1. Poker Method In Agile Methodology
2. Poker Method In Agile
3. Poker Method In Agile Methodologies
4. Poker Method In Agile Scrum

If you’ve estimated with Planning Poker, you may very well have used cards with either the Fibonacci sequence, or a modified Fibonacci sequence.

The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21 and so on, with each number the sum of the preceding numbers.

Years ago I began having teams estimate with a modified Fibonacci sequence of 1, 2, 3, 5, 8, 13, 20, 40 and 100.

Why?

In simple words, it is a game used to estimate the efforts and hence find the product backlogs. It is consensus-based and used to estimate the user story size in a scrum. A decade before in 2002 James Grenning named this game as estimation poker after some time officially Mike Cohn made this technique popular through his Agile book. Agile Poker is a well-known app for Jira for quick and convenient planning and estimations for both remote and co-located teams. 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.

It’s because numbers that are too close to one another are impossible to distinguish as estimates.

Weber’s Law

Imagine being handed two weights—one is one kilogram (2.2 pounds) and the other is two kilograms (4.4 pounds). With one in each hand but not able to see which is which, you can probably distinguish them. The two kg weight will feel noticeably heavier.

Imagine instead being handed a 20kg weight and a 21kg weight. They are the same one kg difference as the one and two kg weights. But you would have a much harder time identifying the heavier of the two weights.

This is due to Weber’s Law. Weber’s Law states that the difference we can identify between objects is given by a percentage.

Weighing the Difference Between Objects

The difference from one to two kilograms is 100%. You can probably distinguish the weight of items that differ by 100%.

The difference between 20 and 21kg, however, is only 5%. You probably can’t tell the difference. (I know I can’t.) And if you could, it would mean you should be able to distinguish between a 1.00 kg weight and a 1.05 kg weight, as that would also be 5%.

The values in the Fibonacci sequence work well because they roughly correspond to Weber’s Law. After the two (which is 100% bigger than one), each number is about 60% larger than the preceding value.

According to Weber’s Law, if we can distinguish a 60% difference in effort between two estimates, we can distinguish that same percentage difference between other estimates.

So, the Fibonacci values work well because they increase by about the same proportion each time.

Modifying the Fibonacci Sequence

Poker Method In Agile Methodology

Early agile teams I worked with made use of this and estimated with the real Fibonacci sequence. Ultimately, though, we learned that an estimate of 21 implied a precision we couldn’t support. Stakeholders would look at the 21 and be impressed that we called it 21 rather than rounding it to 20 or even 25.

This led us to start using 20 rather than 21. Once we’d deviated from the Fibonacci sequence once, we felt free to do so further.

That led to experimentation in which we introduced 40 and 100. Those worked well because they represented 100% and 150% increases over the preceding numbers. This was much larger than the 62% of the Fibonacci sequence.

This wasn’t a violation of Weber’s Law because Weber’s Law has been shown not to hold at extreme values. Estimates such as 40 and 100 could, perhaps, be thought of as extreme values.

Experimenting with Planning Poker Sequences

Up until 2007, teams I worked with experimented with both the modified Fibonacci sequence and a simple doubling of numbers—1, 2, 4, 8, 16, 32.

Each worked equally well. Most teams had a strong preference for one or the other, but I could find no clear evidence that either sequence was better than the other.

But in 2007, we began printing Planning Poker Cards, which we sold at cost, distributed at various agile events, and that I use in some in-person courses.

To keep printing costs down, I had to choose between these two sequences. At the time, I just slightly favored the modified Fibonacci sequence. And so I made the call to go with that. Once that sequence began to appear on thousands of decks a year, the sequence gained popularity at the expense of simply doubling the values. My slight preference for 1, 2, 3, 5, 8, 13... over 1, 2, 4, 8, 16... came from being in a lot of meetings with the latter sequence in which discussions were always “Is this product backlog item double the size of the other one?”

All discussions were about whether something was double, quadruple, etc. That concerned me slightly because I didn’t see it with teams using the modified Fibonacci sequence. Their discussions were not always “Is this one 60% more effort?” Those seemed like healthier discussions, even though I had no way of measuring that.

These days I remain fairly impartial between the two sets of values. I think teams can estimate successfully with either set of values as each exhibits attributes of Weber’s Law.

What Do You Think?

What’s your experience with different estimating sequences? Which values do you use and do they work for your team? Please share your thoughts in the comments section below.

There’s a lot of chatter about whether or not agile estimation techniques are reliable and realistic. However, they have undoubtedly been popular in the past, and are still very much in the scene.

Traditional vs. Agile Estimation

Let’s begin with what agile estimation is. These are simply estimates for any particular project in hand. Whilst traditional estimations make use of time, some agile estimations prefer to use story points.

Instead of assigning a time estimation for a project, story points are assigned as measures of relative effort. This allows the team to consider other work they know they have to complete simultaneously in their estimations, and the skills of the team relative to each task. Story points don’t measure time-efficiency – they measure problem-solving abilities.

Traditional estimation is a different ballgame and uses methods that follow ‘bottom-up’ estimating. This means that teams inspect each element of a project, estimate the hours or days required to complete, and then use this information to develop a schedule for the project.

Agile estimation techniques use a ‘top-down’ process. This encourages teams to propose a gross-level estimation for how long the project should take, or how much effort it will take. This is then broken up and applied to different elements of the project. Teams drill farther into those elements, uncovering more and more details until the task level – which is looked at through a just-in-time lens.

In this article, we’re going to run through five of the most used agile estimation techniques. We’ll also briefly look at any pros and cons that are worth mentioning.

Agile Estimation Techniques

1. Planning Poker

Poker Method In Agile

Planning poker is an agile estimation technique that makes use of story points to estimate the difficulty of the task at hand. Based on the Fibonacci sequence, the story point values that can be assigned are 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Each of these represent a different level of complexity for the overall project.

Planning poker starts with the team members involved in the estimation process sitting together for the session. Each member holds cards with the story point values described above. The next step is for either a leader figure or the customer to read out the ‘user story’ (which is essentially the project), and describe all the requirements and features.

Poker Method In Agile Methodologies

The stakeholder reading out the story will engage in discussion with the team members who are estimating, who will, in turn, discuss with one another. In this phase, they can ask the customer or owner questions for clarification and express any reservations they have.

When the discussions are finished, all of the estimators will select a card with the story point they believe needs assigning to the project. If the story point estimations match up – then that will be the final estimate. However, if they do not match up, then estimators who gave the lowest and highest points can voice their reasoning, and more discussion will ensue until there is a consensus.

This technique is not good for large teams, or when there are a large number of items that need estimating. If you only have a selected number of items (between 2 and 10) and a small band of teammates, then this is a good technique to use. It’s also one of the most popular estimation techniques.

2. T-Shirt Sizes

If you think about T-shirts, there are multiple sizes to choose from. More specifically – there is extra-small (XS), small (S), medium (M), large (L) and extra-large (XL). This technique uses these sizes as story points for the size of the project, and it is a useful way of thinking when estimation needs to occur.

This is a useful method for being time-efficient. It can give a quick and rough estimate for how much work is expected for a project. The sizes can be converted into numbers at a later stage – when the team assigns a relative size to the project on hand. This is decided through discussion and collaborative efforts to understand everything that needs to be done.

If estimators propose sizes that do not match up, then the team voices their opinions on the topic and must eventually reach a consensus.

This is a pretty informal method that is great to use for a large number of items. Unfortunately, story points can be tricky. What might seem one size to one person could be perceived as another by someone else. Whilst this can create some confusion, this method is based on open discussion, and everyone should get the chance to have their say.

3. Dot Voting

Sometimes it can be hard to order the items in the product backlog. This ranking method enables you to sort these items from highest to lowest priority, so you know where to focus your efforts. To do this, you need to select the most important user stories.

Start by posting all of the stories you need to deal with on a wall somewhere (or a board, if you’re feeling more conventional). The posts should contain the story description and should look unique so that they are easily distinguishable to voters.

Team members involved in the process are all given 4 to 5 dots to dole out. The use of stickers or markers can be effective for this process. Team members place these dots on the user stories that they would prefer to start working on and distribute them throughout the options.

A leader then orders the stories from most preferred to least preferred (most preferred would be the story with the most marks or dots on it). If there is any stakeholder who is not happy with the order, then the items are divided into three groups – high, middle and low priority. Team members vote on the high priority stories again until they reach a consensus.

This is not necessarily an agile estimation technique – it’s more of a decision-making tool. But if you have a small number of items – it can be very efficient. It’s also really simple and is a good visualization tool.

4. The Bucket System

This method relies on placing different values on a table. We call the placements ‘buckets’, but you can just use cards. The values are generally 0,1,2,3,4,5,8,13,20,30,50,100 and 200 – although these can be expanded if necessary.

Estimators need to take stories and collectively choose which buckets each item falls into. To do this, place cards with the items written on them into the buckets. Before placing each item, it is important to have discussed the features and requirements of each with the estimator team. All items must be assigned and placed in the buckets upon consensus.

The buckets can also be changed and rearranged if the group feels it necessary to reassign an item. There is a ‘divide and conquer’ phase after assigning important items. Estimators get the remaining items and can place them in buckets that they believe the items should sit in – without consensus.

If a participant does not understand a story, it can be transferred to someone who does. If someone does not agree with a certain item placed in a specific bucket, further discussions takes place to agree on where to place the item and why. This ‘sanity check’ is critical to this process.

This method is more time-efficient and reasonable than Planning Poker. It is a great agile estimation technique to use if you have a large number of items and a big team.

5. Affinity Mapping

Poker Method In Agile Scrum

Firstly, silent relative sizing needs to occur. To prepare for this, place two cards on opposite sides of a wall. One should say ‘small’ and the other should say ‘large’. The leader (or product owner) needs to provide each estimator with a subset of items and should remain present during the process to clarify anything. Estimators then place the items on the wall, relative to each item’s perceived size. The size depends on the effort expected to complete them. There is no discussion at this point.

Team members can then change the location of wall items, discussing as they go. Once teams finish editing the wall, they can finalize product backlog items in their positions. However, just before this, the product owner may step in if they spot a discrepancy between what the team members have estimated in comparison to their ideas.

Using a project backlog management tool can help ensure that the finalized estimations are saved. This is a good technique to use for a smaller team. Also, if you have a large number of backlog items, this is a bad choice. You might find it to be time-consuming with too many items.

Join 60,000+ Subscribers

For latest blogs, industry updates and exclusive tips.

*Your email is safe with us, we also hate spam