Agile estimation – story points vs. hours

Once again, discussions at work have driven me to write this. This time, the topic of debate (or rather, amusement) is that in an agile team, hours (or days) and not story points are a better way to estimate user stories. I disagree.

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 400 real hours, that they’re signing up for 600 hours of work and end up completing 500, then in my mind, the 500 hours of work that got done (which can’t be squeezed into 400 real hours) might as well be 500 story points. In fact, you can up the numbers by a factor of 10 so that the team really had 400 real hours (time doesn’t change), they signed up for 6000 points and got 5000 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…

On developers who become project managers

We’ve recently been having quite a few discussions at work around what makes a good project manager. One, what I thought, rather odd remark someone made was that a person’s developer background can work against him (or her). Ouch!

I believe that is a bizarre statement. It’s like saying – someone with a background in advertising should not lead a marketing team. Why? Because it becomes easy to get tied down into details of the work – rather than looking at the bigger picture, and towards the overall success of the effort vs. whether or not the actual work was fulfilling enough on any particular dimension.

Hmmm. Interesting. In my view – if a person can’t elevate his mind to look at the 10,000 foot picture or even the 50,000 foot picture (or whatever the “high-level” is supposed to be), then that is the fault of the thinker – not of his or her particular background. I’ve seen managers without developer backgrounds that love to poke about in the business of programmers trying to do their job. Not only do they make fools of themselves in the eyes of those very people, but their sea-gull management also leaves the project further away from achieving success. The same holds good for the argument that developers tend to trivialize the administrivia of project management. I think that that is at the very most a correlation, not a cause. I’ve seen plenty of non-technical folks mess up adminstrative tsks. And I’ve seen developers do a fantastic job at mundane tasks – sheerly from doing what their logical, step-by-step mind tells them they should.

I’m sorry if I’m being idealistic – but I happen to think someone who leads a company that makes cars should actually know something about engines. And a manager who wants to run a software project should have developed code sometime in his life – for a living. Preferably, he should still be doing it.

Now, to be fair to the person who made this comment, I’d like to admit to one thing. There can be managers who are/were developers who do a worse job than other non-techie managers. Just as there can be non-techie managers who are just so poor at their job that they single-handedly kill software projects wherever they go. I think the spectrum looks like this –

[Bad managers (techie and non-techie)] – [good managers (techie and non-techie)] – [good managers (techie)]

Anyone can fall towards the extreme-left side of the scale. And good, people-focussed managers can fall towards the middle and sidle towards the right. The good guys are in this very region – and can include techie and non-techie people. But to fall on the right-most part of the scale – (again, in my view), you just have to have a mind that truly gets software development. And that also means to understand what an asynchronous event is, and why they’re harder to write tests for. Or why dependency injection is a Good Thing.

Also, I’d like to admit that there are managers who can fall on the extreme-right of the scale without being technical – by the sheer dint of their people-skills, communication abilities and understanding of the software development process. So much so, that they make up for their lack of knowledge about the very thing being built by their own team-members. Sometimes, domain knowldge makes up for a little bit of this lack. Unfortunately, these people are few and far between.

I’m saying this from the most general point of view. There are projects and situations where this may or may not apply. I do believe, however, that this is the case in most projects and companies. Finally – rather than repeating what Joel Spolsky has already said in his inimitable style – I’ll leave you with this link to his essay.