Quote card for 3 Roles That Need to be Involved in Agile Estimating with Planning Poker.

3 Roles That Need to be Involved in Agile Estimating with Planning Poker

When estimating your product backlog with Planning Poker, it’s important to have the right people participate. Let’s go over who needs to be there, and what the job of each is during an agile estimating meeting.

First, of course, we start with the team. All of a Scrum team’s members should be present when playing Planning Poker. You may be tempted to estimate without the individuals in some role—don’t.

An estimate put on a product backlog item (most frequently a user story) needs to represent the total effort to deliver that item. It’s not an estimate of all the work except database changes or all the work except testing.

Those individuals need to be there because they’re needed to deliver many of the product backlog items. They’re also there because they will often have something to contribute to discussions of work they may not directly be involved in.

I’ve seen many examples when a comment by a tester about his or her own work made a programmer realize he overlooked something in his own work.

Programmers are, of course, the best at estimating programming work. And testers are best at estimating testing, and so on. But that doesn’t mean someone with a specialty in one skill won’t have something to add in a discussion about something that will be done by someone else.

Also in a Planning Poker meeting will be the ScrumMaster. A team’s ScrumMaster is its facilitator, and so the ScrumMaster should participate in all regularly scheduled meetings, and a Planning Poker session is no exception.

But should the ScrumMaster estimate alongside the rest of the team? If the ScrumMaster is also a technical contributor such as a programmer, tester, designer, analyst, DBA, etc., then definitely.

By right of contributing in that way, the ScrumMaster holds up a Planning Poker card just like the others.

However, a pure ScrumMaster should estimate only by invitation of the rest of the team. If the others say, “Hey, we have to estimate, why don’t you?” then the ScrumMaster holds up a card each round.

A ScrumMaster who has a solid technical background (in any role) will be especially likely to estimate along with the others.

That brings us to the product owner—and, yes, by all means the product owner needs to be present during any Planning Poker estimating session. The product owner describes each item to the team before they estimate it.

Also, team members will have questions—“what should we do if … ?” “What if the user does … ?”—and the product owner needs to be present to answer those questions.

Product owners, however, generally do not hold up cards during Planning Poker sessions. However, my official answer is the same as for the ScrumMaster: if the team invites the product owner to estimate, the product owner should do so. This is pretty rare, though, and it’s far more common for a ScrumMaster to be invited to estimate.

So, like many things in Scrum, Planning Poker is a whole-team activity.

Guide

Planning Poker

Featured

Planning Poker is a collaborative technique agile teams use to estimate product backlog items. It works because it combines independent thinking with team discussion.

Article artwork for Why the Whole Team Should Participate When Estimating.
Article

Why the Whole Team Should Participate When Estimating

Featured

Even though not everyone may work on a product backlog item, it’s still worth having the full team estimate. Here’s why.

Triangulate for better agile estimates. A new estimate is put forward for consideration. To decide if The Estimate Is Right, the team can compare the new estimate against an existing smaller estimate and and existing larger estimate.
Article

Automatically Triangulating Estimates in Planning Poker

Featured

Compare new estimates with known stories to keep Planning Poker results consistent.

An agile coach and team discussing their work together.
Coaching

Estimating & Planning

Improve estimates, forecasts, release planning, and conversations about scope, timing, and risk.

Text graphic: Estimate at the right time and level of detail.
Article

When Should We Estimate the Product Backlog

Estimate backlog items at the right time and level of detail.

Agile teams learn from spikes: time-boxed research activities
Article

Agile Spikes Deliver Knowledge So Teams Can Deliver Products

Use spikes to reduce uncertainty and learn enough to move product work forward.