Agile Zone is brought to you in partnership with:

Mike Cohn is a consultant and trainer who specializes in helping companies adopt and improve their use of agile processes and techniques in order to build extremely high performance development organizations. He is the author of Succeeding with Agile, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. He can be reached through his website at http://www.mountaingoatsoftware.com. Mike is a DZone MVB and is not an employee of DZone and has posted 21 posts at DZone. You can read more from them at their website. View Full User Profile

It's Effort, Not Complexity

07.09.2010
| 3625 views |
  • submit to reddit

A client asked me last week “When will my team be done with this project?” This is probably the bazillionth time I’ve been asked that question in one way or another. I have never once been asked, “How hard will my team have to think to develop this project?” Clients, bosses, customers, and stakeholders care about how long a project will take. They don’t care about how hard we have to think to deliver the project, except to the extent that the need to think hard implies schedule or cost risk.

I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it’s wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.

In a class a few years back, I was given a wonderful example of this. Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery–snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points–each is expected to take the same amount of time.

This example also points out another aspect of agile estimating, which is that we assume that in general the right person for the job will do the work.We do not assume the little kid will finish school, go to med school, do a seven-year residency and only then begin the brain surgery while we have a skilled surgeon sitting in a cubicle licking stamps. Of course reality intrudes and occasionally the “wrong” person for a job does the job, but that will rarely be as dramatic as in this example.

So, story points are about the effort involved. Feel free to adjust your estimate of effort based on things like risk and uncertainty, but point-based estimating is about the time the work will take. It’s what our clients, bosses, customers, and stakeholders care about.

References
Published at DZone with permission of Mike Cohn, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emma Watson replied on Fri, 2012/03/30 - 6:02am

Do you recommend or at least empathise the need for a two stage estimation approach for this scenario. Also, would like to reiterate what others have said, the first estimate based on volume can be well understood by one and all – tester, BA, developer, user, etc.

Swing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.