Planning Poker Approach

1. Planning Poker Approach Techniques
2. Planning Poker Cards
3. Planning Poker Technique
4. Planning Poker App
5. Planning Poker Free

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.

The Archiver Open Marker Consultation events will be moderated by ADDESTINO using a 'planning poker' technique. It consists in a “best practice” workshop moderation technique, used for estimating value, complexity, required effort etc., based on expert-estimation and consensus. During the workshop, each use case or topic is scored individually, where all participants are asked. Planning poker (also known as Scrum poker) is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. Scrum Planning Poker. Steps for Planning Poker. To start a poker planning session, the product owner or customer reads an agile user story or describes. Planning poker, also called Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development.In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. Planning Poker® is the fun, easy way for your team to effectively plan and execute a sprint planning session. This free online scrum tool encourages collaboration and planning for distributed agile teams. Through lively discussion, your team will create more accurate estimations for healthier sprints.

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?

A well-established best practice is that those who will do the work, should estimate the work, rather than having an entirely separate group estimate the work.

But when an agile team estimates product backlog items, the team doesn’t yet know who will work on each item. Teams will usually make that determination either during iteration (sprint) planning or in a more real-time manner in daily standups.

This means the whole team should take part in estimating every product backlog item. But how can someone with a skill not needed to deliver a product backlog item contribute to estimating it?

Before I can answer that, I need to briefly describe Planning Poker, which is the most common approach for estimating product backlog items. If you are already familiar with Planning Poker, you can skip the next section.

Planning Poker

Planning Poker is a consensus-based, collaborative estimating approach. It starts when a product owner or key stakeholder reads to the team an item to be estimated. Team members are then encouraged to ask questions and discuss the item so they understand the work being estimated.

Each team member is holding a set of poker-style playing cards on which are written the valid estimates to be used by the team. Any values are possible, but it is generally advisable to avoid being too precise. For example, estimating one item as 99 and another as 100 seems extremely difficult as a 1% increase in effort seems impossible to distinguish. Commonly used values are 1, 2, 3, 5, 8, 13, 20, 40, and 100 (a modified Fibonacci sequence) and 1, 2, 4, 8, 16, and 32 (a simple doubling of each prior value).

Once the team members are satisfied they understand the item to be estimated, each estimator selects a card reflecting their estimate. All of the estimators then reveal their cards at the same time. If all the cards show the same value, that becomes the team’s estimate of the work involved. If not, the estimators discuss their estimates with an emphasis on hearing from those with the highest and lowest values.

If you aren’t familiar with estimating product backlog items this way, you may want to read more about Planning Poker before continuing.

Planning Poker Approach Techniques

How Can Someone Participate Without the Needed Skills

Equipped with a common understanding of Planning Poker, let’s see how a team member can contribute to estimating work that they cannot possibly be involved in. As an example, consider a database engineer who is being asked to estimate a product backlog item that will include front-end JavaScript and some backend Ruby on Rails coding, and will then need to be tested.

How can this database engineer contribute to estimating this product backlog item?

There are three reasons why it’s possible--and desirable.

1. Planning Poker Isn’t Voting

When playing Planning Poker, participants are not voting on their preferred estimate. The team will not settle on the estimate that gets the most votes. Instead, each estimator is given the credibility they deserve. If one programmer wrote the original code that needs to be modified and happened to be in that same code a couple of days ago, the team should give more credence to that programmer’s estimate than to the estimate of a programmer who has never been in this part of the system.

This means that each team member can estimate, but that the team will weigh more heavily the opinions of those more closely aligned with the work.

Planning Poker Cards

2. Estimates Are Relative and That’s Easier

In Planning Poker, the estimates created should be relative rather than absolute estimates. That is, a team will say things like, “This item will take twice as long as the other item, but we can’t estimate the actual number of hours for either item.”

For example, this blog post contains one illustration. I provided my artist with a short description of what I had in mind for an image and he created the illustration. Most of my blog posts have one title illustration. Even though I have no artistic skill, I could estimate the work to create those illustrations as about equal each week.

Sure, some illustrations are more involved, and others can reuse a few elements from a past illustration. But most are close enough that I could estimate them as taking the same effort.

But some blog posts have two images. Even though I have no design skills at all, I’m willing to say that creating two images will take about twice as long as creating one image.

So a tester is not being asked to estimate how many hours it will take a programmer to code something. Instead the tester is estimating coding that thing relative to other things.

That can still be hard but relative estimates are easier than absolute estimates. And remember that because of point one above, the person whose skills may not be needed on the story will not be given as much credibility as someone whose skills will be used.

3. Everyone Contributes, Even If They Don’t Estimate

I want everyone on the team to participate in an estimating meeting. But that does not mean everyone estimates every item.

Despite relative estimating being easier than absolute estimating, there will still be times when someone will not be able to estimate a particular product backlog item. This might be because the person’s skills aren’t needed on that item. But that person may still be able to contribute to the discussion.

Sometimes the person whose skills are not needed on a given product backlog item will be the most astute in asking questions about the item, uncovering overlooked assumptions, or in seeing work that others on the team have missed.

For example, a database developer whose skills are not needed to deliver a product backlog item may be the one who remembers that:

Planning Poker Technique

The team promised to clean up that code the next time they were in it

There is an impact on reports that no one has considered

That when the team did a similar story a year ago it took much longer than anyone anticipated

and so on. The database developer may know these things or ask these questions even if unable to personally estimate their impact on the work.

A Few Examples

To provide a few examples, let’s return to role of a database engineer in estimating a product backlog item that has no database work. Here are some examples of things that team member might say that would add value to estimating that product backlog item:

Planning Poker App

• “I’m holding up this high estimate because this sounded like a lot of effort to code. It sounded like about twice as much as this other backlog item.”
  In this case, the database engineer is making a relative assessment of effort. This will presumably be based on things said by coders. In some cases, the database engineer may be wrong in that assessment. But that doesn’t mean the person’s opinion is always without merit. The database engineer’s opinion should be given the merit it deserves (which may be great or little).


• “Are you sure it’s that much work? I thought two sprints ago, you programmers were going to refactor that part of the system. If that happened, isn’t this easier now?”
  Here the database engineer is bringing up information that others may not have recalled or considered. It may or may not be of value. But sometimes it will be.


• “Are you sure it’s not more work than that? Have you considered the need to do this and that?”
  In this case, the database engineer is pointing out work that the others may have overlooked. If that work is significant, it should be reflected in the estimate.

When Everyone Participates, It Increases Buy In

There’s one final reason why I suggest the whole team participate when estimating product backlog items, especially with a technique such as Planning Poker: Doing so increases the buy in felt by all team members to the estimates.

Planning Poker Free

When someone else estimates something for you or me, we don’t feel invested in that estimate. It may or may not be a good estimate. But if it’s not, that’s not our fault. We will do much more to meet an estimate we gave than one handed to us.

We want everyone on a team to participate in estimating that team’s work. You never know in advance who will ask the insightful questions about a product backlog item. Sometimes it’s one of the team members who will work on that item. But other times those questions come from someone whose skills are not needed on that item.

So while not every team member needs to provide an estimate for each item, every team member does need to participate in the discussion surrounding every estimate. Teams do best when the whole team works together for the good of the product, from estimation through to delivery.

What Has Your Experience Been?

What has your experience been with involving the whole team in estimating product backlog items? Have you found it beneficial to have everyone participate even though not everyone has skills needed on each item?