Fervent Coder

Coding Towards Utopia...by Rob Reynolds
posts - 278 , comments - 431 , trackbacks - 0

My Links


Rob Reynolds

Subscribe to Fervent Coder RSS
Subscribe to Fervent Coder by Email

About Me

I manage several open source projects. Need...
   ...package management for Windows?
   ...automated builds?
   ...database change management (migrations)?
   ...your application to check email?
   ...a monitoring utility?

I also write for

Like what you are reading? Want to buy me a cup of coffee?
PayPal - The safer, easier way to pay online!


Post Categories

Image Galleries


Do Story Points Relate to Complexity or Time? Response

I was recently pointed to an InfoQ article titled Do Story Points Relate to Complexity or Time? It mentions that some teams estimate by a matter of complexity versus how long in effort something will take. Mike Cohn, who wrote the original post It’s Effort, Not Complexity, makes some very good points into how people should estimate based on how much time a story will take to finish versus another story. Relative effort, not complexity. The argument here is that complexity should not matter if two stories take the same amount of time to complete.

I thought Mike and the article illustrate some very important points. Effort is different than complexity. The InfoQ story mentions:


Dentist - In a BOX!
Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

I am humbly reminded of the humorous video on the right (Dentist – In A BOX!) when presented with this idea of performing brain surgery. The other part of the story that was great talked about story points being a function of effort, risk and uncertainty (link back to Mike’s original comment):

Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.

I do want to point out what Mike mentioned in one of his other comments:

Thinking of points as a function of Effort, Complexity and Doubt is fine. In my reply above to John I just combined Complexity and Doubt into one thing: Uncertainty.

Points are a measure of how long it will take (effort). How long it will take can be affected by other things and those can influence our estimate. The key is to remember and understand that it is always about time–no client ever cares how hard we had to think, only how long it took.

“No client ever cares about how hard we had to think,only how long it took.” What I believe I am hearing is that Mike is not discounting that there is effort in understanding. Thinking, research, and learning time is still effort, and I think a lot of people miss this important point when they talk about effort. The example provided was a doctor versus a boy on the two tasks. What happens if they are the same person and that person is not a doctor? What if it’s you?! In my mind, that makes a better determination of what developers face when estimating a simple problem versus a complex one.

Let’s explore this idea in more detail. What all goes into the effort required to lick 1000 stamps versus perform brain surgery if you had to do them? Sure the effort of actually performing the task is roughly the same, but the effort to learn how to lick a stamp is significantly less than the effort required to learn how to perform brain surgery. And that I believe more accurately represents what we as developers go through.

To further illustrate, where I work, we also take stories and estimate tasks from those stories. With that I have started including ramp up time as part of the effort for my team as developers. A problem could take 15 minutes for me to code. But it might take me 2 hours to understand what it is that needs to be done. That is not a 15 minute task. That is a 2 hour and 15 minute task. And the effort involved was 2 hours and 15 minutes.



kick it on DotNetKicks.com Shout it

Print | posted on Thursday, July 8, 2010 9:13 PM | Filed Under [ ProjectManagement ]


Comments are closed.
Comments have been closed on this topic.

Powered by: