Inevitably, during a products development the development team will pull in too much work to complete during a sprint, or will produce work that does not meet the definition of done, or fails to meet all the product owner’s requirements. What should be done with incomplete PBI’s? This debate has come up a few times with my teams. Here is what we do to account for the expended effort and why.
First off let’s do a little review. What is velocity in scrum? Velocity is the measure of the rate at which a scrum team delivers done items from the product backlog, or how much value is delivered by the development team per iteration. On our teams we use PBI’s and effort points, so for us our velocity is the sum of the effort for all PBI’s, that meet the definition of done, that are delivered in an iteration. We use this number to help us tell if we are getting better as a team, and for release planning.
So what is the real goal of product development? In each iteration, it is to produce a potentially shippable product increment, overall, it is to produce a product that meets some minimum scope. In scrum we call this the minimum viable product, or MVP. In scrum we accept that we don’t know everything that will need to be built for a product to achieve MVP so the minimum scope is a very rough estimate. We base this estimate on the sum of the effort of the PBI’s we think we will need to produce.
So now that we have established some basics, what do we do with the PBI’s that are not completed within an iteration? The scrum guide doesn’t really say what to do with these items, however it does state “When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.” I tend to treat incomplete items the same way normally the items are still the highest priority items so they typically get pulled into the next iteration. I do get pushback from the development team on this though. The development team typically asks, “Do we get the difference in points from the originally estimated versus the new estimate?” No, again what is velocity? It is the measure of value earned in a sprint. The only question that is relevant is “Did the PBI meet the definition of done and was it accepted by the product owner?” since the answer is no then no velocity was measured on those items. But how does the development team get credit for the work they did? What do you mean by credit? That implies that the team is more focused on increasing their velocity, than producing quality increments of potentially shippable product. Velocity is only valuable as a measure of a team’s productivity. It should not be the goal of development, besides if the ultimate goal is to reduce the overall scope to 0 then that is best served by re-efforting the remaining work on incomplete items and either pulling them back into the sprint or leaving them in the backlog.
While I agree there is some value in keeping track of the old effort estimates I don’t think it offsets the unhealthy focus on velocity alone. The Agile Manifesto states “Working software over comprehensive documentation”. The team should be more focused on delivering working “Done” software than increasing the team’s velocity. All that said do what works for you and your team. If it becomes a bone of contention then by all means give them credit for the “earned” effort, as long as you are using average velocity for planning the math works either way. Have fun and scrum on.
Awesome post, thanks for sharing!