Danger - Keep Off Track High Voltage

I was recently asked if a story was done if when implemented it would break production. The suggestion is that since the specific code meets the requirements identified in the user story and was unit tested the team should be able to celebrate success and put another story on the backlog to fix the problem that would lead to a production failure. This, not a rare or silly question. Before we look at the reason why someone might ask this question let’s deal with a black and white answer. The most succinct answer to the question is always, “no, the story is not done”. The reason is that the story is not implementable and unless the goal of the story is blow up production and anger customers it can’t be considered done. There are four common scenarios that generate the is a story done if it breaks production question.

Scenario 1: The its someone else’s problem defense. Another team is tasked with systems integration, integration, and regression testing. This scenario also occurs when development and testing are in separate iterations. Problem discovery occurs only after the code (or another deliverable) is assembled into the overall system.

Scenario 2: The pain deferred feels better defense. Success occurs only when all stories are complete (whether they are implementable or not); anything else is a failure. Organizations with a strict success/failure definition will often ridicule teams that are not viewed as “successful”. Teams in this situation will often push the boundary by declaring a story done and postponing the pain and ridicule of “failing” to a later the sprint.

Scenario 3: No definition of done defense. In this scenario, the implied definition of done is when time or interest runs out.

Scenario 4: The rest of the system is wrong defense. In this scenario, the code delivered by the story is correct and will work once the rest of the code is re-written. The only time this defense makes a modicum of sense is if an application is being rearchitected from the bottom up. This can also be a reflection of not investing in a testing environment.

None of these reasons are a good reason for declaring a story done if it will break production when implemented. For any individual story, the simplest answer is to leave the story open and fix the code so that it won’t blow up production. Yet, these types of scenarios rarely occur in a vacuum. Fixing these scenarios is rarely as simple as just saying don’t do that anymore. A permanent fix requires process or systemic changes.

  1. Create a definition of done that includes both integration, integration testing and regression testing.
  2. Invest in an environment that supports automated builds and preferably continuous builds.
  3. Invest in automated integration and regression testing.
  4. Develop a balanced view of measurement. Combine measures of story completion with value, cycle time, efficiency. Measurement data is most useful when teams use the information generated to improve their capability.

One of the most important disciplines in Scrum and nearly every other agile framework is that the work delivered at the end of sprint or increment is shippable or potentially shippable. This discipline is important to instill a mindset that value is only accrued when users use the code in production. Repeat after me – if I can’t implement the story it is not done.