Estimating how long developers will complete a product’s features is a hard game. Not to mention that wrong estimations can translate to overwhelming workload and even later project failures. Therefore, the overriding concern among agile team members is to find out the 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.
You should know this before knowing about the story point in the agile methodology: What is Agile Software development?
What are Story Points in Agile Methodologies?
This terminology is developed based on the phrase “user stories” in agile. 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 for building 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 so 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, 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 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)
- What must be done or prepared before team members commence or wrap up?
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 estimation 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. This session is conducted at the beginning of an iteration for development teams to review whether backlog items are clearly refined.
Estimating story points is the main job of those who get directly involved 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 extraordinary estimates can give a detailed explanation of PBIs, discuss and address any arisen problems. After issues are clarified and any misunderstanding is removed, those estimates can be modified.
- The above steps will be repeated until all members agreed upon the final results.
Tips to Make a Story Points Estimation Effectively
Making the right estimations also contributes to the success of building high-fidelity features. But not all members excel at this job. Hence below are some critical tips to help in estimating story points effectively:
Consider Agile Estimation as a Teamwork
Only development teams estimate story points in agile because they are the only persons that 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 over-or under-estimating backlog items. It’s when the owner and team lead jump in to clarify business expectations, explore and discuss matters. Meanwhile, the product owner himself can be knowledgeable about PBI complexity and the work implementation. He then will make a reasonable list of more refined items.
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 are recommended to give the product owner approximate figures instead. Concurrently, these numbers must be useful in building a proper product roadmap.
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 identify 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.
The post Story Points in Agile and How to Estimate Them Effectively appeared first on Designveloper.
March 16, 2022 at 09:25AM
No comments:
Post a Comment