Developers are, in general, more aware of the potential complexities that they can run into in the process of implementing a story. Despite this cognizance, it is often hard to predict exactly what these complexities might be. Obviously, if a developer knew the exact nature of the issues that he will run into, he can account for those and predict exactly how much time the work might take. Since this knowledge can never be complete, no developer can determine the exact amount of time needed.
Further, depending on the specific process being used in a given team, it is possible that the developer(s) who estimated a given story is not the one who ends up actually doing the implementation. Different developers have different skill levels and differing amounts of domain-knowledge. This also contributes to the variance in the actual time taken for implementation.
Finally, there are things that developers have no control over – the so called external factors – source-control going down or behaving erratically, having to attend meetings, or having to help another team or another developer on something, and so forth. Someone with critical knowledge could be out on vacation or a key developer could fall sick.
Lets represent actual time taken by a developer to complete a story with the following formula ->
A = function(C, U, E, S, K)
where
A = actual time
C = an idea of complexity (how difficult something is, and how many tasks there may be),
U = unpleasant technical surprises,
E = external factors,
S = implementing developer skill level,
K = available domain knowledge
Clearly, the only thing that can be “estimated” here is C – an idea of complexity (also based on the “understanding” of the team – whatever that is, and however it can be quantified). Let’s say that we measure this with complexity points (or story points). If we assume that everything else will get averaged out over the duration of the project (which it usually does), then it all comes together quite nicely. This is why story point estimation works.
On the other hand, trying to estimate using hours is like trying to guess the effect of the other four (and possibly more) factors. Trying to estimate in hours is like trying to estimate both the effort needed due to complexity AND the velocity of the people working on the story.
Finally, if I hear someone say that they have a capacity of 200 real hours, that they’re signing up for 300 hours of work and end up completing 250, then in my mind, the 250 hours of work that got done (which can’t be squeezed into 200 real hours) might as well be 250 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 200 real hours (time doesn’t change), they signed up for 3000 points and got 2500 done, it will not change a thing. Story points are story points. The team can call it “ideal hours” or “estimate hours” or whatever they like. As long as they’re not real hours, they’re just like a rose with another name…
~SA
Having tried hours, ideal hours and story points, I'd have to agree that story points are the most useful units I've found for estimation. Most people I've worked with are not espcially good at saying how long something will take, but no one has had any trouble identifying relative size (or complexity).
ReplyDeleteexactly, that is why complexity is the only thing which can be estimated. We can estimate story points based on the complexity because story points are variable thing & others elements can accomodate in story points however if we estimate in hours, we need to consider other elements (like unpleasant technical surprises, external factors, implementing developer skill level, available domain knowledge) at the time of estimation because these elements may impact your estimated time (hours) & we all know that time is not a variable thing, It is fixed.
ReplyDelete