What Is the Relationship Between Story Points and Task Effort in Hours?
A simple way to look at how story points are performing
Story points and cycle time
A Scrum planning meeting is usually held in two sessions:
Session 1: The product owner explains the user stories, the team clarifies any doubts, and the user story is refined or updated. The team estimates (sizes) the user stories and commits for the sprint.
Session 2: The team works on a design for committed user stories and breaks the user story into tasks; volunteers pick up the tasks and assign hour estimates. (If required adjustments to scope are done in consultation with the product owner, and the team agrees on the sprint goal, team capacity is matched with estimates in terms of hours).
For sizing user stories, complete the Planning Poker® exercise by following these steps:
Select the smallest user story and assign 1 story point.
Relative to this smallest user story, size other user stories.
Select the story points from a preset scale (e.g., 1, 2, 3, 5, 8,13, 20+). The story point estimate can be based on any of one of the following parameters:
Unpleasant technical surprises
Experience of the team
Developer skill level
Available domain knowledge
If a user story is sized as 20+, use options to split the story to create smaller user stories.
Do not size a user story with more than 13 story points.
Never look back and adjust the numbers (story points).
After all user stories are sized, move to the task breakdown.
Break the tasks, which will be clear and small (i.e., can be completed in two days maximum).
Based on who is working on the task, estimate in hours.
Add all efforts at the task level, and ensure that tasks are within the team’s capacity.
In practice, when we want to implement Agile, challenges usually stem from a mindset change. Whenever I conduct training for new teams, most of the senior members/managers ask:
Q: Is there a relationship between story points (SP) and tasks hours? In the past, we have used function points estimation, and we can easily cross-check the team’s productivity.
A: No, there is no relationship between SP and task hours in Scrum. (Although I know that SAFe approaches it differently.)
Q: Is there a baseline for 1 SP = X number of hours?
A: There are no baselines across organizations, but for long-running projects, we can look at the trend.
Q: Can we estimate tasks first and then arrive at SPs?
A: By estimating tasks first, we are defeating the purpose of the estimation. Before the team goes deep into task-level estimation, they need only to have a rough work breakdown structure in mind to check whether they are missing any of the acceptance criteria or assumptions.
In Scrum, teams do discuss deviations that occur between estimations and actuals in retrospectives. By updating the parameters of estimations for upcoming sprints, SPs in that sense are self-adjusting.
Smart managers and team members still arrive at some agreeable number based on their Waterfall or Agile experience. In one of the sessions, I came across a participant who very proudly shared his formula with others: 1 SP = 6 hours of tasks; 8 SPs = 64 hours of tasks, which bothered me greatly.
When I requested an explanation at their retrospective meeting, I realized that they were not looking at data from a deviation perspective (planned vs. actuals), as they were pretty confident of the formula!
To prove that the participant’s method may not be sustainable in the long term, I asked for specific data from his team for all accepted and released user stories.
|Story points for each story||1, 2, 3, 5, 8, 13, 21+|
|Task-level estimated hours||1 SP = 8 hours (their original formula)|
|Task-level actual hours||Actual efforts that the team has entered in the Application Lifecycle Management tool|
By analyzing this data, I began to understand what was the best way to see through the relationship between SPs and hours.
One of the Scrum principles says, “Working software is the primary measure of progress.” Teams need to understand that working software (working functionality) is the only measure of progress, which can then be measured in terms of how fast teams develop it, given the requirement (in the form of a user story or feature).
Another principle says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. “This principle expects teams to look at the numbers or processes that are not working for them and improve on them.
By combining these two principles, and using Lean principles, you reduce waste by keeping work-in-progress items to a minimum and using the swarming method, whereby the whole team works on one story and completes it beginning to end. We need to look at throughput or cycle time for each idea, feature, or user story by entering into the Scrum execution model.
Where am I going with this notion of cycle time and SPs?
With data from the team and some investigation, I uncovered how teams have been performing in terms of estimates (given that they were using a formula to derive the 1 SP = hours estimates). I plotted the data points of actual time (cycle time) taken to complete similarly sized user stories from the Planning Poker numbers (i.e., Fibonacci series of 1, 2, 3, 5, 8, 13, and 21+).
When I shared these details in the form of graphs to the team, they were shocked! Because despite having a well-defined formula drawn from their experience, we could see large deviations from what was estimated (i.e., 8 SP = 64 hours).
Symptoms of the deviations
The team is getting pressured/influenced to use estimates according to the formula. There is little room for improvement.
Retrospectives are not in a real sense a PDCA (Plan, Do, Check, Act) activity.
Numbers/metrics are never discussed in retrospectives which results in fluctuations that remain in the system.
Baseline figures that are assumed at the start of the project are never revisited or re-baselined.
Because the actual time (cycle time) required for user stories is not discussed or root cause analysis is not done, teams can’t think of major improvement areas.
A large gap exists in terms of a user story’s acceptance criteria versus the actual implementation required (ineffective backlog refinement sessions).
Agreed-upon processes are not working for the teams (ScrumMaster is not working as an enabler of Agile processes and principles).
Teams are not cross-functional and cross-trained.
A better way
Encourage the team to log actual (real) numbers for efforts spent on tasks. (Planned hours ? (To do + Actuals))
Every sprint retrospective looks at the cycle time for similarly grouped story points.
Derive the lower control limit and upper control limit based on data, and set the targets in collaboration with the Scrum team.
If the team sees it is deviating from agreed numbers, raise the issue as an impediment in the Daily Scrum. This will help the ScrumMaster look at the process that is hindering the team.
Loop back the learnings for next sprint to improve on.
Circulate the learning; help other ScrumMasters learn from it in the Scrum of Scrums.
With this exercise, the team now looks at the cycle time at each retrospective and is able to see improvement in cycle time. The team can also reduce variability in the actual time.
The same model can be extended to the feature level, where similarly bucketed features’ cycle time can be looked at during the release retrospective meeting to improve in future releases.
I hope this method offers another angle from which to view data for improvement.
Zensar Technologies Ltd