Trainer Talk Podcast: How Do We Get Credit for Unfinished Stories in a Sprint?

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In this episode of Trainer Talk – the supplemental series to the Agile Coaches’ Corner podcast – Sam Falco, a Professional Scrum Trainer, 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?”

Listen on Google Play Music

Introduction

I get this question a lot, both in training classes and when I’m coaching teams. It stems from a fundamental misunderstanding of what the 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 Agile Manifesto are relevant:

  1. “Working software is the primary measure of progress.” This principle 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. So, 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.

Don’t kid yourself that you “get credit” for incomplete work, and don’t engage in accounting tricks where you split the Product Backlog Item (PBI) and include the incomplete work in this Sprint’s velocity, hoping 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 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, then the Scrum Master should work with the organization to reorient its outlook. The Scrum Master will also probably need to work to establish safety for the team so 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 is no middle ground.

Provide Feedback

Let us know what you thought about this supplemental episode of the Agile Coaches’ Corner. If you’re interested in training, visit agilethought.com/training or call us at 877.514.9180 to learn more. And if you have a question you want us to answer on the next Trainer Talk episode, email us at podcast@agilethought.com.

Want to Learn More?

Stay Up-To-Date