In a Scrum project, we want teams to buy stories only if they are going to complete them within the sprint. There are several good reasons why that’s true, but many teams don’t know what they are.The first reason has to do with increased work in progress (WIP). If you buy a story for sprint N, and don’t complete it until sprint N+1, you must have increased the amount of time a story is WIP. As our colleagues in the lean world will tell you, increasing your WIP has two effects: it decreases overall throughput of the system, and it decreases the quality of the product you get out the other end. Stated another way: bigger WIP results in a shoddier product, slower than you would have gotten otherwise.

Another reason to discourage buy-but-don’t-finish is that is destroys the team’s ability to forecast. If I buy a story worth 12 points and complete it, then I can use that as a guidepost when deciding what to take on in the next sprint. If I buy 177 points worth of work, complete 90, but another 50 are “almost done” then how many points do I take on, 90, 140, or something different from either? Teams that fall into this problem have removed themselves from the empirical management style of Scrum, and entered the world of the “gut check.” All teams have to start out with buying what they’re comfortable with, but we want them to move to using velocity to gauge their ability to get work done. If they routinely don’t complete the work, then we can’t use velocity to forecast work.

We want teams to commit to finishing what they start, because it encourages accountability and ownership on their part. In addition, if we don’t insist on finishing the stories we bought, we can’t forecast, the work product will be poorer, and will come later.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.