In a recent discussion with a team, the topic of “unshippable bugs” was brought up. The team explained to me that there are cases when there are bugs found during a Sprint that cause the software to become unshippable. Their fix was to extend the Sprint and fix the bugs. For many of us this probably does not seem all that crazy of an idea. In general, there is a big problem with this idea if you are using Scrum to build software. Let me explain. In Scrum we are always shooting to complete PBIs in the order of importance. We don’t want to “divide and conquer” all of the PBIs in a Sprint but rather work on one at a time, in order of importance. (as much as possible) There are numerous reasons for this including the fact that we want to always deliver some “done” value at the end of the Sprint. If we split up the work we run the risk of not delivering any of them and thus creating no value. Additionally, if we want to deliver positive, quality value, we need to always including many forms of testing in our definition of done. (unit, integration, functional, performance, regression, etc.)
If we comply with our “definition of done” during the Sprint in a way that makes the PBI shippable, how are teams getting to the end of the Sprint with “unshippable bugs?” One reason might be that the bug was discovered during testing after the PBI was considered done. Should the team be writing code in such a way that testing can’t keep up? Should the testing specialist be the only one testing? No. Quality and testing should be owned by the entire team such that the software is thoroughly tested as it is written. This way bugs found after the PBI is considered done are usually minor and easy to fix.
The next issue here revolves around the concept of delivery. Should the team just extend the Sprint? No. If the team is shipping every Sprint, this is usually indicative of a fast pace and the Sprints should already be short. (1-2 weeks) If a bug is found and the Product Owner wants it fixed prior to shipping, the team should simply make it #1 in the order and deliver it as part of the next Sprint. If the Sprints are longer (2-4 weeks) the team is using working in a Release Cycle and has a number of choices, ship what was delivered a Sprint prior or wait for another Sprint. Finally, when you extend a Sprint (timebox), the Product Owner and the organization looses the ability to contain risk, measure velocity and establish cadence.