Don’t panic. It’s not uncommon for a team to have some unfinished work at the end of the sprint. One of the biggest misconceptions about Scrum is that it is perceived as a silver bullet solution to solve any problems in your organisation. It’s not like that! What Scrum does instead is to help you maximise transparency and thus identify problems on a methodological, organisational or communication level.
It’s up to you to decide what will you do with this information. Some might not like it and will try to misuse Scrum and modify the framework to an extend that will hinder it from exhibiting potential problems, which in this case will stay hidden instead of being addressed transparently. Maybe you are familiar with: “This will not work for us!” Others will use this information to change the system.
Some Scrum teams can be riddled with interruptions or regularly fail to deliver on their sprint forecast. Adopting Scrum doesn’t automatically mean that interruptions or complete sprints will be avoided. It just makes visible when it can’t be possible. To change the way we work will always require some creativity, teamwork, problem solving skills and trust.
Time is up! Pencils down!
Similarly, this is what happens in Scrum. At the end of the sprint, teams stop, show their work and reflect. As Mike Cohn states “Ideally, a team would finish every item on it’s sprint backlog every sprint. But for a variety of reasons, that isn’t always the case.” Even though each team is unique, here are some common reasons:
When the sprint starts, after the Planning meeting, team members start multitasking. This happens especially then when they begin by working on too many stories at one time. There is even a worse situation when managers ask team members to work on several projects inside one sprint. Even if the initiatives are small, working on them at the same time introduces huge costs caused by context switching and waiting time. Setting WIP limits can help in this situation. Do not start to work on another user story, until the one that is currently in progress, is Done.
- Large stories
Even if according to the estimate these would fit into a sprint, there is often the case when teams don’t manage to get large user stories to Done in one sprint. A common cause for large stories is when the Product Owner doesn’t look for the first possible value in the feature set. When refining big user stories, the product development team should identify for whom they are implementing the specific user story. That way, they will know also why they are implementing it. The smaller the story is, the faster will the team see progress and learn, the faster will the Product Owner provide feedback and see the throughput. Consider writing stories that are 1–2 days in duration- it’s not easy but worth trying.
- Team does not deliver through the architecture
Team members do not focus on delivering thin slices of functionality. This happens frequently when the team members work as experts across the architecture — even in a cross-functional team. While the team may start with back-end, middleware or front-end people, encourage the team members to become generalising specialists, to have more areas of expertise. Of course they will have their own preferences which is perfectly fine, but they will be also open to support their team to deliver fast a feature or a feature set. Pair and mob programming help in this kind of situation and prevent also reinforcing expertise. When teams deliver through the architecture, one vertical slice at a time, they can release something when they want to and get feedback early. These teams learn early what their Product Owners or customers want.
Always look for a root cause
Whether it happens because of one of the reasons above or it’s simply bad luck, don’t automatically carry over the remaining work to the next sprint. Visualise where the work is, select the highest ranked work and start working on it, as a team.
Use the retrospective meetings to reflect on whether the team could have somehow prevent this. Tools like cumulative flow diagram or burn down chart can help to diagnose and experiment with the team.
What good ways that minimise how often you have work left unfinished at the end of the sprint have you experimented?
Create Your Successful Agile Project — Johanna Rothmann