Planning Poker: Agile Estimation And Planning Made Easy

Written by pradnyaD | Published 2020/06/09
Tech Story Tags: management | productivity | team-productivity | project-management | product-management | startups | agile | scrum

TLDR Planning Poker is an agile estimating and planning technique that is based on the decision made by agreement among group members. The Scrum Master, Product Owner and the development team are part of the Planning Poker activity. Planning and estimation are some of the crucial phases of building your project. In Agile, planing poker helps in achieving the same in Agile. The most important thing is to continuously inspect, adapt and iterate, but having a manageable team size is a good thing to start.via the TL;DR App

“A project without a plan is like a ship without a rudder.” ~D. Meyer
In life, estimation is a part of our everyday experience. When you are shopping in a grocery store and trying to stay within a budget, you estimate the cost of the items you put in your cart to keep a running total in your head. Similar is when you are planning for a project based on the client’s requirement. Planning and estimation are some of the crucial phases of building your project. In Agile, planing poker helps in achieving the same.

What is Planning Poker?

Planning Poker is an agile estimating and planning technique that is based on the decision made by agreement among group members. The Scrum Master, Product Owner and the development team are part of the Planning Poker activity. The Scrum Master coaches and helps the team in carrying out the activity in a better way. To start a poker planning session, the product owner/customer reads a user story or describes a feature to the members of the development team. These members are called estimators.
Each estimator holds a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8 and 13. These numbers are part of the Fibonacci sequence. It is used because numbers that are too close to one another are impossible to distinguish as estimates. These values represent the ideal days, the number of story points, or other units in which the team estimates.
A discussion takes place where the estimators discuss the feature, asking questions to the product owner as needed. When the feature is completely discussed, each estimator selects one card. These cards represent his or her estimate. All cards are then disclosed at the same time.
If the value selected by all estimators is the same then that becomes the estimate. If not, then especially the high and low estimators share their reasons. After further discussion, each estimator re-selects a card, and all cards are again revealed at the same time. This is repeated until all the members agree on a common value.
Agile estimation is a team sport.

Why Planning Poker?

When deciding the initial product backlog, the team needs to estimate the story point for each task. This helps in creating an initial estimate of the scope and size of the project. The product backlog gets updated on iterations. Hence it would be beneficial to have subsequent sessions of such agile estimation and planning once per iteration.
One of the reasons why Planning Poker leads to better estimates is because it brings together multiple expert opinions. The development team might be used to solve such tasks and can understand the implementation. This is the reason they can estimate it better than anyone in the team.

How to estimate better?

STAY ENGAGED: Switch off all the possible distraction sources and stay focused.
ASK MORE: Ask again and don’t be afraid to look awkward, the team will appreciate your curiosity.
THINK RELATIVE: Don’t think “how many steps the ladder has”, but how
tall is this ladder compared to that”.
STOP WHEN TIRED: Sometimes your accuracy degrades proportionally to the time you spend estimating tasks. At this point, planning poker stops being fun and becomes a challenge.

Summary

In Agile, with most of the things, there are no concrete answers for what works best. The most important thing is to continuously inspect, adapt and iterate. This might take time and practice, but having a manageable team size is a good thing to start. I have provided you quite a few tips here, you don’t have to apply all of them at once. You might have to pick one that you think can be achieved easily in your specific environment, apply it and observe the improved results. This can help you and your team get motivated to carry on.
Happy estimating!

Written by pradnyaD | Software Engineer at www.udgama.com
Published by HackerNoon on 2020/06/09