Story Estimation

What is Story Point?

A story point is a measurement, which is used in project management to quickly detect the effort, risk, and complexity of the use of a particular user story. Basically, a number tells everyone on the team how challenging a story is and how much time the team will be required to complete the user story.

When Story points are assigned to a user story?

The Story points are assigned to a user story generally during the sprint planning when the whole team is picking the items from the product backlog and wanted to discuss the estimation of that user story.

In Knoldus how story points are assigned to the user story?

The story point estimation can be done with the following components

  • Risk:- Is there any risk on the user story that the team can foresee or team might face any third-party dependencies and random changes.

  • Complex:-how specific tasks are difficult to develop.

  • Effort/Repetition:- how well the team or a member is familiar with the feature and

Story Point = Risk + Complexity + Effort/Repetition

Steps to give story point to a user story

There are mainly three steps to provide the story points to a user story

1. Fibonacci Series and determining the matrix


The Fibonacci series is a sequence of unique numbers where every number is the sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc. Using these numbers, it’s much easier to decide if an item is 3 story points or 5 story points.

So if the team is giving fewer story points to a user story then it can indicate that the particular user story is easy to develop and it has less complexity and risk on the other hand if the team is giving high story points to a user story then it can indicate that the particular user story is hard to develop and there are some risk and complexity involved in this user story.



2. Planning Poker

Planning poker can help the team to find the right story point for each item.
  • In the sprint planning session, each developer and tester receives a set of cards, each showing a Fibonacci sequence number.
  • The backlog is brought to the table so that the team can ask questions and clarify the features
  • When the discussion is over every team member secretly selects a card that accurately reflects their rating.
  • Once all the cards have been selected, the team members present their cards at once. When consensus is reached, it is time to move on to the next thing. When card number vary, the team negotiate until they reach an agreement. And if requires then the team can ask further questions to the product owner

It is always good to have a complexity matrix in hand so that the team members can focus on the timing of the poker setting, as it allows for greater consistency in all activities. Also, it helps to set a maximum limit (13, for example). If the work is estimated to be larger than that limit, it should be divided into smaller items. Similarly, if the task is less than 1, it should be combined into another function


Note:- If the story points are too far away or the team disagrees then it is best to put that user story item back to the product backlog and revisit the user story item if product uncertainty or technical uncertainty is reduced

Best Practices to give story points to a user story in remote working culture:

  • Every team member should have recurring time-bound calendar invites

  • The team should have an Online storyboard (For eg. Jira Board) where all the product backlog items are listed

  • Product Owner should share his/her screen and present the user story in front of the team during the call

  • Each team member should have the online storyboard access

  • The product owner and the team should visit all the stories one after the other and should be able to discuss the story scope

  • A team can use the following tools in remote working culture for story estimation,

              1. Microsoft Teams Polly

              2. Scrum Poker Online (https://scrumpoker.online/)

              3. Planning Poker (https://www.planningpoker.com/)

              4. Scrum Vee (https://scrumvee.com/)

              5. Pointing Poker (https://www.pointingpoker.com/)

              6. Plan it Poker (https://www.planitpoker.com/)

              7. Scrumpy (https://scrumpy.poker/)

Preparation

  1. PO: For each team decides who will act as the Product Owner.

  2. User Stories: Provide User Stories to the Product Owner.

  3. Prioritize: The Product Owner can sort the user stories according to their business value in order to maximize the value.

  4. Card values: Do not make any agreement on the meaning of the value of each card.

  5. Refinement and slicing: Some user stories have things in common. Check if they can detect and separate them into other stories or slice stories into smaller stories.

Running the planning poker game

  1. Present Story: The Product Owner will present a user story in front of the team and will read the Acceptance Criteria. If the acceptance criteria is empty, the PO can just say what he would like to have as an ideal ACs.

  2. Questions: The team can ask questions to PO to clear their queries. The Product owner can make up any answers that are not defined in the Acceptance criteria according to his own preferences or ideas.

  3. Notes/AC: The Product owner can take additional notes of his answers as acceptance criteria in the card.

  4. Select Cards: The team members select a card according to the complexity they think to get the story done and keep it down so nobody can see it.

  5. Showcards: all team members must show the cards at the same time. This is important!

  6. Consensus: If all cards match, you have an estimation. Otherwise, the ones with higher values must say what complexity they see and the ones with the lowest values must explain why they think this is easy.


Repeat steps 2-6 until the cards match and there is consensus for the estimation.

Start again from step 1 with the next story.


That's it!