September 13, 2011 Leave a comment
When you are managing a team that starts migrating towards Scrum, you will find yourself looking into things like velocity and burn down chart wondering if the team is committing to too much or not enough. You will soon realise that if you allow your scrum master to do her job, the team’s velocity will quickly stabilise and become predictable on their delivery.
However, what I find often overlooked is the impact of the backlog management. In my experience, trying to do too much is not just about the team over committing on an iteration but also about the product owner providing a lack of focus for the release.
Let me give you an example. Within the Ubuntu Certification team, we run six monthly releases, this are then divided into two weeks iterations. On the last release, we scheduled 13 themes. A theme for us is a overarching issue or requirement to which then stories are link in the backlog. In other Scrum practices this are called Epics.
Out of this 10 themes, we estimated that we could deliver 75 stories. The team is in average finishing 7 stories (depending on sizing) per iteration. The problem with this approach is not that the 75 stories we picked weren’t the right priorities but rather that:
- We went for breath rather than depth. We achieved some progress in each individual theme, but not in depth progress in any.
- The team constantly had to switch mental context between themes. Some times a month would pass between stories from the same theme. Although the stories are independent this did not build on the sense of achievement by team every time a story was complete.
What I have learned in this release is that context switch is not only a problem for multi-tasking coders but it is also a source of waste for scrum teams needing to frequently change backlog themes from iteration to iteration.
With hind sight, I would have rather schedule 5 themes. I think that the kick that the team gets from making substantial progress in a theme plus the reduce need for context switching would have actually increase the productivity of the team.
Our next release starts in November and I am going to make sure that this time we focus on depth!