Story Points - complexity vs effort

Last post 05:44 pm September 26, 2019
by James Leach
7 replies
Author
Messages
10:35 am July 19, 2019

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

04:14 pm July 19, 2019

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.

04:39 pm July 19, 2019

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?

 

 

07:38 pm July 19, 2019

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?

07:47 pm July 19, 2019

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.

11:18 pm July 19, 2019

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?

05:40 am July 22, 2019

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?

03:14 pm September 26, 2019

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.