Recently I was involved in a discussion with Scrum.org trainers regarding the question “What is a failed Sprint?" I think we came to the same opinion and the same answer.
And, in your opinion, what a failed Sprint is:
- If the team doesn’t complete all the forecasted Product Backlog Items for the Sprint?
- If the team does not reach the Sprint Goal?
- Different option?
The question is really very interesting and I suggest discussing it.
Scrum is for the Product, not for the Project. Let's start with the most banal question - what is Scrum and what is its purpose?
Scrum is a framework for developing and sustaining complex PRODUCTS. A framework within which people can address complex adaptive problems, while productively and creatively delivering PRODUCTS of the highest possible value (Scrum Guide, 2013).
I gave a quote from the Scrum Guide to remind us that Scrum focuses on the development of creative PRODUCTS, not projects.
The main objective of using Scrum is creating a product that will be in demand by the end users and that will bring us satisfying Return On Investment (ROI).
One of the biggest risks in software development is the creation of a product that nobody wants to use. Scrum reduces this risk by using frequent cycles of feedback. To get a successful product, the Scrum Team regularly conducts demonstrations (inspects increment) during Sprint Reviews where key stakeholders and end-users of the product collaborate over the Increment of the working product. Thus, we get vital feedback and the Product Owner corrects the product roadmap (adapts the Product Backlog and the Release Plan if the last one exists).
Sprints as projects and experiments. On the other hand, while working in Scrum and focusing on the development of a successful product, we are moving forward with short dashes or projects that we call SPRINTS.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product (Scrum Guide, 2014).
For decades, the criterion for the success of software development was the golden triangle of the Manager (Time, Cost, Scope). As a result - thousands of ruined projects, money spent and useless products, because the triangle is only indirectly related to the success of the product.
Scrum is an empirical process and each Sprint can be considered an experiment.
At the end of each iteration, we can direct the development team to go in a different direction from what we may have initially conceived. In fact, the likelihood of this happening is high. Initially, we have a vision or an opportunity that we want to take advantage of. We have a development team create a software application that addresses a highly important aspect of this. We look at the increment. Then we start thinking about how we will use it. We start thinking about what we could add to the increment to make it more useful. In some disciplines, this is referred to as mid-course correction. It occurs with each iteration (Ken Schwaber, Software in 30 days).
And finally we are approaching the most important question. Given that each Sprint is an experiment and Scrum is an empirical process:
An unsuccessful Sprint is one where at the end we have not learned anything. We did not Inspect and Adapt the results for customizing the Product and Processes.
I must say that this concept is difficult to accept for most people. We used to think of a successful team as the one that brings a big number of features completed during the Sprint. But that really doesn’t mean anything if those features have not been inspected and adapted accordingly.
Successful Sprint example:
The team did not reach the Sprint Goal and overestimated their capacity during the planning and forecasted too much. At the Sprint Review we honestly demonstrate to stakeholders only what is really "Done", even if we have just a few things to show. We receive feedback, whatever it is. The Product Owner then decides whether to fund the next Sprint or not. The answer may be either positive or negative. In the case of a positive decision, the Scrum Team goes to the Retrospective where the team inspects itself, processes and tools in order to carry out their adaptation in the next Sprint.
Failed Sprint example:
The team managed to complete a big number of functionality and brought to the Sprint Review exactly what it forecasted ("thanks" to some overtime and lowering quality). But nobody is present at the Sprint Review except the Product Owner. The Development Team never sees the end-users, and other stakeholders are always too busy to visit the Review. There is no feedback on the Increment. Then we skip the Retrospective because we have a lot of work to do. We start the next "successful" Sprint.
Summary:
- The Scrum Goal is the creation of productive and creative products rather than projects.
- Each Sprint is an experiment. Its results should be inspected and correspondingly adapted.
- If it is impossible to Inspect the results of the Sprint (experiment) and to Adapt, it is considered a failure.
Inspect and Adapt, my friends!