Tales of the Bizarro Scrum – The Sprint was a Colossal Failure

  • Post author:
  • Reading time:3 mins read
You are currently viewing Tales of the Bizarro Scrum – The Sprint was a Colossal Failure

Scrum Master: “Team, the last Sprint was a colossal failure.”

So when can a Sprint be considered a failure?

Let us start by defining what does failure mean in this situation? Is it about the team’s velocity being low? Is it the team not completing all the Product Backlog Items they took on in Sprint Planning? Is it the team not delivering a potentially shippable Product Increment? Or is it an unhappy stakeholder? What else?

I do not consider any of these failures. Scrum is all about inspecting and adapting. It is about speculating and validating. And it is about timeboxing to maximize learning, minimize risks, fail early, or deliver early and often. In Sprint Planning, we are speculating that what we are going to build is going to be valuable. We are speculating that the technical solution will work. We are speculating that we can complete the work within the timebox. And we are validating these things at the end of the timebox in the Sprint Review and Sprint Retrospective. We are constantly evaluating feasibility, viability, usability, and desirability and then pivoting by updating the Product Backlog accordingly and adding retrospective action items to our Sprint Backlog.

A lower velocity is an indication of our team’s capacity and a signal to not over commit.

Completing all Product Backlog Items is not the objective of the Sprint. The objective is to deliver a Product Increment based on a Sprint goal tied to an overall product vision. The Product Backlog items help us accomplish this goal but the items in themselves are not the goal.

Not being able to deliver a potentially shippable Product Increment might be due to an incorrect technical solution (a good thing in failing fast and discovering this early) or it might indicate a need for better engineering practices (TDD, continuous integration, continuous deployment, automated testing, etc.) and a review of the team’s Definition of Done.

An unhappy stakeholder might indicate an invalidated hypothesis (a good thing in failing fast and discovering this early), or a misunderstanding of the requirement and a need for more ongoing Product Backlog Refinement.

The entire Scrum framework is based on empiricism and the pillars of transparency, inspection, and adaptation. A statement indicating that the Sprint was a failure goes against the notion of empiricism and what Sprints are all about. It also demotivates the team and will likely lead to trust issues, a lack of innovation, and a lack of transparency. Without transparency we lose the ability to properly inspect and adapt to ensure delivery of value and continuous improvement.

When a Sprint does not go as planned, we should go into the retrospective and reflect back on what happened, learn from it, and adjust accordingly. A Sprint is about continuous learning and continuous improvement.