Many agile teams around me use “planning poker” to estimate story points. Although this method is popular, it also has its limitations. For example: The function to be estimated is too large, and it is not easy to estimate with “planning poker”; 300 stories come out; The user story to be estimated does not have enough information for. How does planning poker work – Steps in detail. This is an agile planning poker scrum activity. Every estimator will have a deck of cards and begin with the exercise. Figure 2: Steps involved in a planning poker game The participants are the moderators in the scrum poker.

Starting a new IT project you want to know two things:

• How long is it going to take?
• How much is it going to cost?

To answer these questions — you have to estimate 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 an Y-like website takes 10 weeks to develop and costs $100,000.

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 project’s timeline and budget, the workload and 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 maximum accuracy possible.

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

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.

Scrum Planning Poker

A proper product backlog should consist of:

• User stories — describe the actions 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

Scrum Planning Poker Story Points Template

With a list of features ready, assign the 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 a possibility to test hypotheses about your idea before completing the whole project, show it to stakeholders or beta users, and to 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.

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.

Planning Poker is one of the gross-level estimation techniques, using a modified version of 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 amount of story points, and then vote again. They do so till they reach a consensus, and then move onto 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 to smaller tasks.

Ideally, the presentation of the item, discussion and voting should take around two minutes, which allows to estimate 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.

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.

Scrum Planning Poker Story Points Games

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.

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.

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

Scrum Estimate Story Points Poker Planning

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

Scrum Planning Poker App

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 on 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 is worth $20,000 and $100,000 for 5 sprints. With a hypothetical non labor costs 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.

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.

Scrum Poker Planning Cards

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

Using time tracking and resource scheduling tools 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.