Using Zoom polls for planning poker in Agile teams

Planning poker cards
Planning Poker cards from Mountain Goat Software

A couple of years ago, I wrote a post about using planning poker in Agile teams, for estimating user story size. But that was when we were all sitting in the same room and not shielding from Covid-19.

Things have changed now. Here are a few options that I’ve tried.

Continue reading Using Zoom polls for planning poker in Agile teams

What are story points?

Photo by Danka & Peter on Unsplash

In his book Agile Estimating and Planning (Prentice Hall, 2006), Mike Cohn tells us that “story points are a unit of measure for estimating the overall size of a user story, feature, or other piece of work.” (p. 36)

Over the years, I have found that one of the trickiest agile concepts for people to understand is story points.

When it comes to estimating how long it will take to complete a chunk of work, agile adopts a very different approach to traditional project management which uses tools like Gantt charts where tasks are estimated in time (e.g. hours, days, weeks).

Humans are notoriously bad at estimating how long something will take. In 1979, Daniel Kahneman (author of the excellent Thinking Fast and Slow) and Amos Tversky proposed a theory they called ‘planning fallacy’. In short, they noted that when you estimate your own tasks you tend towards underestimating (displaying an optimism bias), and when you estimate the tasks of others you tend towards overestimating (displaying a pessimism bias).

Agile tries to get around this by estimating effort using story points rather than time. The reason is that many people can agree on relative effort without agreeing on absolutely time. Let me give an example.

Mountain of an example

Imagine you are interested in hill walking. You and a friend decide that you want to use story points to classify different hills and mountains according to the effort required to climb them.

But it’s not just about the physical effort required to walk to the top. You also want to take into account the complexity of the ascent (how easy is it to reach the starting point, any difficult terrain, will you need any specialist equipment, etc.) and any risks and uncertainty involved (changing weather, wind conditions, or sheer drops, for example).

The first hill you decide to climb the Eildon hills (1,385 ft) near Melrose in the Scottish Borders. It’s a strenuous but simple walk, you don’t need any specialist equipment and you could do it easily in a couple of hours, even on a rainy day. Weighing up the effort involved to climb it, the complexity of the climb and the risk and uncertainty that is presented, you decide to classify that hill as 1 story point.

The following week, you fancy a bit more of a challenge and so you decide to ‘bag’ your first Munro, a Scottish mountain over 3,000 ft. You choose to tackle The Cairnwell at Glenshee, at 3,061 ft. You’ve been told that it’s one of the easier Munros to conquer so the complexity isn’t much more than the Eildons. The risk and uncertainty also remain largely unchanged. The biggest difference is effort. All in all, it’s about twice the size of the Eildons so combining physical effort, complexity and risk you classify it as 2 story points.

Next you decide to tackle Scotland’s largest munro, and the tallest mountain in Great Britain. Ben Nevis (or Beinn Nibheis for the Gaelic speakers among us) stands at 4,411 feet above sea level. It’s around 1,400 feet taller than The Cairnwell, so perhaps you consider classifying this as a 3. But then you start to do more research. While Ben Path is the simplest route, the presence of running water, uneven rocks and loose scree makes it a more complex and risky ascent. You take into account the uncertainty of the weather; there is a risk of fog and snow. Then you read that there were 108 mountain rescue call-outs in 2018. As you are using the Fibonacci sequence for your classifications you settle on a 5 story points for Ben Nevis.

Story points are relative

One of the benefits of using story points to estimate the size of tasks is that it allows you to estimate them relative to one another.

What matters most is the ratio, not the numbers. We could have chosen to classify our hills as a 4, 8 and 20, or a 100, 200 and 500.

You may not be in a position to immediately know exactly how long (in minutes or hours) something will take to do, but it should always be easier to estimate whether it would take more or less effort than a similar task you have already completed.

As we’ve seen in the hillwalking example above, the total effort is a function of effort plus complexity, risk and uncertainty. Whether you are a seasoned mountain climber or a complete amateur, you could both agree that the munro would take twice as long to climb as the Eildon hill. What would be different for each party is the time taken to climb each.

For the keen amateur, it may take him six hours to climb and descend Ben Nevis; while the seasoned pro may do the same route in two hours. Same number of story points, different durations.

The same is true for software development teams. Two teams might both estimate a particular user story to be three story points but if team A has worked on this kind of task before and is comprised of experienced developers who have worked together for a year or more, they might complete it in a a few hours. Whereas the newly-formed team B, which has a few graduates and junior developers, may take a day and a half to push that story through to done.

Don’t compare teams

What is important, though, is to not compare at face-value the estimates of two teams.

“A nice feature of story points is that each team defines them as they see fit.” writes Mike Cohn in User Stories Applied (Addison-Wesley, 2004), p.87.

So, one team’s 3 may be another’s 8. The important thing is that are consistent. It doesn’t matter if you measure your office furniture using centimeters, inches or square Post-it notes, so long as you use that scale for all your measurements.


That is the beauty of using story points. Stories are estimated relative to one another, taking into account effort, complexity, risk and uncertainty but how long they take to finish will vary for different teams.

Ultimately, story points are about time but they are not about hours. It’s a subtle distinction but a very useful one.

Originally published on the Vision internal blog.

Planning poker—why and how we estimate

Planning poker cards
All the tools you need to become an Agile planning ninja

When creating a plan—whether it be a big project release plan or a smaller two-weeks’ timebox plan—you essentially need to know three things:

  1. Tasks —What are the requirements? What do you need to do?
  2. Size — How big are these tasks compared with one another? How long will these take to complete?
  3. Priorities — Which tasks need to be done first because others depend on them? Which tasks are most important regardless of dependencies?

It’s very much like creating a recipe: assemble the right ingredients, measure them to the correct proportions, and then mix them together in the right order.

In an Agile project the prioritisation of tasks is done by the business. It is their project after all; they have the most information about value, they understand the market, they have an idea of what features should be delivered next. Prioritisation is not a decision to be made by the development team.

The size of each task, however, is something that the development team is qualified to estimate. If I want a new wall built in my garden whose estimate should I trust more: mine (the person who commissions the work) or the builders (who do this job day-in, day-out for a living)?

When planning, we use a tool called planning poker to help estimate the relative size of tasks.

Continue reading Planning poker—why and how we estimate