Skip to main content

Agile Story Point Estimation Techniques - Planning Poker - By Ankur Mistry

In my previous article, we have discussed what is Agile Story Point Estimation. In this article, we will learn how to estimate story points using "Planning Poker" cards.

Planning Poker is a relative estimation technique used by teams to estimate the user story.

Before starting, the planning poker team will define and agree on the parameters to measure the amount of work like a number of screens and number of fields etc. Identify a reference story that the team has done before or understands very well. Ideally, they will compare other stories with the reference story and one by one do the estimation.

Steps
  1. Product Owner will explain the story to be estimated and the development team will ask questions if they have any issues or unclarity. For example -

    Design Related- Do we have to learn new things before starting the design/HTML/jQuery etc?
    Coding Related- Do we have any code class library ready or we have to write it from the scratch?
    Testing Related- Any specific setup required for Unit testing?

    Other questions like any dependencies in tasks, does anyone have written code for similar stories etc. are also included.
  2. Once the Team understands the user story, they compare the story with the reference story that they have selected.
  3. Each team member comes up with the size of the story related to the reference user story.
  4. Team members show the card to everyone.


    Image Source: Autentia Planning Poker 
  5. If the team member has consensus or the variance is less, assign the story points and move on to the next.
  6. If there are conflicts, then each team member explains the rationale behind the number.
  7. The product owner explains the story further or clarifies misunderstanding if any.
  8. Team repeats steps until the team has consensus or variance is less or up to three rounds.
    image source: https://www.youtube.com/watch?v=sCCUEtjCpCs  
Even after three rounds, if there is no consensus and variance is high, assign the biggest number and move forward.

For first few months with the team, it's challenging but once the team is used to it, it will be great fun and useful for the product owner to make decisions for the team as well as the business.

I hope you liked this article. In my next article, we will discuss T-Shirt size estimation.

Reference
  • https://leanpitch.com/
  • http://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/

Comments

Post a Comment

Popular posts from this blog

Scrum Framework - 5 Events in Scrum Framework - By Ankur Mistry

In my previous articles, we have discussed  3 Roles  and  3 Artifacts  in Scrum. In this article, we are going to discuss 5 events in the Scrum Framework. There are Five events in Agile Scrum Framework. Sprint Planning Daily Scrum Sprint Review Sprint Retrospective The Sprint ( Figure: Life cycle of Scrum from  http://www.agiletroop.com/product/life-cycle-of-scrum/ ) Sprint Planning  is the event in which the Product Owner presents the ordered product backlog to the development team. As the word suggests, 'Sprint Planning' means we are going to plan the work to be done in the Sprint. There are two main parts - 'What' and 'How'. 'What' can be done in this Sprint? 'How' will the selected work get done? What can be done in the Sprint - In this part, the Product Owner presents the product backlog items with high business value tasks as a first priority to the development team. All team members collaborate to understand ...
1 comment
Read more

Scrum Framework - Three Artifacts - By Ankur Mistry

In this article, we will discuss three artifacts in Scrum Frameworks. There are three artifacts in Agile Scrum Framework. Product Backlog Sprint Backlog Working Product (Figure: Scrum Process from : https://commons.wikimedia.org/wiki/File:Scrum_process.svg) Product Backlog is an ordered list of tasks or features that need to be done within the project. It may have short descriptions of all functionality desired in the product. Product Backlog is owned by the Product Owner. It is an ordered list of features for the product. Each product item has an Order, Value, Description, and Estimation. Generally, tasks which have more business values are the top priority. Product Owner owns the product backlog. Product Owner makes sure that the product backlog is clear and transparent to the team. Anyone from the team can add an idea in the product backlog but it's product owner who decides which one stays there. There is one Product Backlog for one product, multiple...
Post a Comment
Read more

What is User Story ?

A User Story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. User stories are: written from the point of view of a person using your website or application written in the language that your customers would use. Three C’s of the user story: Card – stories are traditionally written on note cards, and these cards can be annotated with extra details Conversation – details behind the story come out through conversations with the Product Owner Confirmation – acceptance tests confirm the story is finished and working as intended. Template for User Stories : A user story template often uses the following type of format: As a <role> , I want <feature> so that <reason> . Examples of user stories are: As a  user , I want  to upload photos  so that  I can share photos with others . A...
1 comment
Read more