“Try this sometime: Make a list of everything you are going to do in the next few weeks at home. Everything from dishes, laundry and other household chores, to fun things like going out to dinner or renting a movie, to larger endeavors like planting that garden or repainting the bedroom. Estimate how many days all this will take and write a date on the calendar to review the list to see if you got everything done. ”
Scrum teams often get to the end of a Sprint and have some work that isn’t done. There just wasn’t enough time. Do we move that into the next Sprint? Do we put it back on the Product Backlog? Do we re-estimate it? Is it bad that we didn’t get everything done? What if we got a lot of things 90% done, but nothing 100% done?
Let’s say we have 4 PBI’s in a Sprint, and the team works on all of them and makes good progress, but doesn’t quite complete any of them. We’re left with something that looks like this:
In this case, we’ve done a lot of work, but delivered zero value. Nothing is DONE, we have nothing to show at the Sprint Review, and we have nothing to potentially ship to customers. We also have to figure out what to do with this undone work now. Carrying it over into the next Sprint is the most common approach. There’s a huge downside here in that the PO no longer really has control over the order of the work, and therefore over the delivery of value. By not getting to done, the development team is de facto controlling the order of the backlog.
Here’s a better idea. Work each PBI to completion before starting the next one. This is called “Single Piece Flow.” Or if that seems silly given your team history or context (team size comes into play here often), then try just two at a time. We might end up with something that looks more like this:
Now in this scenario, we got 3 of the 4 PBI’s all the way to DONE, delivered those valuable features, and then made just a bit of progress on the 4th PBI. This is a much better, more agile, place to be. You have 3 things to show at a Sprint Review, a much short discussion about what to do with the 4th PBI, and the PO is in control of the backlog and can decide what to work on in the next Sprint.
The biggest argument against working like this is typically: that’s not very efficient. We might have idle time, or might have to pair-up when we could be working on separate things. We can actually make more progress on work when we wplit it up in a way that allows us to each work 8 hours per day.
Yeah, you are probably right.
But the economics here are really interesting. Think for a moment in terms of time-value of money, depreciation of customer needs, the economic utility of having features done and useable now versus later, and the risk of developing the ‘wrong’ product. In this context, it will always be more valuable to work one PBI at a time all the way to DONE. Even if this is less efficient.
“So you sit down to review your to-do list with your family. You proudly announce that you washed the dishes but didn’t put them away, washed the laundry but never had a chance to move it to the dryer, rented a movie for the family to watch but never organized a night when you’d all be home, and repainted the bedroom and never got a chance to remove all the painters tape. Good job?”
