The Sprint is the heart of Scrum. This means that all events and scrum artifacts are meant to make work as efficient, comfortable, valuable and transparent as possible during a Sprint. Before the start of each new Sprint, the development team and the Product Owner outline the scope of the work to be completed, called the Sprint Backlog. This is a kind of commitment which means the Product Owner can be sure that the development team will make every effort to complete the assigned tasks.
What happens if the Sprint is completed but some tasks remain incomplete?
Every reason for the failure of a Sprint should be analyzed, and steps must be taken to avoid it happening again in the future. For responsible and mature teams, the failure to complete a Sprint on time is sometimes taken personally, because they feel that they have not kept the promise which they made at the start. The motivational aspect is also meaningful – completing and presenting a task well done puts wind in your sails and motivates you to work even better.
So why do some Sprints fail?
Poorly planned Sprint Backlogs. People tend to be either overly optimistic or overly pessimistic. Our personality traits have a direct influence on the work we do. We frequently overrate our abilities or have a good-faith tendency to strive to please others. We can’t avoid this when planning a Sprint, but we also have to remember that it is very important to be realistic about the scope of work that the team is obliged to undertake.
Superficial analysis and poor task estimation. When we plan a task to be done, we believe that we know enough about it to properly determine its complexity. But what if our assumptions turn out to be false? The cycle of events begins, which leads to the failure of the Sprint. The task turns out to be more complex than we thought; we devote more time to detailed analysis and additional work, and consequently “the Sprint is too short” to complete, test and present specific functionality.
Changes to the composition of the team. The goal of the Scrum Master’s work is to create an independent team. The most mature and independent teams are, of course, those who know each other well and know each other’s strengths and weaknesses. Each change within the team causes uncertainty and means that work proceeds less smoothly, which directly affects the velocity of the team, i.e. the speed at which the Sprint Backlog is processed.
Poorly estimated velocity. It turns out that this concept does not always mean the same thing. Let’s consider a hypothetical situation: the velocity of the team oscillates at around 70 Story Points, which means that during the last 4 Sprints, the total number of completed tasks was just +/- 70 SP. Does this mean that another Sprint can also be planned for these 70 SP? Intuitively we might say yes. From experience, we know that it all depends.
While working with teams, I noticed that even if the number of SP is the same, working on a larger number of smaller tasks is faster than a smaller number of large ones. This means that a Sprint is more likely to be successfully completed if the tasks in the Backlog are divided into even smaller tasks with a lower SP value. This is one of the reasons why splitting large tasks into several smaller ones is a great help during the planning and implementation of the Sprint. With smaller tasks, the level of uncertainty during development work decreases and the speed of testing increases.
Can an unsuccessful Sprint bring added value?
In spite of appearances, yes! Scrum is based on empiricism, so each failure should serve as a lesson for the Scrum Team, helping them to draw conclusions for the future. Of course, this is best achieved by a ‘Retrospective’ – a meeting where the factors that help, and hinder, the work process are analyzed. It is also worth noting that sometimes teams are willing to undertake tasks verging on the impossible, just to check whether they are able to do them.
Let’s remember that a failed Sprint can eventually bring more business value to stakeholders than a successful one which was simply planned with a higher degree of caution. In this situation, should you verify what causes a team to err on the side of caution, rather than setting out a realistic Sprint Backlog?
Challenges which the Scrum Master must face
I encourage beginner Scrum Masters to print out and stick a piece of paper up over their desk that says “The Sprint is the heart of Scrum”. This seemingly obvious sentence will allow us to focus on what is most important in our work – supporting the process in such a way as to make Sprints productive. Everything else is only a means to help, not an end in itself.
Read more:
Scrum Master at Inetum. He believes in empiricism and iteration and teaches Scrum Teams independence and responsibility. Outside of work, Łukasz is a mountaineer and climber, as well as the operator of the Tuudi.net portal.