I wanted to examine how teams that regularly fail to deliver forecast work erode trust within an organisation. When a team has eighteen completed sprints without ever meeting a sprint goal then you know that there are hidden issues.
A development team in Scrum forecasts the work to be delivered in the next sprint based upon past velocity and team composition. Having unfinished work at the of a sprint is sometimes unavoidable, when this becomes frequent the team has a problem.
I think it was Mike Cohen who said ‘An estimate is your best guess of how long a task will take based upon your current knowledge’, occasionally sprints goals will not be met but this should be the exception. The late and great Douglas Adams said “I love deadlines. I like the whooshing sound they make as they fly by”. Fortunately in Scrum the deadlines are always fixed for sprints but the quantity of work delivered can vary due to many reasons including hidden complexities, unknown dependencies, sickness or misunderstandings.
Management within an organisation can view a team frequently ending a sprint with incomplete work as:
- Lacking in the required competencies or skills
- Unable to estimate and accurately plan its work
- Inexperienced in Scrum and value delivery
- Untrustworthy and unable to live up to its commitments
Software development has a poor image with many projects overrunning and massive cost increases. Agile is a tool that can be used to try to change this situation.
A team should strive to collectively achieve its sprint goal and deliver the sprint backlog. This will not always be possible as we continue to push performance and increase capability but if we are missing the sprint goal more often than not then there are some issues we can consider:
The team needs to track its velocity – the amount of work completed each sprint, ideally in story points. The average velocity over the last three sprints, averaging the middle eight of the last ten sprints or a simple average of all sprints will be fine – just keep the metric consistent over time.
In addition the team needs to know at the start of a sprint planning session who will be available for the sprint and how much time that they are available for (100% in an ideal world).
Ensure transparency is maintained, if a story does not meet the definition of done at the end of a sprint then it is returned to the backlog and no points are claimed against the unfinished work. Generally do not split stories to be able to claim work, do not re-estimate remaining work and do not automatically roll work into the subsequent sprint.
Utilising a sprint burndown chart, updated at the daily scrum will also help the team maintain a realistic sense of progress.
The development team needs to decide how much work that they can accomplish within the sprint. It is not up to the product owner to push an unreasonable amount or for the scrum master to set a stretch goal but it is for the developers to agree as a team how much work that they realistically believe they can accomplish within the sprint. By all means use previous velocity, available skills and a chart of who is available but as a team they need to accept an amount of work to move to the done state during the next sprint.
So enough discussion, how do we fix this?
The team should focus in a retrospective on what the issues are and how to resolve them. The Scrum Master should facilitate the retrospective with the goal of the team creating actionable task
s to resolve the issue.
b. Do Less
Until we can do a task well slowly we cannot expect to be able to do it well fast. Permit the team the possibility of success by cutting the number of tasks for the sprint so that the sprint backlog size matches the team’s average velocity. When the team is able to complete the sprint goal in time it will begin a behavioral change within the team. Velocity will naturally increase for the team over successive sprints but this needs to be team driven based on the inspect-and-adapt cycle as supported by sprint reviews and retrospectives.
As an experiment try spending more time on refinement and breaking down user stories. Ensure estimation is performed by the team as a whole, planning poker is ideal for this and ensure a reference set of stories exists to prevent estimate creep.
In summary, it is better for the team to predictably deliver less for the sense of achievement and the increase in stakeholder trust. Velocity will naturally increase over time but needs to be team led based on retrospective driven improvements.
If you have any thoughts on unfinished work at the end of sprint then please comment on this post or e-mail me as I would welcome any discussion.