Story point calculation in Scrum

 61,344 total views,  9 views today

This is my fifth article, on my Scrum learning course. In the Scrum framework, the user story is one of the important aspects, and calculating the right story point for the user story will play a vital role while estimating and planning the sprint. So, if your estimation is wrong, your sprint might get failed. In this tutorial, we will learn how to calculate and estimate the story point for a user story.

Before getting into this, we should know what is user story is in the scrum, what is a feature in the scrum, what is epic in the scrum. In scrum hierarchy, this should go in this order Epic -> Feature -> User Story -> Task

Key-Highlights: What you will learn from this tutorial?

• What is epic in scrum?
• What is a feature in Scrum?
• What is a user story in Scrum?
• User story writing examples
• What is a story point in the scrum?
• What is the Fibonacci series?
• Story points vs hours estimation – how to estimate story points and hours?

What is Epic in scrum?

An epic is a large body of work that can be broken down into a number of smaller features, stories. In simple terms, Scrum Epic in Agile Methodology is a big chunk of work that can be divided into smaller user stories, which we can think of like it is a new project or a new big module in the project. The concept of a high-level business item is sometimes also called “Epic”.

What is a feature in Scrum?

In agile scrum development, a feature is a chunk of functionality that delivers business value.

For example, I want to build a site that sells eBooks.

My features might be:

• Display informative Home screen
• User Registration
• User Login
• Display Products
• Display Shopping Cart
• Add products to Shopping Cart
• Buy the product from Shopping Cart
• Add billing in the buy product section

What is a user story in Scrum?

A user story is the smallest unit of work in an agile framework that can be broken into multiple tasks. So, we can say user story superset of a task.

User story writing examples

For example, user stories might look like this:

User Story Title: Download all workflows from the SharePoint Online tenant.

User Story Description: “As a SharePoint admin, I would like to download all workflows from SharePoint Online, so, that I have a better view of all workflows running in my tenant from the Power BI report.

User Story Acceptance criteria: The workflow report is tested and accepted by SharePoint online admin person

Note:

• Each user story must have acceptance criteria so that the scrum master can execute the sprint with the pre-defined vision.

Now, we should calculate and estimate the story point for the above user story – but how? Before this, let’s understand what is a story point in scrum?

What is a story point in the scrum?

A story point is an abstract measure of effort required to implement a user story. So, it is a Fibonacci number we should assign to the user story which depends on the complexity of the tasks, efforts required for that task, and also it depends on the resource expertise who is working on that particular user story. The Fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on.

What is the Fibonacci series?

In mathematics, the Fibonacci Sequence is a series of numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. The logic behind this series is – the next number is found by adding up the two previous numbers.

Story points vs hours estimation – how to estimate story points and hours?

From my practical experience what I have seen is – there is no direct relation or equivalent translation for the number of hours and story points in the scrum. For the above requirement – someone might estimate the story point as 5 and the number of hours as 15 whereas someone might have a different number for this.

For time being, let’s forget about estimating the user story in the scrum. Let’s focus on this real-time example.  You want to travel from Kolkata to Bangalore – this is your requirement. If you travel by air it might take around 2.5 hours, if you travel by train it might take around 40 hours if you travel by road it might take more than 50 hours.

What we can see from the above example is – for the same requirement we have various estimation which completely depends on the approach we take.

The same rules are applied in user story point estimation as well which depends on the resource who is going to work that user story, the technology is planned to use, domain knowledge on the product, etc.

For the above workflow report generation user story scenario, a team member who is an expert in PowerShell coding, and if the technology is chosen as PowerShell programming, understand well, the object structure of the SharePoint Online workflow – for this resource, the estimation (simpler, least story point) will be different than a fairly new team member who has moderate knowledge on the above like PowerShell, workflow object structure.

One more scenario, I can say – there will be a scenario where the story point is less but the number of effort required is more.

Let’s say you are planning to analyze a SharePoint workflow excel report manually – where you need to verify the workflow running status by going to each list URL – this needs cumbersome efforts, isn’t it? However, this is not a complex job but time-consuming, in this scenario, we can have fewer story points but more no of hours.

If generally, 21 hours of effort required 8 story points in this scenario, we should consider the story point as 5.

To summarize the calculating and estimating the story point vs. hours we can take as below:

• For 1 story point, the number of hours might need 1 to 2 hours.
• For 2 story points, the number of hours might need 3 to 4 hours.
• For 3 story points, the number of hours might need 5 to 10 hours.
• For 5 story points, the number of hours might need 10 to 15 hours.
• For 8 story points, the number of hours might need 15 to 20 hours.
• For 13 story points, the number of hours might need 21 to 30 hours.

Notes:

• The above story point translation to the hour is not exactly equal, it is an equivalent comparison.
• The story point and hours are dependent on many factors like complexity of the work, type of the recourse, technology is planning to use, etc.
• The rule of thumb is – as the story point increase, the complexity of the user story is also increased.
• It is not recommended to go beyond 13 story points for user sing user story – if it is needed, we need to split that user story into two phases – otherwise, it will be very difficult to manage the user story and the sprint will lose its vision from its deliverables.

It looks complex to understand 🙂 don’t worry, once you get used to it – things will be easy.

Summary: What do we have here?

Thus, in this article, we have learned the below with respect to the estimation of a user story point in scrum:

• What is epic in scrum?
• What is a feature in Scrum?
• What is a user story in Scrum?
• User story writing examples
• What is a story point in the scrum?
• What is the Fibonacci series?
• Story points vs hours estimation – how to estimate story points and hours?

See Also

You may also like the below Scrum articles:

• 3 Top roles in Scrum project
• 5 Scrum events and ceremonies
• Artifacts in Scrum – Product Backlog, Sprint Backlog, Increment Backlog
• Understanding the fundamentals of scrum in agile – scrum vs. waterfall

Hope you have enjoyed reading this article and helped you. If you like to appreciate our efforts, please do share this with your friends and colleagues. 🙂