Story Points in Agile and How to Estimate Them Effectively

What are Story Points in Agile Methodologies?

*Story points are units used to measure how much effort developers need to build a product backlog item*

This terminology is developed based on the phrase “user stories” in agile methodology. Accordingly, a story, known as a product backlog item, is a concise explanation of a deliverable’s functionality from end-user perspectives. For example, below is typically what a customer wants from an eCommerce app:

“I prefer to receive notifications about personalized discounts based on my purchase history.”

Based on this user story, developers plan to build Push Notifications on the app. To estimate the overall effort they need to accomplish the job, they may assign relative values from one to ten or even 1000 to 5000. Which value range you use isn’t as important as how you evaluate the difficulty of a user story. On a 10-point scale, for instance, pieces of work given one are easiest, while those with six prove much more demanding.

Why Should Your Team Use Story Points in Agile Development?

Time (e.g. hours, days, or months) is a traditional estimation approach in software development. However, it proves a bit old-fashioned and ineffective because such events as interviews or daily meetings lead to delays in your work. This hardly ensures the punctual delivery of a product’s features that team members committed to complete within a predetermined period.

Not to mention that time-based estimations possibly come from subjective, emotional opinions. This means team members can overestimate their amount of work or over-plan product backlog items.

*Beyond that, the owner can evaluate a user story’s ROI and better predict time-to-market*

Various agile teams turn their focus on story points. This gauging technique helps them solve the above problems. For the product owner, story point values help him/her better understand technical uncertainties relative to oversized prices of work. Beyond that, the owner can evaluate a user story’s ROI and better predict time-to-market.

Meanwhile, story points support development teams to make a reasonable estimation of product backlog items they are able to develop. Thereby, they can build a reliable execution strategy, devise a proper plan, and work sustainably to implement those items in an iteration.

How to Calculate Story Points in Agile?

Agile teams use different ways to identify abstract values of story points. Designveloper suggests several common point systems as follows:

The Fibonacci Sequence: Each number is a sum of two preceding digits – 1, 3, 5, 8, 13, 21, 33.
The Linear Sequence: The standard number pattern – 1, 2, 3, 4, 5, 6, 7, 8.
The Doubling Sequence: Each number is a result of one preceding digit – 1, 2, 4, 8, 16, 32, 64
T-Sizing: This method uses t-shirt sizes such as XS, S, M, L, XL, and 2XL.

The Fibonacci Sequence: Each number is a sum of two preceding digits - 1, 3, 5, 8, 13, 21, 33 — *The Fibonacci Sequence: Each number is a sum of two preceding digits – 1, 3, 5, 8, 13, 21, 33*

Whichever methods are applied, the more important question is how team members can base the difficulty of each item on those values.

So to estimate them as precisely as possible, all the members should consider such external variables as workload, complexity, or risks. Besides, story point values should be based on internal factors like their abilities or available resources. The following questions will give them a clearer view of how these variables affect their estimates:

How complex is a feature? Or How difficult is it to build an item?
What are the potential risks? (e.g. ambiguous demands, reliance on third parties, or uncertain parts of a project)
Is the work repetitive? Or How familiar do developers feel with an item?
How much work is needed to complete a feature?
What is the team’s technical capacity?
How available are resources for developing an item? (e.g. human, finance, or tools)

During the estimation process, team members shouldn’t assign values to small work they can implement in a specific timeline. Besides, they should avoid letting one factor impact the whole estimate process because story points are decided by various factors.

A Typical Process of Estimating Story Points

Assigning story points in Agile is not a one-man job. It is a process that is practiced by all the members of the team such as developers, designers, testers, and deployers. This approach helps in incorporating other views which makes the estimates more accurate.

It starts with a conversation on a basic user story. This reference story is used as a benchmark for future computations. After that, the team selects a grading system for story points. This system assists in estimating the time that would be used in performing a given task.

One of the most common practices applied during this process is the ‘planning poker’. ’ Each team member secretly chooses a card with a story point value and turns it over at the same time. It makes the process more objective and gives everyone the opportunity to express their opinion about the issue.

Story points take into account three factors: risk, repetition and complexity. Risk can be defined as the total variability that is attached to the task. Repetition is about the kind of work that the team is familiar with. Complexity concerns the difficulty of the task.

Following the estimation, the team sets a sprint retrospective to review the velocity of the project. This assessment is useful in getting a feel of the team’s capacity and in enhancing the subsequent estimates.

Always bear in mind that story points are relative. They are most useful when used to compare with other tasks and not for their actual values. Therefore, when using story points in Agile, do not pay much attention to the actual numbers but rather the relative values.

Steps of Story Point Estimation

Below is how a typical estimation session takes place:

A team lead/scrum master holds the product backlog refinement meeting. He/She takes responsibility for monitoring the session and preparing the burndown chart for a project.
The product owner briefs product backlog items (PBIs) for estimation. Team members then give questions and examine possible assumptions or uncertainties.
Team members build an estimation matrix for story points. They then draw out PBI calibration to identify which causes minimal uncertainties, complexity, and repetitiveness.
Each member compares an item’s size with the preset calibration. Members use Planning Poker cards that display available numbers to show their estimates.
The product owner can ask why development members pick specific numbers. If the owner and the team lead recognize unusual estimates, they can re-explain PBIs, and discuss and address problems. After members grasp issues and remove misunderstandings, members can modify those estimates.
The above steps will be repeated until all members agree on the final results.

How We Build Story Points in Agile at Designveloper

At Designveloper, we’ve mastered the art of estimating story points in Agile. Ours is a holistic approach that is easy to implement and it is all about cooperation and understanding.

The first step is to decompose each user story into tasks. This level of detail enables one to determine the level of difficulty and work expected in each of the tasks. For example, in our project ‘Lumin’, which is a document platform where users can view, edit and share PDFs, we estimated the story points for each feature, such as viewing, editing and sharing, according to the level of difficulty.

Every member in the development cycle including the developers, designers, testers and deployers are involved in the estimation process. This collective effort helps to make sure that all possibilities and all the problems are being considered. For instance, in our ‘ODC’ project, which is a healthcare platform for both the doctors and the patients, there are the functionalities for the doctors and the patients, which makes the project more challenging.

We also learn from our past estimates in order to enhance the process. Today we have more than 100 projects implemented, and this means that we have a solid base of statistics to work with. This historical data assists in making adjustments to the estimates and makes them more precise.

Also, we use story points to assist in ranking our project backlog. When we assign the story points to each of the tasks, then we are in a position to determine which of the tasks must be initiated earlier. This was particularly useful in our ‘WorkPacks’ project which is a full construction management tool and in which we had to manage many tasks concurrently.

Therefore, the estimation of story points in Agile at Designveloper is a combination of cooperation, comprehension, and experience. It is a technique that has been used in many projects and still is useful in the delivery of quality software solutions to clients.

Recommended reading: What Is SCRUM And How Does It Work?

The 3 Tips to Make a Story Points Estimation Effectively

Making the right estimates also contributes to the success of building high-quality features. But not all members excel at this job. Hence below are some critical tips to help in estimating story points effectively:

1. Consider Agile Estimation as a Teamwork

When it comes to story points in Agile, teamwork plays a pivotal role. It is important to note that agile estimation is not a one man show but a team affair. Developers, designers, testers, deployers – all of them have their own view of the situation. This diversity of thought results in better and more precise estimates.

For example, a task that is obvious to a product manager, such as supporting a new web browser, may be full of challenges to a developer or a QA engineer. Likewise, design changes need the review and approval of the design team and the development and QA teams.

As much as it is necessary to involve everyone in the estimation process, it enhances morale as the key participants in the process feel valued. What one must not do is to exclude any part of the larger product team from the estimation process since this will only reduce the quality of the estimates and, in turn, the quality of the software.

Additionally, the reliability of Agile estimation can be improved by calibration, historical data, quantifying uncertainty and confidence. Calibration is the process of comparing current stories with examples of stories at different story point levels, to enable estimators to gauge the current stories. This practice helps to avoid situations when some team members use story points in one way, while others – in another.

In fact, historical data, no matter how scanty or inaccurate, can serve as a useful point of comparison. Historical records of previous projects can be used to make current estimates since the teams can be able to see patterns and trends. It is also important to have a historical perspective in order to make the estimates more realistic.

Lastly, quantifying uncertainty is also important in estimation. It is important that uncertainty should not be shunned, but should be recognized and quantified. For instance, if a particular task involves many external interfaces, add some time to the estimate to cater for the possibility of interface problems. It also assists in preventing and controlling possible risks that may arise.

2. Estimate Smartly, Not Hard

Estimate story point — *How to estimate story points for improved agile planning?*

In the case of story points in Agile, it is all about smart estimation and not exhaustive effort. Agile story points estimation is not a blood-oath; it is an estimate. One does not have to work on the weekend to make up for underestimating a piece of work.

First of all, let us consider the numbers. A survey by KPMG showed that at least 91% of organizations consider the adoption of Agile as a priority. This is an indication that Agile is becoming more relevant and therefore so is story points in the management of projects.

Estimation is a team game. It should involve all the members of the team including developers, designers, testers and even the deployers. Every team member has a specific view on the product and the efforts that should be made to complete a user story. Excluding a part of the wider product team from the estimation process results in lower quality estimates.

For example, suppose product management wishes to support a new web browser. It may sound like a trivial process, but development and QA must have their say because their expertise has shown them what obstacles may lie ahead.

New trends in story point include; using machine learning algorithms and data analysis in order to increase the reliability of the estimations. Through the use of historical information and pattern analysis, the teams can be able to improve their estimation and make better decisions.

3. Learn From Past Experience

Learning from past experiences is a crucial aspect of estimating story points in Agile. It involves the assessment of previous sprints, the problems encountered, and the use of this information to make better predictions.

The application of machine learning algorithms and data analytics has also been incorporated in Agile project management in recent years. These tools use past data and statistical analysis to improve the estimation process. For example, if a task estimated to require five story points took more time than it was anticipated, this information can be used to make corrections on future estimates.

Suppose, for instance, a team had underestimated the level of difficulty of a particular user story. It was estimated to be a two-point story during the initial planning and it took the resources of a five-point story to complete it. In such cases, the team can understand this experience and make the right estimations in the future.

Do not aim at getting the most accurate estimate but try to enhance the estimation procedure in the future. These are the reasons why Agile methodologies, such as story point estimation, are effective due to this continuous learning and adaptation.

Conclusion

Estimating story points in Agile can be among the hardest parts of your job. Yet it also requires regular practice to perfect. Besides, agile teams, say, Designveloper also build a harmonious, collaborative environment for team members to constructively give their estimates of work.