Story points estimation is a mystery for new teams. They wonder why we use them, how to use them, and what benefits they bring. This is the first mindset change that new teams encounter. In this two part article I will attempt to Demystify story points by answering some of the fundamental 'Whys' and 'Whats' behind the concept of story point estimation.
Q7: How do story points incorporate complexity?
When we are estimating effort its not just the volume of work; it integrates considerations of complexity, risk, and uncertainty. While this is a seamless part of our day-to-day planning, its routine nature often goes unnoticed.
Deliver a package 50 miles distance:
Consider the scenario of delivering a package to a 50 miles distance.
On a straightforward highway with no traffic, the cost is $25.
If the journey involves a mountainous winding road, the cost doubles to 50$.
If the road is mountainous with sharp risky turns, cost escalates to $100.
Introduce the element of unexpected landslides, and the cost further increases to $150.
Despite the fixed distance, our estimates surge from $25 to $150 due to the layered complexities, risks, and uncertainties. Even if the actual drive time stays the same, additional factors and conditions impact our estimates.
Let's apply this concept to Web page design:
Create a web page with a banner and list of services offered. 2-Points.
Develop a web page that dynamically adjusts the services based on the visitor's role. 5-Points.
Integrate with an external API never used before to retrieve the service list. 8-Points.
Implement intricate business logic to dynamically change the service listings. 13-Points
In this software example, the estimated effort varies based on the complexity and potential risks involved. Similar to the package delivery scenario, the software task's estimation adjusts to reflect the intricacies and uncertainties specific to each development task.
Q8: How does a new team start using story points?
Transitioning to story points involves a shift in mindset that doesn't happen overnight. When new teams don't have stories available for relative estimates, they can initially use hours as a transitional measure.
It's like learning to ride a bike; at first, training wheels are necessary. However, when embraced correctly, the team will seamlessly adapt to estimating with story points, hardly realizing they've outgrown the training wheels. Here's a helpful guide to kick-start the journey with story points.
Q9: What if developer and QA have different estimates?
In an ideal Agile team, every team member is expected to handle both development and testing. However, this isn't always the case, teams members often have distinct roles.
Developers may understand the development requirements of a story well but may lack insight into the effort needed for QA. Lets join "TAC-Force Sprinters" backlog refinement ceremony and see what happens this time. After all they are the best :).
Team just reviewed another story and its voting time. Here are the votes (3,3,3,8,8,3).
This shows a clear difference of opinion. First thing to keep in mind is to avoid grouping the estimates into Dev, QA, or other categories.
Lets listen to how TAC-Force Sprinters resolve this problem.
Scrum Master: Team, we have a split estimate. Could someone who voted 3 explain why it's only 3 points?
John: This code is relatively simple, leveraging a significant portion of what we recently developed for a similar story. I believe it's a 3-pointer.
Sara: Oh I see what you mean and I agree that development is straightforward but this code impacts several scenarios and testing looks tricky to me so I think its 8
TACtastic Coder: I know I am new but Sara can you explain how many scenarios need to be tested, how complex they are and do we have automation?
--------------- [technical discussion] ---------------
John: OK, now I understand why you feel its going to take more effort"
Scrum Master: Team lets vote again. Bingo we have a consensus on 8 points.
Impressive TAC-Force Sprinters are really good. You want to meet the team?
Meet TAC-Force Sprinters
Q10: What if estimates prove to be incorrect or inconsistent?
Story points are not task estimates, and their accuracy is expected to be in the ballpark range. Teams should not overly stress to make them precise. Here are some rules to follow:
Backlog Flexibility: Feel free to adjust estimates as needed until they are incorporated into an active Sprint Backlog.
In-Sprint Consistency: Once in the Sprint, you should not change the estimate even if you realize you made a mistake. A mistake is an opportunity to improve. If you change the estimate, you will lose track of the mistake as well as the opportunity to enhance your estimation skills.
Significant Deviations: What if you realize that the estimate of a story in an active sprint is significantly different from original expectation? In this unexpected situation, the team should promptly inform the Product Owner and consider removing the story from the sprint. If there is available capacity, a different story can be added to the Sprint Backlog. The removed story shall then be re-evaluated and resized for a subsequent sprint.
Q11: How do I use story points for forecasting Epics or Releases?
Product backlog items are commonly grouped into Epics and Releases. By determining the total number of story points within an Epic or a Release, we can estimate the number of sprints required.
Determine Team's TRUE Velocity:
Though it might look like simple but velocity calculation is tricky. The initial inclination is often to compute the rolling average of 3 to 5 sprints. However, a more effective method entails plotting a graph and determining a line of best fit, disregarding any outliers.
An outlier can represent either a notably Good or a Bad sprint, influenced by factors such as holidays, unexpected impediments or the discovery of reusable code that helps the team complete a story earlier than anticipated.
Using Velocity to Forecast:
Next step is rather easy, the formula is:
Count of Sprints to deliver (an Epic or release) = Total Story Points / Team's Velocity.
It's advisable to consider any risk factors, particularly if the team lacks maturity, by adding 1 to 2 sprints to the estimate."
Watch a great video by Gary Straughan.
Q12: How can we improve our story point estimation as a team?
Improving story point estimation is crucial for enhancing a team's accuracy and predictability. Here are 3 strategies to follow:
Include All Team Members: Estimations are a collective effort for tasks that belong to the entire team, not individual members. Even those without expertise in a specific domain can contribute valuable insights. For instance, someone unfamiliar with civil engineering can still compare two houses and provide a reasonable estimate of their relative costs.
Details and Definition of Ready (DOR): Key to accurate estimation lies in well-defined user stories that adhere to the Definition of Ready (DOR). Vague user stories cannot be estimated with confidence. Encourage collaboration within the team during estimation sessions to gather diverse perspectives. Comprehensive discussions, leading to knowledge transfer and more accurate estimations.
Tasking: When faced with persistent estimation challenges, use the traditional approach of breaking down user stories into tasks, also known as sub-tasks. Tasking helps in understanding the 'how' behind the work described in the user story. This granular breakdown can make work steps more visible and help estimation process.
Comments