Preview Mode Links will not work in preview mode

Agile Coaches' Corner shares practical concepts in an approachable way. It is for agile practitioners and business leaders seeking expert advice on improving the way they work to achieve their desired outcomes. If you have a topic you'd like discussed, email it to podcast@agilethought.com, or tweet it with #agilethoughtpodcast.

Jun 2, 2020

In this episode, Professional Scrum Trainer Sam Falco addresses the question: "If we have stories that aren't finished by the end of the Sprint, how do we get credit for the work we've done so far?"

Introduction

I get that question a lot, both in training classes and when I'm coaching teams. It stems from a fundamental misunderstanding of what a Scrum Sprint is for and how Scrum Teams should measure their effectiveness.

How does seeking credit relate to the Agile Manifesto?

Two of the principles behind the for Agile Manifesto are relevant:

  1. "Working software is the primary measure of progress." It doesn't talk about credit.
  2. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Seeking credit for unfinished work violates both principles. There's no value in unfinished work!

OK, mister smart guy, I hear people saying, but it happens. Sometimes things don't get finished. What should we do about it?

Achieving the Sprint Goal without finishing all Sprint Backlog items

In the most positive scenario: the team achieved the Sprint Goal, but there were some extra items in the Sprint Backlog that weren't directly related to it. We have a working, thoroughly tested Increment that meets our definition of "Done," but we also have these one or two things we were doing, and we've run out of time.

If that's the case, congratulations on creating a potentially releasable increment! As to those extra bits that you thought you could finish, have a conversation with your Product Owner. Is this work worth continuing? Make sure it is reflected in the Product Backlog, so the Product Owner can order it appropriately. Maybe it should go into the next Sprint, maybe not. It's the Product Owner's call.

In your Retrospective, talk about the fact that the Development Team brought work into the Sprint that it couldn't complete, and talk about why it happened. Did the team overestimate how much work it could do? Adjust for that in future Sprint Planning. Did your team add the extra work as a kind of "stretch goal," or add new work to the Sprint Backlog late in the Sprint because it was running out of work to do, and wanted to "fill up the time?" Talk about whether those are practices that add value. That half-completed work is a form of waste.

The Sprint Goal was not achieved

Another scenario, less positive, is when the incomplete work means that the team failed to achieve the Sprint Goal. There's no new working increment. If that's the case, the team needs to figure out why that happened. This becomes another topic for a Retrospective. Was the Sprint Goal too ambitious?  Worse, was the Sprint Goal simply, "Do all the things?" Learn to create better Sprint Goals. If the Sprint Goal was reasonable, figure out what kept the team from achieving it. Do better the next Sprint. Examine your practices and figure out how you can achieve the Sprint Goal next time.

Just don't kid yourself that you "get credit" for incomplete work. Don't engage in accounting tricks, where you split the Product Backlog Item and include the incomplete work in this Sprint's velocity and hope to finish the rest in a future Sprint. Carrying over work from Sprint to Sprint subverts the Product Owner's accountability for maximizing the value of the product and of the Development Team's work.

How do we measure effectiveness of a Scrum Team?

Scrum Teams should measure their effectiveness by the value they deliver, not by how busy they are from Sprint to Sprint. If the organization values productivity measures rather than value delivery, the Scrum Master should work with the organization to re-orient its outlook. The Scrum Master will also probably need to work to establish safety for the team, so that they don't feel obligated to try to fill up every minute of their time.

Conclusion

The purpose of a Scrum Sprint is to produce a thoroughly tested product Increment that is in useable condition. There is no "credit" given for work that isn't complete in Scrum. You either produce an Increment by the end of the Sprint that meets your definition of "Done," or you don't. You either fulfill your Sprint Goal, or you don't. There's no middle ground.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!