Planning Poker Estimation Technique and Story Points

Inaccurate estimates are among the most popular project management challenges. Starting a new IT project you want to know two things: how long is it going to take and how much is it going to cost. To answer these questions — you have to estimate the projects you’re about to run. There is no magic rule that says that project X takes 12 weeks and costs $150,000. Or that a Y-like website takes 10 weeks to develop and costs $100,000.

What you will learn from this article:

• How do project managers prepare for cost estimation in project management
• Which one estimation techniques are useful for project estimation
• How to prepare yourself to estimate costs with formulas

You can’t assess that without thorough estimation, even if the project’s scope is very similar to what you’ve done before. Yet, things get worst: Estimation will never give you a 100% accurate answer to these questions as well. So, why do we estimate?

Because it’s the only way to make assumptions about the project’s timeline and budget, the workload, and the resources needed to deliver it. Estimating the project, you’re also able to schedule employees with the right experience and skillset.

What you can do about it is to use methodologies and techniques that’ll let you estimate with the maximum accuracy possible.

Here’s how to use the Agile methodology and Planning Poker technique to create meaningful estimates of your project.

Create a list of required features

Starting a successful project relies mostly on how well you understand what it is actually about. That includes:

• Understanding the expectations of your client
• Understanding the objectives of the project and its main goal
• Creating a list of required features

Once you have gotten through the client’s brief and have as much information about the project requirements as possible, you’re able to list all the features and pass them to your team.

In order to do so, create a product backlog that consists of all the to-do features. You can then prioritize them, evaluate their complexity and estimate how long it will take to complete them.

A proper product backlog should consist of:

• User stories — describe the actions that user can take at every step of using the product
• Acceptance criteria — list the items needed for a story to be completed
• Story points — estimate the amount of work, risks, and complexity in relative point value (I’ll get to that later in this article)
• Tasks for user stories — list the tasks needed to be done in order to deliver a user story

Sort features by priority

With a list of features ready, assign priority to each one of them. You can use the MoSCoW analysis method to sort them as:

• Must have
• Should have
• Could have
• and Won’t have

Developing a project, focus on things you have to deliver in the first place.

Building an MVP gives you the possibility to test hypotheses about your idea before completing the whole project, show it to stakeholders or beta users, and collect feedback important for further development of the rest of the features.

Assigning priority can also help you with estimating the project. As you focus on the main features and the ones that you need to do first, you can make more accurate assumptions about their estimated completion.

For “could have” features you can start with a ballpark estimation, as they are further in the development process and a lot can change by the time your team gets to them (and if your team gets to them, as after collecting feedback about your MVP you can pivot and not include all of the initially planned functionalities).

It is important, however, to estimate all the features, regardless of their priority (except the “won’t have” ones, of course), as you want to get an overview of the whole project at once.

And as you get to the next stages of the project, you can re-evaluate the scope of work, to make sure your estimates remain accurate.

Looking for more expert tips on project management? Check out our FREE sprint planning checklist now!

Story point estimation process

Now that you have your product backlog completed, it’s time to estimate each one of its items. To do so, we use story points. They are units Agile teams use to evaluate the work needed to complete each item from the backlog.

Story points help to assign relative value to the product backlog items. They are not related to time and can bear different values to different teams, so they don’t carry the emotional value. Thus, chances are that team members won’t pad the estimates just to be safe.

Using story points, a team can estimate:

• The amount of work to do
• Risks and uncertainty
• Complexity

In the next step, I’ll show you how to use Planning Poker (aka Scrum poker) to assign story points to each user story from the product backlog.

Negotiate estimates with Planning Poker

Planning Poker is one of the gross-level estimation techniques, using a modified version of the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100.

To estimate items from the product backlog, team members get the same sets of cards with numbers on them. Then, after a brief introduction of the product backlog item by the Product Owner (who doesn’t vote) and the discussion, they privately pick the card with the number of story points they consider relevant to the amount of work required to complete this item and reveal them at the same time.

If the numbers differ, team members discuss why they’ve chosen such an amount of story points, and then vote again. They do so till they reach a consensus and then move on to the next item from the product backlog.

And if the number agreed on is high, let’s say 20, 40, or higher, it means that a story may require too much work for one sprint and may need to be broken down into smaller tasks.

Ideally, the presentation of the item, discussion, and voting should take around two minutes, which allows for estimating the whole backlog in a short amount of time. But as the point here is to estimate the whole backlog at once, take your time, and don’t worry when some stories take a little bit longer to assess.

It’s called a consensus-based estimation technique, as by not saying the numbers but revealing them at once using cards, the influence of other team members is being avoided and the estimations are considered more accurate.

Assess team velocity

Team velocity shows you what is the pace of the project development. It helps with understanding two things:

• What amount of work your team is able to do in one sprint
• What is the predicted date of finishing the whole scope, assuming that it’s fixed

The velocity is different for every team. You can assess it after the initial iterations when your team has already worked on some features.

For example, if you’ve included four product backlog items in the first iteration for a total number of 20 story points, and the team finished three of them equaling 15 story points, this is your team’s current velocity.

Remember that only completed items count. Even if they’d managed to start the fourth item, but haven’t finished it, it doesn’t count.

How to schedule a particular project on story points

After negotiating story points and assessing team velocity, you’re able to determine the project’s schedule.

To do so, add up team velocity from the last three iterations and divide it by three. For example, if the velocity from those iterations was 20, 23, and 17, the average velocity would equal approximately 20 points. If the total amount of work had been estimated on 100 story points, then, with the average velocity of 20 points, it would take 5 iterations to complete the project. Assuming that one iteration takes two weeks, you should deliver the project in 10 weeks.

Determine the budget – project cost estimation formula 

To determine the budget of your project, you can use this basic formula:

(total Story Points / Velocity * team hours per sprint) + non labor costs = estimated budget

Having a total number of story points divided by the average velocity, multiply the number of sprints by 40 hours per week per team member to get your labor cost. Then add the non-labor costs like capital costs, equipment costs, maintenance costs, training costs, etc.

For example, we have a project estimated at 100 story points and our team’s average velocity is 20. Assigning 5 people team to the project with $50 hourly rates, the team hours per sprint are worth $20,000 and $100,000 for 5 sprints. With a hypothetical non-labor cost of $50,000, the estimated budget for our project would be $150,000.

Considering the confidence intervals on exemplary levels of 80–120%, the reported range of our budget is now $120,000 to $180,000.

Re-estimate your project to get a more accurate cost estimate

Remember that no estimation is 100% accurate. It’s best to re-estimate your project every few iterations, as things, like resource availability, team velocity, or project’s scope, may change over time.

Re-estimating, you’re making sure that your estimate is up to date.

Using time tracking and resource scheduling software will also help you manage your team’s availability, and to reassign them, if needed. With the right techniques and tools, you can make your estimates more reliable and better plan your next project.