I’ve recently had a few good conversations about the desire to coach Scrum teams to complete their stories by the end of each sprint.
I’ve always felt that this was not a good goal for a team as there is a risk that it will focus too much on that goal, to the point where it becomes a target and ceases to be valuable.
“When a measure becomes a target, it ceases to be a good measure”. Goodhart’s law
Human beings are very compliant to figures of authority, and if a manager or team lead asks a team to focus on closing their stories, this will become their goal. Engineers will focus on making sure their cards are done at the end of the sprint using different tactics to meet that goal. For example:
- changing the definition of done to exclude testing
- consider work Done when a PR is open because the code review takes too long
- work in the background on stories and include them in a sprint only when they are almost complete The goal will probably be reached but nothing valuable will come out of it.
Why does it matter to complete stories within a sprint?
This goal is often presented as needed so that a team can be more predictable. If a team always completes between 3 and 5 stories in a sprint, that can be used to predict when a larger feature will be complete. It reflects the need for an organization to deliver against fixed dates, or promises made to customers. This shows the lack of Agility of an organization and how it works with customers or stakeholders. The third value of the Agile Manifesto is Customer collaboration over contract negotiation so, instead of predictability, an Agile organization promotes Transparency and tries to involve their customers as early as possible in the development process. The challenge is that often these customers are not asking for that Transparency and collaboration. They prefer contract negotiation which often ends up to their advantage. This should not stop an organization from being transparent with customers, and seek feedback as often as possible.
Is there value in measuring if a team completes all their stories within a sprint?
The answer is Yes and No.
There is no “one way” to be Agile, and it is always empowering to go back to the Agile principles and forget about the practices. This is the way to free a team and let them discuss which principles they value and how it translates in their day to day work.
The principle behind completing all the stories within a sprint is “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
In Scrum, the goal is to have usable software at the end of a sprint so that the team can collect useful feedback. This is not meant to be predictable. It is meant as a checkpoint to make sure the team is solving the right problem. Not all stories need to be finished, as long as you have usable software that can be used to gather feedback. Working in small releasable chunks of software also offers the possibility to quickly adapt to change, either based on the feedback received, or just a change of priority.
This principle can be implemented in different ways by different teams. Some might go as far as developing a process that allows to deploy every commit in production, while others might think that releasing once a month is good enough to gather feedback.
So instead of trying hard to coach your team to complete their stories in a Sprint, asked them what they think about this principle, how it applies to them and how they would like to measure themselves against it. Empower your team to own their way of working.