One of the many people who I follow on Twitter is @jbogard and I find his articles on NServiceBus and SOA of great interest and very illuminating. A couple of days ago Jimmy Bogard posted on why we shouldn’t use abstract points to estimate, but rather use time and money, because that’s essentially the only thing anyone cares about anyway.
I had a few things to say about this, which I almost typed in a comment, before realising I was severely slacking on my Hanselman-inspired endeavour to contribute instead of just devour, and should perhaps elaborate in a blog post.
Now, I agree time and money is all anyone cares about and we need to be both conscious and sensible about it as developers, but that doesn’t mean you’re going to get a more accurate estimate or better results by reverting to basing your estimates on it. Story points are a relative estimate of complexity that the team uses internally to estimate how much they can commit to in a single sprint. They also allow the Product Owner to use this measure when prioritizing stories at the top of the backlog.
The ‘Iron’ Triangle of Resource/Scope/Schedule referenced in the original article is indeed an extremely effective way of articulating the fundamental constraints (anyone who’s ever had any building work done can attest to this). Assuming that resources (e.g. number of people) and schedule (your deadline) are constant, how do we achieve everything we want to without sacrificing quality? We have to cut scope. But how do we know what scope to cut? Well we start one sprint at a time, getting feedback, re-prioritizing, and changing requirements one sprint at a time. In this way we can guarantee that a) at the end of every sprint they will have a working product and b) that the highest priority features will be included in the product by the deadline. This could also be summarised by the statement “don’t ask me when ‘it’ will be done, tell me when you need ‘it’ to be done by”. In fact, if resource and schedule are indeed constant, then surely they control your budget already? Now all that remains is what are you going to get for it.
I find the most effective way to answer that old favourite “when will it be ready?” is to counter with another question “how much money will it make?”. Which is probably why when estimating business value, an abstract relative metric is often also used.