It’s Effort, Not Duration
- Posted on August 24, 2010 8:29:PM by Application Administrator to Retrospectives
- Methods & Processes, Technique, Agile, planning, estimation, Management
A discussion on the LinkedIn Certified Scrum Master board led me to read an article on Mike Cohn’s blog titled, “It’s Effort, Not Complexity.” Mike argues that stakeholders don’t care about how hard it is to do something, they care about how long it will take. Fair enough. However, Mike went a step further, and effectively equates effort with time/duration instead of complexity. I respectfully disagree, and invite you to read his article referenced above before continuing (it will pop up in a new browser window)….
Okay, you’re back. I have to question the premise of this article, because equating effort to time is, in my opinion, a huge mistake. They are related, but not equivalent, and equating the two violates a basic rule of estimation: estimate size, derive duration. What ties effort and duration together is velocity, or the rate at which the effort is exerted to implement the desired functionality. Yes, stakeholders want to know duration rather than effort, but we are not helping them or ourselves by confusing or equating the two.
Instead of equating effort to time, it should be considered as analogous to distance. For example, Mike and everyone else reading this article can generally agree on what a mile is, and if one distance is twice as far as another, or half as far. However, we will disagree on how long it takes us to cover that mile because that is dependent on our individual abilities. Similarly, a world-class miler could accomplish the same amount of work more quickly than either of us. What’s the difference? Velocity.
Looking at the licking-stamps-versus-brain-surgery example, I would disagree that they should have the same measurement in story points. Brain surgery requires far more skill, and I think both a brain surgeon and a paper boy would agree that the effort required to lick a thousand stamps is far less than the effort required for even simple brain surgery… especially considering the differing Acceptance Criteria. That the brain surgeon can perform the surgery in the same amount of time as the teenager can lick and stick 1,000 stamps is due to the fact that his velocity for brain surgery far exceeds the teenager’s velocity for brain surgery even if their velocity for stamp licking is similar. Similarly, two different Scrum teams may agree on the same story point estimates for two different stories, but one team may take far longer to implement those stories due to their lower velocity (ability to turn ideas into potentially shippable increments of software functionality). Of course, how people do what they do also affects velocity. I can write the same functionality in assembler as I can in C#, but my velocity will be much higher in the high-level language.
Accordingly, I don’t really care about duration when I’m estimating because time-based estimates are closely tied to the person doing the estimate; I may answer “10 minutes” when asked how long it would take me to cover a mile while Carl Lewis may reply “5 minutes” and we are both right (if we have to run that mile in the time given) and both wrong (if we are estimating for the other person).
In short, story points are best used as a relative measure of effort/complexity/size instead of duration, and then a valid duration can be derived by factoring in the velocity of the people who will actually do the work. Remember, estimate size, derive duration.