PremierAgile

Agile organizations have evolved in recent years and it has become crucial for the IT professionals to make themselves updated with the Agile product development processes. As Agile solves all the drawbacks that were faced by the traditional software methodologies, many organizations have adopted them. These organizations tend to hire professionals who are well-versed with Agile practices and skills. There are many concepts that one has to grasp to understand and resonate with Agile professionals. These concepts include knowing about the User Stories, different roles, and responsibilities that they have to complete, Scrum values, principles, and artifacts, etc. One important concept that is not mentioned in detail in the Scrum guide, but has to be known by the professionals is the concept of Story Point in Agile and How to estimate them. This article provides an overview of the concept and explains story points with few examples. 

What is a Story Point in Agile?

Story points in Agile are a type of measurement that is used in Agile Project management and development which estimates the difficulty of implementing a particular User Story. It is an abstract measure of complexity and effort that the Developers has to make to implement a particular User Story. In traditional software methodologies, developers used to estimate the difficulty of a particular Product Increment by measuring the time taken to implement it. However, in the modern Agile product development system, story points are assigned to a particular User Story that would estimate the difficulty of a specific Product Increment. A Story Point could be thought of as a number that would let the developer understand the level of difficulty of a User Story based on several factors such as risks and efforts, complexities, and uncertainty revolving around the User Story. A story point estimation is a kind of relative estimation that is performed during the Product Backlog Refinement sessions. The team that is responsible for the actual development and testing process is responsible for allotting the story points for the items in the Product Backlog. 

Product Backlog Refinement sessions are one of the Scrum practices that are facilitated by the Product Owner. This session is mainly conducted to evaluate the items on the Product Backlog and is attended by the Developers, the PO, and sometimes, the Scrum Master, and other Stakeholders. The main aim of the session is to make the Sprint Planning session more efficient. Here, the following questions would be answered:

• Whether the Sprint Planning meeting can be conducted efficiently?
• Is the information enough to complete the Sprint Planning meeting?
• Whether the User Stories in the Product Backlog are split reasonably?

During this session, while preparing for the Sprint Planning, the Developers also evaluates the items in the Product Backlog and assigns a specific number for each of the user stories. The estimation of each user story would differ from one team to another as it is an abstract concept and does not have a standard chart of values. The values are assigned by the team members themselves during the Product Backlog Refinement sessions. Hence, we have understood that story points are the unit of measure for estimating the overall effort the developers have to make to fully implement a Product Backlog item or any other piece of work. 

What are the factors that are considered while estimating a Story Point?

As the story points represent the overall effort taken by the developers to create a story, the team should estimate the story point concerning all the factors that affect the effort of the developer. These include:

• The amount of work that has to be done
• The complexity of the task or work
• Any uncertainty or risk while doing the work

These three factors have major impacts while estimating a story point. Let us understand how each factor affects in detail.

The amount of work that has to do

As the story point dictates the amount of effort required to develop a User Story, it would correlate with the amount of work that has to be done to complete the work. The more amount of work required to develop a User Story, the larger will be the story point. Consider the example of developing three web pages. The first web page has only one field and a label that asks to enter a name. The second page has 50 fields to be filled with a bit of text and the third page has 100 fields that also have to be filled with texts. There are no interactions between the fields in the second and third fields and each of them has to be only filled with text. There are no additional risks in the second and third web pages. The only difference between the three pages is that the first page has only one field to be filled, the second has 50, and the third has 100. The second one has more work than the first, and the third has more work than all of the three web pages. Hence, the third page gets more story points than the second, the second gets more than the first, and the first page gets the least story points. The estimation of the story points depends on the type of estimation used by the team such as t-shirt sizing or planning poker. 

Uncertainty and Risks

The story points are affected by the amount of uncertainty and risks that the Product Backlog item contains. If the Stakeholder asking for the Product Increment is not clear about what they need, it should be reflected in the story points. Many scenarios would also include the developer implementing a feature by changing specific old and brittle codes that do not have automated tests in place. This type of risk should also be reflected in the story points. 

The complexity of the work

The complexity of the work should also be considered while estimating a story point to a particular User Story. Taking the previous example of having 50 and 100 fields in web pages with no interaction between them, let us consider another example where there is one web page with 100 fields. Here, there are few data fields with calendar widgets that pop up. Other data fields are formatted text fields such as social security numbers and phone numbers, also few fields check the validation of the credit card numbers. In this data field, there are few interactions such as when a user enters an American Express card, a four-digit CVV field is reflected, and when a visa card is entered, a three-digit CVV is shown. As compared to the earlier example, this type of implementation is harder as it involves various interactions which makes it more complex and time-consuming. Also, there are more chances that the developers would make mistakes while implementing it and have to back up and correct them. This complexity should be seen in the estimated story point provided. 

Combining the three factors

It may seem overwhelming to combine these three factors and reflect as a specific number and provide an estimate. But having effort as a unifying factor may be possible. The team decides the effort that takes to complete a specific amount of work in the Product Backlog. Also, estimators, later consider the effort required to deal with uncertainty and risk to complete the Product Backlog item. The effort is considering the risk of a specific problem and the impact of the risk that may occur. For example, a risk that is time-consuming and has more probability to occur would have more story points than a minor risk or an unlikely risk. Lastly, while calculating the story points, the complexity of the work should be considered. Work that requires more thinking, more trial and error experimentation, and more back and forth with the customer, and tasks that take longer to validate and correct mistakes should be assigned more story points.

Story points are an abstract concept and few may find it hard to grasp the concept. However, one must understand that the number represents the effort of the developer considering all the factors. The point values we assign to each item is not important, what is essential is the relative values that we assign to other items. A story that is assigned a 2 should be twice the story that is assigned 1. Hence, the value of the story point should be decided by the team according to their level of difficulty. 

How to Estimate a Story Point?

There are several ways to estimate story points for any Product Increment or other tasks. However, these are certain steps that one can follow to estimate story points. 

Step 1: Identify a base story 

As understood, story points contain three elements that have to be considered: risk, complexity, and repetition. The factors under risks include Unclear demand, Dependence of the third party, and uncertainty in the future. Complexity is the effort required to develop a particular user story. Repetition is a monotonous task that does not include any risk or complexity. We have to search for one elementary task that would correspond to the internal standards of the Definition of Done to find our base story and assign a specific story point to it. 

Step 2: Creating a Matrix for Estimation

Creating estimation matrices can be done using two types of scales called the linear scale (1,2,3,4,5,6,7..) or the modified Fibonacci sequence numbers (0.5,1,2,3,5,8,13..). Using the Fibonacci sequence, people could easily compare sizes, and even if they are not good at estimating absolute values. While estimating the story points using the Fibonacci sequence numbers, a matrix with rows for each sequence along with their associated stories is created. Later, all the stories are classified into rows such that all the stories are compared to each other. A baseline story should already be added in the first row such that all other stories could be added to different rows by comparing it to the base story.  

The team members have a meeting where all the specialists that would work on the project get together and play planning poker to assign story points to each User Story. Planning poker is a type of estimation technique that can be used with various estimating units but usually used for story points. 

• Estimation Process of Planning Poker
• Each specialist in the team gets a set of cards
• The estimators select the backlog items, and discuss their features and raise questions on the backlog item. 

When the feature is fully understood, then each estimator chooses a card to represent their estimate privately so that the estimate is objective.

When everyone estimates their story points, they reveal their cards simultaneously. If all the estimates match, the story point for the user story is finalized and the team moves on to the next backlog item and repeats the process. However, if the estimates differ, the team comes to a particular story point by discussing their point of view on the backlog item.

Other estimation processes that are also popular among Agile teams are using 1,2,4,8, 16 numbers, T-shirt sizing method where the User Story is termed X-Small, Small, Medium, Large, Extra-Large, XXL, and the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. In this example, planning poker was played with the Fibonacci sequence. 

Step 3: Sprint Planning

The size estimates can be converted into man-hour estimates only when the first Sprint is completed. While the first Sprint is in progress, the team's velocity can be tracked. Hence, after the Sprint is completed, the team can calculate the number of story points they have finished. These numbers can be used to forecast the team's performance in the upcoming Sprints. Once the number of story points is estimated to all the backlog items, it becomes easier to understand the number of Sprints needed to complete the project. And hence, these abstract numbers can be converted into real calendar timelines by the team. 

Conclusion:

Story points are one of the best ways to estimate the effort taken by the team to complete a specific Product Increment or any other tasks. It is quick and helps the team members to understand the relative effort required to complete each story even if they have not faced the User Story before. Story points also provide clients a precise estimate and hence are considered better than the abstract man-hours given to complete a specific project. Story points are usually done before Sprint Planning, during Release Planning, and at a pre-planning phase. Story points and Sprint velocity are both helpful in providing a guideline for the stories to be completed in the coming Sprints. Hence, knowing to estimate story points is a crucial skill that every professional should acquire, and gaining more knowledge about story points would help individuals gain a strong base during Sprint Planning meetings. 

References:

1.https://www.atlassian.com/agile/project-management/estimation

2.https://www.visual-paradigm.com/scrum/what-is-story-point-in-agile/

3.https://www.tothenew.com/blog/how-to-estimate-story-points-in-agile/

Useful Links

Certified Scrum Master Certification Course Amman, Leading SAFe Course Training Sioux Falls, Advanced Product Owner Online Certification Cleveland, Advanced CSPO Certification Charleston, Advanced CSPO Training Stamford, Advanced Certified Scrum Master Virtual Certification Training Des Moines, Reasons To Adopt Agile, Certified Scrum Product Owner Training Sacramento, Advanced Product Owner Virtual Certification Training Davao City, CSM Certification Marseille