By 73,060 total views, 5 views today
The story point calculation in Scrum—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 fail. 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 a user story is in the scrum, what a feature is in the scrum, and what an epic is in the scrum. In scrum hierarchy, this should go in this order. Epic->Feature->User Story->Task
Key-Highlights: Story point calculation in Scrum
- What is epic in a 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 the scrum?
An epic is a large body of work that can be broken down into a number of smaller features and 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 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 an informative home screen.
- User Registration
- User Login
- Display Products
- Display Shopping Cart
- Add products to the shopping cart.
- Buy the product from the 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 the user story is a 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 the SharePoint online admin.
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 a story point is in scrum.
What is a story point in scrum (What is Story point calculation in 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 and the efforts required for those tasks, and also depends on the expertise of the resource 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: Story Point Calculation Methods
In mathematics, the Fibonacci Sequence is a series of numbers: 0, 1, 2, 3, 5, 8, 13, 21, 34, and so on. The logic behind this series is that 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 that there is no direct relationship or equivalent translation for the number of hours and story points in the scrum. For the above requirement, someone might estimate the story point at 5 and the number of hours at 15, whereas someone else might have a different number.
For the 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; and if you travel by road, it might take more than 50 hours.
What we can see from the above example is that for the same requirement, we have various estimations, which completely depend 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 that is planned to be used, 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, if the technology is chosen as PowerShell programming, understands 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 and workflow object structure.
One more scenario, I can say: there will be a scenario where the story point is less but the amount of effort required is more.
Let’s say you are planning to analyse a SharePoint workflow excel report manually, where you need to verify the workflow running status by going to each list URL. This requires cumbersome efforts, isn’t it? However, this is not a complex job but one that is time-consuming; in this scenario, we can have fewer story points but more 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 the steps below:
- For 1 story point, the number of hours might be 1 to 2 hours.
- For two story points, the number of hours might be 3 to 4 hours.
- For three story points, the number of hours might be 5 to 10 hours.
- The number of hours required for 5 story points could range from 10 to 15 hours.
- For 8 story points, the number of hours might be 15 to 20 hours.
- For 13 story points, the number of hours might be 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 the complexity of the work, type of resource, technology being used, etc.
- The rule of thumb is that as the story points increase, the complexity of the user story also increases.
- It is not recommended to go beyond 13 story points for a 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: Story point calculation in Scrum
Thus, in this article, we have learned the following with respect to the estimation of a user story point in scrum:
- What is epic in a 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: Story point calculation in Scrum
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
- WHAT IS SCRUM?
I hope you have enjoyed reading this article and that it has helped you. If you’d like to appreciate our efforts, please do share this with your friends and colleagues. 🙂
Download SharePoint Online & Office 365 Administration eBook
Buy the premium version of SharePoint Online & Office 365 administration eBook from here:
Get the free demo PDF eBook from here:
Send download link to:
About Post Author
