A few days ago, we had a discussion about Scrum and one person asked the question if it really isn’t possible to run effective estimation meetings with 16! persons involved. If you have an answer ready, wait. Once the problem becomes clearer, the solution is getting more interesting. It may rather be a question of maturity than of team size.
In fact, it made sense to have a team of sixteen persons in this situation, whatever all the gurus may make you believe. As the question hints however, the meetings were ineffective, mainly for two reasons. First, team members were able to estimate some of the stories, but not all, as different expert knowledge was needed. So at any time, half the team was bored.
Mostly however, many stories were not ready to estimate with story points, yet. Product owner and team were not clear enough what the story was all about.
I perceive this as a general issue in Scrum teams. Too many stories are brought into sprint planning that are not ripe to be estimated with story points. The conversation about the backlog item has not reached the point needed yet. The team does not know what to build nor does the product owner know what he will get after the sprint. Planning poker takes ages.
In our metaphor from stars to road, such a backlog item is not on tree level yet.
Immature items need a different estimation method
During sprint planning, the Scrum team takes the top-most backlog items, clears the last details, and estimates the items with story point. This process works fine for items on tree level.
If a team tries to do this process with items in the clouds or even in the stars, the process fails. It takes too much time to clear the last details! Every Scrum team I’ve been in had to deal with this issue.
The response of the team is uniformly to tell the product owner to come better prepared next time.
This may be a solution.
But epics need estimations as well. The product owner in the situation above needed estimates from the team to select those stories that provided good value at reasonable costs before going through the whole conversation! The task for this is backlog grooming. And it’s a good idea to separate this task from sprint planning.
Rate the maturity first
The solution is fairly simple. Briefly discuss (time box recommended!) each backlog item and assess the maturity. Then choose an appropriate estimation method and estimate the items per level, here is a proposal:
- Stars: Use very rough estimates e.g. small, medium, big
- Clouds: Use e.g. estimation by T-Shirt sizes (XXS, XS, S, M, L, XL, XXL)
- Trees: Use storypoints and for the tasks even hours of work.
The cone of uncertainty is related;
a description in the context of agile
estimation can be found e.g. at agile101.net.
This done, you can juggle with backlog items (see towards the end of the linked article).
One thing a team can do is to separate all items above tree and discuss, what needs to be done to bring it on tree level. The team could add the respective exploration tasks to the backlog, e.g. create UI sketches, conduct interviews with some stakeholders, build a throw away prototype, or even a product increment to be improved later.
For those stories that remain to be estimated with 16 persons: Why not having a bidding phase first, where team members mark those stories they really are able to estimate. Split the team accordingly, conduct planning poker, come together later and present the results. Much faster and smarter.
So summarizing the thoughts in this article: Dealing with the waste of putting 16 persons into one room and doing everything together is much simpler if you know the maturity of each item and choose an appropriate level to estimate it. It allows the team to separate stories into the buckets for exploration and building and, overall, keeps estimation meetings leaner and less painful.