Poker Planning Approach
One pitfall of Planning Poker resides in making “convergence to consensus estimate” an obligation rather than a natural result of the conversation that follows a round of play. Doing so runs the risk of erasing useful information, i.e. The degree of uncertainty conveyed by a wide spread in the initial estimates. Planning Poker Estimation Planning Poker is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in Scrum. Planning Poker combines three estimation techniques − Wideband Delphi Technique, Analogous Estimation, and Estimation using WBS.
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.
Poker Planning Approach Strategies
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.
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.”
Poker Planning Approach Plan
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:
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:
- “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.
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?