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?"
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.
Two of the principles behind the for Agile Manifesto are relevant:
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?
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.
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.
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.
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.
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!