Estimation of the effort to implement and deliver a set of functionality is an important but not always the most fun part of product development. Estimations are done at different detail levels during the project, for example the high level story estimation and the low level task estimation. It is a few years since I did task estimation; many times it is a waste of time doing low level estimations, so in the following text I will describe a technique that I like when estimating the user stories.
Like many people involved in agile projects I have done the relative user story estimation using the planning poker estimation technique. This hasn’t really worked out for me (but I will of course be open to use it in future projects with people for which the technique is working perfectly). It may have been how the meetings have been facilitated, but I have seen the following general pattern when I have played the estimation game: a few people got really excited and talked a lot and expressed their thoughts about the complexity and size of each story. A few others expressed clearly that they do not have enough knowledge to choose between the different points and voted blank, and the large majority sat quiet trying their best. Even though that I worked on this and tried to facilitate the meetings in different ways, we had in general a low level of collaboration in the meetings.
I feel that the technique didn’t help the team collaborating in the way we needed to do to get good estimations. The situation with all members sitting around the table created distance to each other instead of closeness. What I like instead is sessions where everybody contributes to the discussion, expresses their views and experiences and arguing to each other about the relative sizes of the different stories. The result is much better in this case and you get a better buy-in into the solution by the whole group.
I have tried something different that have worked really great for me, and which helped the team reach a collaboration level that I hadn’t experienced during other estimation sessions. We had the same goal to relatively estimate all the stories in the product backlog. But at these times I threw out the card deck and did the estimation in the following way instead.
We came together in a room. We moved away all chairs so that the whole team could stand around the table to ensure that everybody could reach all around it. We then wrote all stories on small papers and gathered them in a pile on the table.
We then first relatively compared all stories to each other:
- We took one of the stories and talked about it. We discussed what we needed to do to implement it, and then placed it at the middle of the table.
- We then took another story, talked about it, and then relatively compared it with the first one lying at the table. We then placed the story either above or below the first one depending on if we thought it was larger or smaller than it.
- We then proceeded with the rest of the stories relatively comparing them with the stories already on the table (without talking story points, we just decided on the relative size of the story compared to the already estimated ones).
When all stories had been placed on the table relatively estimated to each other we started to allocate story points to each one of them (using the Fibonacci numbers)
- We decided that the story in the middle of the table was 8 story points.
- We then asked if the story above that one was large enough to have 13 story points or if it was somewhat close to be 8 points story.
- We then continued through all stories allocating story points to each one of them until all stories had estimates.
The estimation of a quite large product backlog took in total one hour, which was really fast compared to the estimations we had done in previous projects. And, I definitely think that we got a higher level of engagement; everybody discussed and contributed to the shared understanding of how to implement the different stories and which effect they had on the application. I also think that we had great fun doing the estimation this time!
Another nice thing worth mention is that we got a really agile way of estimating new stories during the following iterations. We put up a big paper on the team wall with a few selected user stories from each group ordered in decreasing size from the top downwards. At the top of the paper we had a few large stories and at the bottom we had a few of the smallest ones and the other groups between them. When we had new stories we gathered at the team wall and relatively estimated the new ones compared to the existing groups on the paper. In most cases it only took a couple of minutes estimating the new stories.
In programming you should try to organize the code according to the single responsibility principle. By following this principle you get a more understandable code since you only need to focus on one thing at a time to be able to read and understand it. When you are using the planning poker technique you are in parallel doing two different parts of the estimation algorithm: the relative estimation of the stories and the allocation of estimation points. Applying the single responsibility principle to this problem you need to decouple these two parts from each other and let the participants focus on them sequential. This is exactly what happens when you are using the technique I have described here.
A few months later I read a blog describing this kind of estimation technique which named it as the Steve Bockmans team estimation. So, I think we can conclude that this is a valid pattern of how a team effectively could estimate a product backlog with a lot of user stories.
3 responses on “Steve Bockmans team estimation”
Hi Anders, just a couple of thoughts and questions.
I am surprised that it only took you one hour to do the estimation. How large was the team? how many stories composed that large backlog?
Let’s say I have my team, which consist of 4 developers, plus the Prod owner (I won’t mention that I include the QE guys too). If everybody participates in discussion, allowing a minimum of 1 minute of talk each one? (We have stories of 8 points, thus some complexity is involved). That will give us not less than 5 minutes per story. Honestly I don’t think you can estimate more than 10 stories in one hour session.
Thanks for reading my blog and for the question 🙂
I think that 5 minutes in average is quite a long time to spend on each story during a backlog estimation workshop, you could go down a couple of minutes in average and still get a good estimate of the backlog. But, anyway, the amount of time you need to spend on each story depends on a lot of different things, like your knowledge in the domain, how many times you have developed something similar before, and how much preparation you have done before the estimation workshop. In this case we had developed similar applications for a few years and our requirement engineer had done a lot of preparation with GUI mockups and she had a good understanding of what we were about to develop for each story. I do not remember the exact number of stories we had in this backlog, but it was in the range 20-30 stories.
I would like to stress that I do not mean that you will always estimate 20-30 stories if you use the described estimation technique. But for me the technique has helped me estimate more stories than I have done at similar workshops and applications using other kinds of estimation techniques, so I recommend you to try it out in your project and see how it works out for you.