“Planning poker? Not again!”

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.

Planning poker

What is your team’s worst nightmare?

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).

Explore or Build

Items above tree need exploration before building. Items on tree and below are ready to build.

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.

4 thoughts on ““Planning poker? Not again!”

  1. Michael wrote: “The article proposes to choose estimation methods depending on the maturity. This may not be a good choice because it makes all the planning and controlling more complex. The translation between two different estimation techniques is not obvious.”

  2. So how do clouds / stars get taken into account when release planning? If they are not using the story point estimation metric, how can they be fed in to any predictions on end date?

  3. @Paul: The project I’m currently involved in takes 2 years with up to 20 persons. It replaces a few existing software systems with a new one and the contract sets up a quite defined set of high-level features to be delivered. To run this project, we split it up into several smaller releases.

    The high-level features were quite cloudy, i.e. roughly sketched concepts. It was not fully defined how much of each feature actually was needed to be built. It turned out that using T-shirt sizes helped a lot to define the budget for such cloudy high-level functions and to distribute the budget over the releases.

    Once such a feature made it into a release, we then took it down to tree level and defined what really needed to be build. A user story map was created for the release with the story progressing towards ready for development. These stories got story point estimates.

    Having the features allowed us to come up with a quick first release plan by spreading the features according to their budget over the iterations. Once the feature got replace by stories – we did this quite early in the project with the walking skeleton defined quite detailed and the rest a bit less detailed – we had the more precise story point estimation that gave us a forecast on what we really would be able to achieve with the release.

    The same effect could obviously be achieved with story points. However having two estimation techniques helped the developers who estimated to accept items that were not ready to implement. Thus we used one technique on cloud level to allocate and distribute the budget over the releases and the second on tree to road level for forecasting and progress reporting.

    The estimate on star level we used in a different setting. In this case, the estimates were used to have a quick decision if we wanted to pursue an idea at all. Items with high costs and small or medium value were instantly removed from our idea pool or at least delayed. This estimate was not used for release planning nor for budgeting.

  4. I learned from another project about the following approach: they do something they call feature points on program level (same principle as story point estimation, just for larger scale stories they call features). When taking features into releases, these features are broken up into user stories and estimated with story points. This gives standard measures we know from agile delivery. Now, as each user story is associated with a feature, a conversation rate between story points and features points starts to become more and more precise and even a feature velocity can be measured. This allows now for much easier planning of coming releases.

Comments are closed.