2 Times to Play Planning Poker and 1 Time Not To

This post continues my recent series about Planning Poker by focusing on when to estimate.

Because Planning Poker is a consensus-based estimating approach, it is most appropriate to use it on items that require consensus. That is, I recommend using Planning Poker on product backlog items rather than on the tasks that make up a sprint backlog.

Estimates on the user stories of a product backlog serve two purposes:

1. They allow the product owner to prioritize the product backlog. Consider two product backlog items that the product owner deems to be of equal value. The product owner will want to do first the item that has the lower cost. The estimates given to items are their costs, and so are used by the product owner to make prioritization decisions.
2. They allow the company to make longer-term predictions. A product owner cannot begin to answer questions like how much can be delivered by a certain date or when a set of features can be delivered without first knowing the size of the work to be performed.

When to Play Planning Poker

Knowing those two reasons for estimating product backlog items is important because it helps answer the question of when a team should estimate. A team should estimate early enough to fulfill these two needs but no earlier than necessary.

Practically, then, this means that a team should estimate with Planning Poker at two different times.

First, a team should play Planning Poker after a meeting like a story-writing workshop in which they have written a large number of product backlog items. I recommend doing such workshops about quarterly.

This allows the product owner and team to identify a larger goal than can be achieved in one sprint, and create the user stories needed to reach the goal.

A typical quarterly story-writing workshop might produce 20 to 50 product backlog items. At a target rate of estimating about 20 items per hour, this could lead to two or so hours spent estimating for each quarter.

The second time a team should play Planning Poker is once per sprint. Some teams will do this as part of a regular product backlog grooming meeting, and I think that’s fine if the whole team participates in grooming.

If the whole team does not participate, another good time to play Planning Poker is following one of the daily scrums late in the sprint. If the team estimates too early in the sprint, there’s a chance they’ll need to repeat the process for any late-arriving stories.

But the team should avoid estimating so late in the sprint that the product owner cannot consider the newly estimated items when deciding what the team will work on in the next sprint.

A Time Not to Play Planning Poker

There’s only one time when I think it’s a mistake to play Planning Poker: at the start of the sprint planning meeting. The first problem with doing it then is that it’s too late for the product owner to adjust priorities based on the new estimates.

Some product owners may be able to rejigger priorities on the fly, but even if they can, they'd probably do so better with a little more time to think.

A second problem with playing Planning Poker to start sprint planning is that it almost always causes the team to spend too much time estimating. I think this happens because team members walk into the sprint planning meeting ready to think in detail about their user stories.

But with Planning Poker, they are asked instead to think at a high-level and put a rougher, less precise estimates on the user stories. Many team members seem to have a hard time giving rough estimates in a meeting in which they will next be asked to give much more precise estimates of tasks.

This leads to more involved discussions than I recommend, and that leads to the team taking longer to estimate than when that is done separately. By following the guidelines here, you’ll be able to help your team estimate at the two times they should use Planning Poker, and avoid estimating at the one time they shouldn’t.

Question: When do you play Planning Poker?