Story Point Estimation and Planning Poker

Story Point Estimation and Planning Poker are two popular techniques used in Agile software development to estimate the size and complexity of user stories. In this article, we’ll explain what these techniques are and how they work.

Story Point Estimation

Story point estimation is a technique used to estimate the effort required to implement a user story. User stories are short, simple descriptions of a feature or functionality that a user wants. They are often used in Agile software development to break down larger tasks into smaller, more manageable pieces.

The process of story point estimation involves assigning a numerical value to each user story, based on its level of effort. These values are usually represented in points, with larger numbers indicating more effort. The goal is to create a common understanding of the relative complexity of different user stories, and to provide a basis for planning and scheduling work.

One of the key benefits of story point estimation is that it allows teams to estimate the size of a project without getting bogged down in the details of individual tasks. Instead, the team can focus on the overall effort required to implement a feature or functionality.

Real-life example — calibrating and defining points

Below you will find an agile story point estimation table example that has 6 outcomes:

• 1 SP
• 2 SP
• 3 SP
• 5 SP
• 8 SP
• 13 SP

In the proposed example 8 story points are a lot and have the potential to be broken down into smaller work items. While 13 is already too high risk and must be broken into smaller items. Just beware — breaking down large items as 13 points, should not mean that two items of 8 SPs and 5 SPs will remain… Story points math is a bad practice.

Each broken-down item should be estimated again individually evaluating the amount of work needed. Thus the result might be three items of 5 SPs each after breaking down one item of 13 SPs.

Planning Poker

Planning Poker is a popular technique for conducting story point estimation. It involves a group of team members, usually including developers, product owners, and project managers. The team works together to assign points to each user story, based on its level of complexity.

The process begins with the product owner presenting a user story to the team. The team then discusses the story, asking questions and clarifying any details that are unclear. Once the team has a good understanding of the story, they each select a card from a deck of cards that represents a point value. The cards typically range from 0 to 100 points, with larger numbers indicating more effort.

After everyone has selected a card, the cards are revealed simultaneously. If there is a wide range of values, the team discusses the reasons for the differences and then repeats the process until a consensus is reached. The process continues until all the user stories have been estimated.

One of the benefits of Planning Poker is that it encourages collaboration and discussion among team members. By discussing the details of each story and coming to a consensus on the level of effort required, the team develops a shared understanding of the project and the work involved.

Planning poker is estimation technique which brings democracy to the work. Is democracy good for the world? Well, people may have different views. But democracy brings freedom, so new ideas and open thoughts. So let the team be the decision maker.

Who participates in the planning poker?

Entire scrum team. You may bring along designers and architects if they are not part of scrum team. This is an exercise not to write numbers on the wall, but to understand and agree on forecast without spending too much time.

Estimations are difficult. If a person can estimate the future with 51% accuracy (that is just 1% more accurate than tossing a coin) can make millions of dollars in wallstreet. That 1% makes lot of difference. There are various views on estimation and no estimation. I am not going into that debate. If you chose to do the estimation and so would like to forecast your team’s work, read on.

What is estimation? Estimation is a forecast just like weather prediction. Estimation can go either way because of known unknowns and unknown unknowns.

What is story point? This is a relative size and simply a number (1,2,3,5,8,13…) or a letter (S,M,L,XL ..). Relative to the complexity of the work.

Some talking points to ponder to understand complexity.

1. User story: What the story is saying? Is the understanding common across the scrum team members?
2. Design: Is it required to come up a new design or small modifications are sufficient?
3. Coding: Should we create many classes? Does user interface need extensive changes? Should i call one database or multiple databases? Is data transformation complex? How clean is the data?
4. Unit Testing: How many test cases should be written? Is the current testing framework sufficient?
5. System Integration Testing: Are the interfacing teams ready with data? Will we get timely help from them? What should we do if external teams delay?
6. User Acceptance Testing: Are users readily available to test? Is acceptance criteria clearly written for story? If users are not available should the team do UAT?
7. Deployment: Is there is a CI/CD (Continuous Integration and Continuous Delivery and Deployment) pipeline available? If it is manual, how much time should we spend?
8. Skills and Knowledge: Was this type of work done earlier? Do we have right skilled people in the team? Should we take one off help from external experts? Will they have time to help?

Above list is suggestive. You can build your own models depending on the type of work you do. Depending on the answers if the team feels the work requires more time, communication channels, coordination and resources (eg. infrastructure) the number or size may goes up.

Well…what is this size now?

Size is a number and it represents amount of the work just like kilo grams or kilo meters. This is not number of hours.

But then is there a direct relationship between size and hours?

There is… but it is not one to one mapping. If there are two people to run 10 Kilo meters, their timings will be different. Same with story points as well. Two people doing 5 story points of work will complete in two different timings. This being knowledge work adds bit more complexity to the equation. This is the reason, team velocity of one sprint is not sufficient to conclude as velocity. This needs to be over few months.

Conclusion

Story Point Estimation and Planning Poker are two powerful techniques for estimating the effort required to implement user stories in Agile software development. By assigning numerical values to user stories, teams can create a common understanding of the relative complexity of different tasks, and use this information to plan and schedule their work.

Planning Poker is a popular technique for conducting story point estimation, as it encourages collaboration and discussion among team members. By working together to assign point values to user stories, the team develops a shared understanding of the project and the work involved.

Overall, these techniques help teams work more efficiently and effectively, by providing a common language for discussing the complexity of the work, and enabling the team to plan and schedule their work more accurately.