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 agile project management 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 estiamte 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.
Tags: Agile Estimating, story points
Hi Jake–
I’m glad you’ve enjoyed our discussion here. The only thing I’d add on complexity & time is that complexity influences time and may sometimes be the biggest driver of the time that a story will take to develop but we are not directly estimating complexity because other things are involved (e.g., sometimes the sheer amount of work to be done).
One possibly last attempt at eliciting from you what all the others have tried so many time before – as I am still not convinced that one size fits all – no pun intended. Well, SP = f(E,C,R) is the best we could get so far in line with our thinking – and in fact as you mentioned on one of the latest comments E = f(C, …) – hence does not need separate mention. But why not a story-point reach out to a larger audience by saying S.P. = f (V, C, R) where V is the Volume of work as perceived by various audience – read function points, feature function points, screen elements and actions, report groups, or whatever be that is related to the Work Product and not the work itself. So, would like to see SIZE as the work product / item SIZE and not the work SIZE. Of course we can adjust it to work size based on a technology and tools we use – usually a deferred decision based on lean principles and Murphy’s law.
Taking the example of the painting mentioned earlier – I would like the estimate for painting the wall to be initially same when I do story estimation irrespective of whether I manually paint it or whether I use a robot or machine. Usually is the target robot or machine friendly gets detected much later and we can of course account for it when we split to task estimates in hours or a pre-sprint story point adjustment.
Same holds good in IT examples as well where some features can be implemented using high-productivity tools and frameworks while others due to their nitty-gritty requirements may end up being built using more low-level technologies.
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. – while the second level is usually a story of the elephant and the blind men – where complexity is purely from the perspective of difficulty of test automation or code generation or design or integration etc.
Some concrete examples where we have a degrading level of productivity in chosen technology – just to get the message across well – Sharepoint direct feature vs. .Net web part, direct informatics transformations vs. custom transformation, jasper reports vs. custom Java Script vs. Flex Reports.