Confused? This post elaborates on a couple of old posts by Mike Cohn once of the founding fathers of scrum, and on the replies to it. It is expresses in the form of mathematical formulae but I take no credit for accuracy of these formulae as they aim to stylistically represent the relationships rather give a calculable result. It’s a long time since I did maths at school 🙂
Effort [capitalized] is the time it takes to do something, and is an absolute value and can only be known if you have done that same thing before in exactly the same circumstances
“Effort, when being accounted for and quantified in a time and labor budgetary attempt is customarily presented in terms that include but are not particularly limited to staff hours, staff minutes, staff days, staff weeks, staff months, or, for particularly long projects, even staff years. ” — project-management-knowledge.com
effort [lower case] however, has a broader scope, it takes in to account the changing circumstances, including;
Both of these constructs apply during estimation, but at different points in the release. Whilst 2 applies at the beginning of the release 1 applies to the sprint. Let me see if I can explain in terms of a graph
Early in any release there is planning it is ongoing throughout the release and allows us to learn about what we are about to do. t=0 is the time at which the team starts doing the work, ‘execution time’ if you will.
At the start of the release t=-10 then we know very little about the detail of the work to be done (uncertainty), and the items are large and are perceived to be difficult because of this uncertainty (complexity), this may be real or imaginary, at this point we do not know, this leads to an unwillingness to commit to hard timescales (risk) as the possibility of successful execution is unknown.
As time progresses the team enter in to discussions with all the stakeholders, including the product owner to improve clarity, (reduce uncertainty) split the work into simplified, but still valuable chunks (reduce complexity). Once the work is clear and simple enough then the team will be confident in completing the work within a known timescale (removing risk) and start to execute the work
In formulaic terms;
As the values of complexity, uncertainty, and risk tend to 0 then effort (small ‘e’) tends to only be related to time, so ‘e’ gets closer and closer to ‘E’ once external influences are removed i.e
And referring to the first formula then since Effort = time then the closer to the time of execution and e has less and less unknown influence then
The next challenge comes in deciding what ‘arbitrary’ value of time are you going to use (post by Mike Cohn). It is asserted that it is possible to complete 2-3 stories in a single week. However this leads to another question, how big are these stories in points.
My rule of thumb: do not assume this is a 1-SP story, it leaves no wriggle room to complete anything smaller, my baseline, 3. Then 2-3 stories equates to somewhere between 6-9 points per week. Now, that’s good enough for me. But for others they want a single figure. Here goes;
Why 8? Simply cos it is a factor of 40, and we work around 40 hour weeks, and it makes the maths easier. 1 Story point therefore equals 5 hours
This is readily applicable during sprint planning when you know just about as much as you can about the work. But earlier in the release when effort is more affected by complexity, uncertainty and risk it is not going to be appropriate. Applying it here would be planning distant work in detail based on many assumptions which is a trait of traditional sequential planning techniques.
Circling back. Are story points the same as effort? Yes!!! Are story points the same as Effort? No!!! It depends at what point in the planning cycle you are
Story points during sprint planning are as close to Effort or time as you are going to get. This gives your stakeholders confidence in their ability to achieve their aims
Story points during release planning are still based on effort, but are influenced by the unknown, manifested as complexity, uncertainty and risk. But since release planning is about a distant horizon and detail is not required. Then this is OK….Remember the last responsible moment?