Cutting Quality to Hit a Release Date
Imagine that your Scrum team just got out of a heated sprint review. The team didn’t deliver anything during this sprint, and the stakeholders are furious. Deadlines were reiterated and ultimatums delivered: “You will deliver everything in this next sprint or else!’’
Then temptation creeps in: What if you removed the requirement to write unit tests during the sprint? You could just add them later when you aren’t under so much pressure.
The truth is there will never be a time when your team isn’t under pressure. And once you start down the path of sacrificing quality to meet dates, you’ll find that your productivity steadily declines over time as your technical debt increases.
In these situations, Scrum masters really earn their keep. Here’s an important question you should ask the development team and the product owner: Does removing a requirement from the definition of done uphold our commitment to quality and allow the team to deliver a potentially shippable increment by the end of the sprint?” If the answer is a resoundingYes,’’ then great! You’ve found a constraint that you can likely remove without much impact. But when the answer is “No,’’ it’s time to look elsewhere for solutions.
Why? Because undone work—work that the development team claims is done, but for which there is still more work remaining—is never part of the increment.
For example, suppose a development team says they are done creating a new shipping feature for a website that will allow real-time shipping quotes to customers via USPS. Though they say it’s done, it hasn’t been tested to confirm that it works with the organization’s shipping and receiving system because they can only mock the system, not test in a fully integrated environment. So while they’re done with the feature in their development environment, testing the integration with the shipping and receiving system is undone work because it’s not completed yet.
Undone work should never be put into production–ever. In our example scenario, if the team puts the undone work into production there could be dire consequences to the organization’s shipping and receiving system. As Scrum masters, we must take the impediment (in this case, the team’s inability to do full integration testing against the shipping and receiving system) into our hands and work within the organization to remove it.
Each increment gets added to all prior increments and thoroughly tested, ensuring that all increments work together. This rule comes straight from The Scrum Guide. Undone work doesn’t meet that criteria, so it can never, ever be released.
Consider what would happen if you made an exception to this rule. How would you know the impact your software has on your customers if you neglected quality and allowed undone work into production? You wouldn’t—until it’s too late and customers are reporting a degradation of quality in your product. The short-sighted decision to release undone work increases your team’s risk of failure. It will become a habit, quality will degrade, and your customers will notice. It simply isn’t worth the risk.
A done product increment is usable. If you release it, it doesn’t break in production. There are no bugs, no glitches, no half-baked features. A released product increment that the team calls done is valuable, it’s of high quality, and it works as intended when the customer uses it.
When balancing quality and deadlines, try mapping out your last sprint on a whiteboard or with sticky notes and markers. Start at the end with the increment and work backward. Put your Scrum events on the wall and include any major events from the sprint. Did your team composition change? Did you get new product backlog items mid-sprint? How did refinement go? Was the daily scrum productive and focused on the sprint goal? (You had a sprint goal, right?) Use the insights you gain from this discussion to come up with improvements that will allow you to deliver a done increment.
If you’re under a deadline, revisit your product backlog items with your product owner. Work diligently with them to try to understand what is actually necessary and possible. Working with the team, you may try to find ways to slice your PBIs into smaller pieces that are still valuable and shippable within a sprint.
Approaching a deadline by negotiating scope and/or decomposing PBIs into smaller chunks changes the discussion in an important way. Rather than trying to negotiate an estimate or a date, you’re negotiating scope. Cutting the features that aren’t truly needed by the deadline and slicing the features that are needed can help a team make progress under stressful conditions while preserving quality.