Approaching Estimation With Estimation Poker

In a world with unlimited time and budget, we could certainly do away with estimates. Nobody likes them. They’re more wrong then they are right – everything takes longer. Our teams would experience more joy and more productivity because we could all truly focus on doing our best work rather than fretting over unknowns that pop up. No one would miss the feeling that comes when the Scrum Master stares you down and asks “Will you commit to that?”.

As Matt points out in Why You Should Do Software Estimates, estimating is hard in part because estimates will never be perfect. There are times they are spot on, but the nature of an estimate is that it’s a rough approximation, an educated guess, and sometimes it’s not even educated – it’s just a guess. But we should still do them.

This post is going to take a brief look at how to think about estimates and the act of estimating using a technique called Estimation Poker.

If you’re familiar with Estimation Poker feel free to skip the next section.

The Basics Of Estimation Poker

Estimation Poker, colloquially known as Planning Poker® (trademark of Mountain Goat Software), is a team-based technique that relies on a deck of cards. Every member of the team gets the same set of cards and they use the face value of each card as estimates. What these values mean to your team is up to your team. They may represent a unit of time such as hours or days, a dimensionless unit such as t-shirt sizes, or even a unit for measuring complexity known as points.

There are special Estimation Poker decks that exist with units printed on each card. For example, one deck is based on the Fibonacci sequence and has the cards with each of the following values: 0, 1, 2, 3, 5, 8, and 13. Another deck has powers of 2: 0, 1, 2, 4, 8, 16, and 32. And yet a third deck doesn’t use numbers at all. It uses t-shirt sizes: XS, S, M, L, XL.

Specialized decks are nice, but you don’t need them. A traditional deck or two of playing cards will work perfectly. Just remember to take out some cards so you don’t end up with a linear list like A, 1, 2, 3, 4, 5, 6, 7, 8, etc. This is so the estimation scale reflects the reality that as estimates go up so does the uncertainty/unknowns that accompany them. For example, a verbiage change on the signup page has less uncertainty and requires less effort than implementing the feature giving users the ability to upload files to their virtual folders.

A regular interval for estimation is during an Iteration Planning Meeting (aka Sprint Planning Meeting). The Product Owner will have a set of items (e.g. stories, etc) that they have prioritized for the upcoming iteration/sprint. The Product Owner will pick one item at a time (usually from the top of the list assuming that represents the highest priority item) communicating to the team what the work is about, who it’s for, and its acceptance criteria.

If there is any associated UI work, a designer will usually walk thru any wireframes, mockups, or a prototype to describe both the design and intended interactions.

The team then takes a moment to digest and to ask any questions. A short discussion ensues if necessary, then the team estimates by having each person who could be involved in doing the work will put their estimate on the table, face down. When everyone has put their estimates down the team flips the cards.

The team will either all be relatively close in their estimation or there will be variation. Otherwise, the estimate is recorded and the Product Owner begins discussing the next item.

For more information on the practice of estimating be sure to check out our Estimation Guide.

Estimation Poker frames estimation in a helpful and honest way

A common misconception is that estimates are commitment dates. Even when not explicitly stated as such, they’re often treated that way. The problem with this is that it doesn’t match up with reality. It causes a lot of unnecessary friction because they’re never right. This is not an honest or helpful representation for the team or the stakeholders.

If we reinforce this misconception within our teams through interactions or communication then we’re in for a lot of hurt, frustration, and disappointment.

The trick is to think about estimates as they are: rough approximations with assumptions, uncertainties, and unknowns. If we expect estimates to have these characteristics then we can shift our focus from “Why is this late?!” to “What assumptions do we have and how can we validate/invalidate them as quickly as possible?” By doing this our mindset shifts away from assuming certainty to trying to identify how to remove uncertainty as soon as possible.

Estimation Poker helps frame estimation this way by acknowledging that uncertainty exists and increases as the perceived amount of effort increases. The non-linear estimation scales are a way to reinforce this.

Estimation Poker is a conduit for surfacing assumptions, complexity, and risk

Estimation Poker is usually done when the whole team is present even though not everyone participates in estimating.

One benefit of this is that everyone hears first hand about the assumptions, perceived complexity, and risks of each item. Once this information is out there it puts the team as a whole in a better position to make decisions.

If the Product Owner knows that a particular feature has a lot of unknowns, but it’s a high value feature, they may want to frontload that work in order to eliminate the risk later on.

If the Project Manager knows that developers are worried that IT won’t be ready to integrate in time then they may be able to facilitate conversations early on to identify if that’s a valid concern. If it is, the Product Owner might prioritize other work.

If designers know that developers find an intended interaction really complicated to build they may be able to suggest another interaction or follow up with questions that help remove unnecessary complexity.

An outlier estimate may surface when a developer has never worked on that part of the system before. This provides the opportunity for a teammate to step up and offer to pair on that. This reduces unknowns while transferring knowledge.

Estimation Poker provides a natural way for assumptions, complexity, and unknowns to surface throughout the team. The team is then allowed to quickly incorporate important information and work more effectively together.

Estimation Poker elicits honest opinions

When doing Estimation Poker, everyone puts their estimates face down until everybody has estimated, then the cards are turned over to reveal the estimates.

When doing Estimation Poker, everyone puts their estimates face down until everybody has estimated, then the cards are turned over to reveal the estimates. This blind estimation avoids any bias or unnecessary influence from others on the team. I may be thinking the current item we’re estimating is an 8, but if I see Matt give it a 3, I might be inclined to prematurely deflate my estimate.

This outcome is not bad, but we want that outcome to happen after we discuss why I thought it was more complex and why Matt thought it was less complex. I may be forgetting about previous work we’ve done that makes this simpler or Matt may not be considering an area of complexity that I see. Once this conversation takes place, we can re-estimate. Otherwise we prematurely take away the opportunity for the discussion to happen in the first place.

Estimation Poker gives everyone a voice

Because estimates remain face down until everyone has estimated, everyone’s opinions are treated equally at the outset. This gives everyone a voice and helps avoid a dominant personality taking over.

But what if we move straight to the conversation before estimating? If the conversation is what we want why not streamline the order of things so it happens first?

My colleague Mike Doel likes to say that the trouble teams encounter is estimates that are biased towards the extroverts and people unafraid to make their voices heard. By placing the estimates face down initially it ensures that those who are reluctant to speak up are called on to participate.

Estimation Poker is a catalyst for what to talk about

Let’s say we just estimated a feature and the estimates were: 3, 3, 1, 3, 3, and 8. What should we talk about first?

In our experience, the best things to talk about are the outliers: the 1 and the 8. This discussion will have the effect of raising the 1, lowering the 8, or changing the 3s.

While the opinions of the 3s are important their contribution will come out naturally as part of the conversation around the 1 sharing why they think the work is such little effort or why the 8 finds the work to be so complex.

In this way, Estimation Poker can be a catalyst for a better conversation sooner and avoiding the drudgery of rehashing all of the things we already all agree on.

Estimation Poker is quick

The goal of Estimation Poker is to identify a shared sense of effort and unknowns involved in a particular area of work (features, bug fixes, etc). It is not to diverge into discussions of architecture or detailed implementation.

When the team shares this perspective they can self-regulate and help each other identify the relevant assumptions or questions that are an obstacle for an estimate. This makes producing a collective estimate (or sending it back to be broken down) quick.

Don’t get stuck verbally implementing

A common pitfall is that teams get stuck discussing implementation details during the Estimation Poker session. This can easily lead to a discussion that has gone astray, living far beyond its usefulness.

When this happens it can be helpful to refocus the team by shifting the focus back to what’s necessary for the desired outcome. This is often as simple as asking:

• I hear you saying that ______ is an assumption that needs to be validated. If it turns out to be true would it change your estimate? If so, should we do a spike first?

• I hear you saying that ______ is complicated because it deals with X (e.g. third-parties, parts of the system the team isn’t familiar with, etc.). Does anyone on the team have knowledge in with X? If so, can you pair with somebody on that? If not, do we need a spike to answer some unknowns about X?

• I hear you saying that ______ is a lot of work so it’s hard to estimate it all at once. Would it be helpful to break this work down into smaller pieces and estimate separately?

These questions are not meant to be exhaustive. Hopefully, they are illustrative in ways to refocus the discussion.

Estimation Poker works whether the team is in the same room or distributed

Physical cards work great when the team is co-located, but they also work when the team is distributed. All you need is a Google Hangout or some other video-chat. Teammates can hold up their estimates and turn them around once everybody’s are up.

There are also digital estimation poker tools. There are a number of iOS and Android apps for use on your phone (although many of them are standalone decks). There’s even http://planningpoker.net which allows everyone to use a shared web site to enter their estimates.

In the end

We live in a world of assumptions and unknowns; we build technology that is similar, but never the same; we work on teams whose collective knowledge base changes every single day; we depend on systems that we don’t control. There are a lot of uncertainties in life yet somehow the world still functions and evolves despite our inability as humans to accurately predict the future, let alone estimate it.

The art of estimation is not about perfection. It’s about collectively surfacing risk in a way that allows the team to bring to life possibilities that didn’t exist yesterday. All while being cognizant of the very real time and budget constraints that do exist.

Estimation Poker is a tiny practice in the scheme of things, but it is one way in which we can shift our perspectives to allow for both past experiences and future unknowns to coexist.

A Guide to Estimation and Velocity

If you are feeling the pressure of hitting a deadline or accurately estimating your budget, this free guide can help you.