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 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.
- Tales of the Bizarro Scrum
- Tales of the Bizarro Scrum – Developers and Deliverables
- Tales of the Bizarro Scrum – Are You Sure It’s Going to Take this Long?
- Tales of the Bizarro Scrum – The BAs are Holding Us Back!
- Tales of the Bizarro Scrum – Yes, We Are a Self-organizing Team
- Tales of the Bizarro Scrum – Assigning Points to Everything
- Tales of the Bizarro Scrum – Isn’t Scrum Just a Team Level Thing?
- Tales of the Bizarro Scrum – The Code Freeze
- Tales of the Bizarro Scrum – Refining the upcoming 8 Sprints?
- Tales of the Bizarro Scrum – Of Course We Are Agile!
- Tales of the Bizarro Scrum – I’m Responsible for Writing User Stories
- Tales of the Bizarro Scrum – Scrum Master Canceling the Daily Scrum
- Tales of the Bizarro Scrum – The Sprint was a Colossal Failure
- Tales of the Bizarro Scrum – When is Sprint Planning?
- Tales of the Bizarro Scrum – Canceling the Sprint Retrospective
- Tales of the Bizarro Scrum – Product Owner Missing Sprint Planning?
- Tales of the Bizarro Scrum – Extending the Sprint
- Tales of the Bizarro Scrum – I’m the Product Owner and Scrum Master