After the Ubuntu Summit in Budapest, We were faced with a lengthy backlog for the next 6 months. We made sure that we wouldn’t waste too much time on defining in great detail stories that would not be executed until 3 or 4 months from now. The result is that the next month worth of stories are smaller and more granular and large stories are found towards the bottom of the backlog. So far so good.
Like any successful team 😉 we have more work that we wish we could do than we can actually fit over the next 6 months. To reduce scope, I needed to at least defined what is our estimated capacity for the 6 months and compare it with the current backlog.
To be accurate, we would need to estimate the size of every story in the backlog, in a more consistent manner than asking a team member for their gut-feeling (current process). We discussed having a Late Night Poker session at Budapest where we would size every single story, however this strike me as not agile at all.
Having discarded the massive Poker Planning session, I started looking with the Scrum Master at other options: Monthly Poker, Next Iteration Poker…and so on.
Eventually, I decided that I was looking in the wrong direction. We are going to continue doing planning poker for the Iteration that we are about to start and we will need to leave with the uncertainty of our backlog.
One thing was certain, that our backlog was too large and needed trimming down. Looking at our team’s velocity, I noticed that it was not only consistent on the story points but also fairly consistent on the number of stories completed per iteration. Saying this, I set out to cut down the backlog assuming that we completed 7 stories per iteration and that the last iteration should be empty. Clearly, this is not 100% accurate, maybe not even 80%, but it is a good starting point.
Agile is about managing change and living with uncertainty, and I’ve realised that I was trying to bend that in to good-old false security feeling of predictability.
Victor Tuson Palau 