Estimating how long developers will complete a product’s features is a hard game. Not to mention that wrong estimation can translate to an overwhelming workload and even later project failures. Therefore, the overriding concern among agile team members is to find a way to make a realistic timeline. It’s when some estimation techniques with higher accuracy come into play. One of them is story points. In this article, Designveloper will give you a deeper understanding of story points in Agile and how to apply them for effective estimations.
What are Story Points in Agile Methodologies?
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.
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.
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
In case you wonder when the story point estimation occurs, the answer is during the product backlog grooming. In particular, team members conduct this session at the beginning of an iteration to review whether backlog items are clearly refined.
Estimating story points is the main job of those who directly engage in development work. But the product owner, a team lead/scrum master, and other stakeholders can participate in the process to avoid unexpected misunderstandings.
Recommended reading: What Is SCRUM And How Does It Work?
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.
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
Only development teams estimate story points in agile because they are the only persons who understand the work implementation most.
Meanwhile, the product owner is responsible for receiving requirements from clients, building the product backlog, and explaining items therein. The owner doesn’t always know exactly how the work is implemented. But it doesn’t mean the owner should stay out of the estimation process.
It’s admitted that agile estimation isn’t a one-person game, but teamwork. Why is that? In reality, team members don’t grasp input requirements from the business, consequently under-estimating backlog items. It’s when the owner and team lead to jump in to clarify business expectations and explore and discuss matters. Meanwhile, the product owner himself can be knowledgeable about PBI complexity and the work execution. He then will make a reasonable list of more refined items.
2. Estimate Smartly, Not Hard
One mistake during the estimation process is some team members are trying hard to estimate story points. This sounds impossible because requirements may be altered and previous estimates can prove incorrect afterward.
Assuming that a member’s hardest work never gets the estimated figure of over 20, for example. They will find it difficult to give exact figures for larger work than that.
Therefore, when estimating story points, development teams should give the product owner rough figures instead. Concurrently, these numbers must be useful in building a proper product roadmap.
3. Learn From Past Experience
In the sprint retrospective, all team members will reflect on what was done and how to make further improvements. But Designveloper advises you to look back at past estimates as well. This helps determine whether such estimates are accurate and whether PBIs should be divided into smaller increments to suit your team.
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.
