Story Points - complexity vs effort
Hello, I have a question regarding Story Points estimations - should those reflect effort, complexity or both?
I'm working as a Business Analyst in a project where we have 4 scrum teams and there is quite a heated discussion between the teams, very often followed by the given example:
There is a straight forward user story which isn't complex in terms of the problem that needs to be solved but requires a change in multiple parts of the code, unit tests, extensive manual tests, etc. Let's assume that it would take 30h to finish.
There is another user story which covers a complex issue in the business logic but required only 1-2 lines of the code, and all the related activities are not very engaging. However, due to the complexity of the issue, the completion of this user story would also take 30h.
The question now is whether those 2 user stories should be estimated for e.g. 3SP both (due to the effort) or rather first one should have been estimated for e.g. 1SP and the second one to 3/5SP (due to the complexity).
Of course, the above example is simplified, but let's turn the blind eye on it.
Thanks,
Thomas
Hi Thomas,
Great question, I have had this conversation many times with development teams.
What I have found is that its really down to how far in the Agile journey the team are. If they are doing Scrum superficially, the SM may want to measure in effort to allow them to track the time spent etc. This will also give you your reporting of how many hours on story A, did the developer meet the estimate...etc, which is not very Agile...
If they are fully embracing what it means to be Agile and are using Scrum as their framework to deliver value, then I would use story points are they are less restrictive as hours and dosen't cast expectations in stone as much as effort does. But this does make it more difficult to report to stakeholders on expectations, as long as you can convince them its the rite thing to do you should be fine I think..
I work with a major enterprise company who measure in both SP and hours. Another who uses SP, but then maps these to hours...
Why not try both? If you do make sure you set out your hypothesis correctly to ensure you maximize the learning from your tests then your best placed to make a decision.
I work with a major enterprise company who measure in both SP and hours. Another who uses SP, but then maps these to hours...
Nick, i see both of these examples as very wasteful. In one, estimations are being provided in two different formats (relative, time). In the second example, relative estimates are being translated to perceived time equivalents. This seems to be a large amount of overhead being applied to what are (it needs to be stressed here!) estimations.
Perhaps both examples would benefit from a single estimation method?
To Thomas' original question for this thread...
Effort and complexity should both be considered when comparing one item to another and coming up with a relative estimate.
A frequent analogy that I use is a boulder. Think of each PBI as a boulder that the team needs to move from point A to point B.
The weight of the boulder can factor in to the "effort" consideration. The length between A and B should also factor in to the "effort".
But that is only part of the puzzle. Complexity is present as well. What is the shape of the boulder? Is it completely round, or is it uneven which provides opportunity to grip it better? Is the distance between A and B level, or is it uphill/downhill? Is the path smooth, or uneven with divots and holes?
All of these factors are part of the equation, and have nothing to do with guessing how long it might take to move the boulder from A to B, or who might be moving the boulder.
Bottom line - the team needs to assess the effort and complexity of one item against another, and this judgment is 100% germane to the team that will be doing the work. Is a 20-lb jagged boulder that needs to be moved 20 yards uphill bigger or smaller than a round and smooth 10-lb boulder that needs to be moved 30 yards across an uneven field?
Nick, i see both of these examples as very wasteful.
Appreciate the feedback Timothy! I completely agree these are estimates maybe I miss understood the question... however I have not found a better method to yet to satisfy both devs (who like sizing) and PO's & stakeholders (who do not like sizing thus want hours).
This seems to be a large amount of overhead being applied to what are (it needs to be stressed here!) estimations.
You are correct this is more overhead, but is very little in reality, and the clarity they provide is good ROI for our stakeholders.
I have a question regarding Story Points estimations - should those reflect effort, complexity or both?
What would the Development Team like taken into account, when it comes to figuring out how much work they can do in a Sprint?
Isn't there a blurred/fine line between complexity and effort? I mean if a PBI is "complex" that it needs additional experimentation and research, therefore you would need more "effort" to do it, right?
A frequent analogy that I use is a boulder. Think of each PBI as a boulder that the team needs to move from point A to point B.
I like this analogy and I like where this conversation is headed. This is a topic my team is currently faced with that we are trying to solve.
Would people on this thread agree or disagree with this formula?
Complexity = Amount of Work + Degree of Risk + Level of Uncertainty
This Complexity being the benchmark for estimating story points.
Would people on this thread agree or disagree with this formula?
Complexity = Amount of Work + Degree of Risk + Level of Uncertainty
Nope, It's:
Effort = Complexity + Amount of Work + Degree of Risk + Level of Uncertainty
I would echo @Ian comment here !!
Is there is any standard law or guidelines which Scrum Guide defines how the estimations have to be ? What do the development team think, they should consider while making the estimates?
My only question is why do you need a formula? These are ESTIMATES which are guesses which usually are Wild A$$ Guesses. You can apply a formula to estimates but that really only makes them Scientific Wild A$$ Guesses.
I usually have a new team discuss how each individual arrived at their estimate so that people can start to come to a consensus on what is taken into consideration when estimating. You will start to see estimates becoming standardized by the team members. Give them a formula and it doesn't help. For example how do you define complexity, degree of risk or level of uncertainty so that everyone is using the same scale?
It doesn't matter how teams estimate…
…as long as the technique achieves whatever purpose estimates are being used for.
I suggest as a Scrum Team, consider what you can gain from estimating effectively. What's the purpose of this exercise, regardless whether you use story points, or any other technique?
I've thought about it a lot, and consider 4 main reasons to estimate:
- Allows better forecasting (for the Product Owner and Development Team)
- Helps the Product Owner with prioritization
- Surfaces misunderstandings of scope
- Highlights the need for items to be broken down into smaller deliverables
Once the Scrum Team are clear about what they want from estimates, I suggest letting the Development Team choose the technique that lets them achieve that.
There is no requirement for estimation to be perfect. It should be good enough to produce generally helpful estimates, without being so complicated that it introduces unnecessary waste.
…as long as the technique achieves whatever purpose estimates are being used for.
Yes, good point! Do you believe that, for forecast purposes and already having statistics from teams for a considerable timeframe, we can assume estimation as a finit resource? I mean, building a bigger burndown for a project maybe.
My advice is do not get hung up on the story points with the team, remember whatever works for the team to identify how much work then can take on in a single sprint to get something delivered at high quality is the goal.
How the team figures that out is up to them. Explain that the story point estimates can help. The simplest thing can be pick one item, give it 3 points and base everything else of that. Leave it that simple and see how it goes.
Write a good DoD with the team and create a habit where the team refers to it with every estimation session.
I find mentioning complexity and not effort is always too difficult. I usually ask the question "where is the risk here" let the team answer and then decide if the risk can be reduced asap.
After a few sprints good teams can usually know how many items they can take on comfortably and also leave 20% aside for the unknowns.
Thanks for the advice!
My idea was not using this approach to deal with teams, but to deal with POs about what can be brought or not to DevTeams to work on.
A story point is an attempt to create something like a kilometer, so that we can use a simple math to predict arrival times for example (Distance = rate * time)
Unlike distance there is no formula to calculate Story Point, but you have 2 different estimates
- Complexity estimate
- Time estimate
Complexity Estimate:
- Label change in a configuration file which fixes 1000 labels in UI across application
- Label change in 1000 places manually
Complexity for #1 and #2 is the same in this case – “Label Change” but time estimate will be different. Assume the complexity is 1SP for both #1 and #2 but time can be X and X+100 mins.
Also time will vary from person to person, A newly joined team member may take more time than the senior person to solve the same complex user story
(or) an experience person who was delivering a story in 5 hours might now be a expert to deliver a story of similar complexity in 3 hours. Time will vary from person to person at various stages.
Why you need time estimate?
Business needs to predict the time of arrival, Business may need to forecast based on the last few release from the team . Give freedom to every member in team to do time estimate for the stories which are picked up.
Time estimates will help the individuals to introspect and improve on uncovering the unknowns in the story much earlier. It allows to coordinate with other team members and predict the release of the story in the sprint and subsequently release to customers
This enables openness within the team members to discuss together and provide a commitment together.
What is the mantra needed?
The mantra needed is more refinement, less estimating (I am not saying don’t estimate!). Estimates have no user value, so do as little estimating as possible. Refinement (making big stories smaller) builds understanding of the problem to be solved and creates fine grained confirmation for each pieces of the large story.
Allow individuals working on user stories to come up with their own time estimate, but make sure individuals together estimate the complexity as part of refinement! No math between Complexity and Time.
More math between Complexity and time is Garbage. Remember Garbage In, Garbage out!