The case for estimating in hours

Photo by Toni Verdú CarbóAlthough the vast majority of Agile teams estimate stories in story points (and tasks in hours) I wave the flag for hours instead. No points, just hours… or possibly days if your stories tend to be larger.

I do understand the argument for story points. It emphasises that we are estimating size, not duration. It depersonalises estimation, particularly when dealing with non-technical stakeholders. If something is estimated as “10 hours” a stakeholder can get very difficult if it starts going into a third day.

Dealing with hours is therefore more difficult. But I like it because of the honesty it forces out. It forces us to understand what “estimate” really means. In particular, it forces our non-technical stakeholders to understand that, and therefore understand better what it means to develop software. I find it odd when I hear marketing and financial people talk about “story points”. Simon Baker has said that he’s “never met a customer who liked them”. It seems we have forced some kind of weird made-up language on them, forced them to become like us, in order to cover up a nasty truth about our work. I’d much rather we technologists thought more like the stakeholders, and turned our language towards them.

My colleague Dave Putman commented to me that it was a question of “maturity” whether a business representative can work constructively with hours. It’s true that not everyone can manage that, and it does take time. If at all possible I prefer to help those people understand and work with the nature of software development.

9 thoughts on “The case for estimating in hours

  1. Why estimate at all? Estimates are always wrong so why waste time producing something that is wrong when that time could be used instead to build valuable, working software? Estimation is waste, it doesn’t really add any value.

  2. Hmm, that argument seems to be “if something cannot be known precisely then it’s not worth trying to find out roughly”. But any measurement is imprecise (for example, my laptop is 25.1cm wide, but that’s only accurate to one decimal place, and assumes I held the ruler straight) so by that reasoning nothing is worth measuring.

    I’d suggest that any measurement (or estimate, which is a rough form of measurement) needs to be sufficiently precise for the purpose at hand. If there is no consequence of knowing the measurement then I agree there is no point in attempting to discover it, however imprecisely. But if there is a consequence then a sufficiently precise measurement is worthwhile. For a software project, such a measurement may be taken once at the beginning, or regularly re-evaluated throughout, or both.

  3. Do you mean man-hours? Cycle time? Whole team time? Pair-hours?

    One of the main issues with real hours is that on the business side people are a bit prone to misusing the numbers and it can turn rather rather mythical-manhour. One advantage of points is it’s much more clearly impossible to incorrectly convert to pounds or misuse in other ways. Another advantage of points is that it auto corrects over/under estimation – do you still do this with hours by doubling estimates after or do rely on developers to do the doubling in their heads. Typical points estimation is done on the basis of if everything goes pretty smoothly and no interruptions so to switch to actual hours moves the “automatic doubling” (or whatever the load factor is) on to developers.

    What about other jobs the dev team does? Does that get factored in to the hours or sit outside it?

    Internally in one of our dev teams we are really estimating in “uninterrupted days if everything goes relatively smoothly” down to a quarter day (0.25) we just call it points because “ideal days” or “ideal hours” is typically quite confusing. We could convert “ideal hours” to “actual hours” but to make those add up to hours in the iteration would require hiding in those hours, planning, research, maintenance, support, etc many of those tasks not being related to the stories.
    If you don’t “load factor” up the hours to make it match the hours in the iteration it feels a lot more like a points system still!

  4. So what exactly are you trying to measure and why? The one thing that can pretty much be guaranteed about precise estimates is that they are precisely wrong.

  5. Matthew, I agree with all those comments about points. In short, if you use hours then you need to calibrate your estimates against all those other activities (that are also measured in hours). If you use points then no calibration is needed because stories are then measured on their own scale. The reason I like hours is because it forces you to do that calibration, and does surface those questions. Similarly with stakeholders who can misuse hour-measurements. This is what I was referring to when I said things “can get very difficult”. My preference is facing up to those difficult conversations and educating the stakeholder. Yes, it’s difficult; yes, it’s not always practical; but it is my default preference.

    Iain, why we’re measuring is exactly the question. If there is no reason, then there is nothing to measure. Or there may be valid questions, such as “This is likely to save us £5m, but how much is it likely to cost?” and “Are we still on target against our projected project cost?”

  6. Nik, you’re the one advocating estimating in hours. I’m advocating not estimating. Estimating does not tell us whether a piece of software (or any other product) is really going to save us £5m, or if we are on target aagainst our projected project cost. How can it? Estimating is making assumptions about what might happen in the future. It’s not a measure. Estimating won’t tell us how much something will cost either – especially in an agile world where we are going to be breaking items down into smaller items in the Product Backlog as we go (assuming Scrum), therefore the items will change but we may not implement a large item in its entirety as there may be parts that are not valuable enough. Requirements will emerge, priorities will change, learning will be done and we don’t know what we don’t know. All these things make estimates wrong. Oh – and remember the 12 principles behind the Agile Manifesto? “Working software is the primary measure of progress”………

  7. Iain, I’m quite happy to not estimate if the outcome is indeed not going to make a difference. But I also believe that sometimes it can make a difference.

    If a piece of software is suspected to make us £5m (which may or may not be correct, but that’s a question for the boardroom, not the engineering team) then it makes a difference if the cost is more likely to be £2m or £10m. The estimate I’m discussing in this example is the £2m or the £10m, not the £5m.

    Estimating can also be useful on a smaller scale. For example, if a work item is estimated to be very large (by some measure of “very large”) then it may be useful to spend the time this week on something else, instead.

    Working software is indeed the primary measure of progress. Estimation is a measure of projected progress. Estimation of projected progress is less real than working software delivered, but that’s not to say it has never has any value.

  8. Nik, alternatively, if a piece of software is expected to make us £5M and we’re therefore don’t want to spend more than £2M developing it, fix the cost and fix the time and then vary the features to get the most valuable product possible out of the £2M. We can balance how much we’re willing to pay against how much we think we will make – this is normally done anyway at the very beginning – before any project has started. I believe it’s sometimes referred to as a business case.

    If an item of work is too big, then break it down and do the most valuable parts. If it’s at the top of the Product Backlog, it should already have been broken down into smaller pieces where the most valuable ones are 2-3 days of work to make potentially shippable. Also, if it’s at the top of the Product Backlog, then it is the thing that the Product Owner wants first, therefore should be the most valuable. Why would you do something else instead of doing the most valuable thing?

    Unfortunalely you’re still not convincing me that there is any value in having a measure of projected success as it’s not really a measure in my opinion as you can only measure something that is real, i.e. working software and of course estimates are wrong. Now teams can spend time producing something that is wrong and has little to no value, or they could spend that time building some valuable working software instead. I know which I would prefer :)

  9. Iain, I’m going to try to make this my last comment on this thread, as this may otherwise go on indefinitely. You’re welcome to the last word after this.

    Regarding your first comment about the project with a £5m upside: Yes, I agree that is a good and common scenario. As part of this the business case would need to show how much could be obtained from a projected £2m investment, if not the full £5m upside. The process of determining what could be obtained for that £2m involves estimation. More precisely, I would imagine it involves estimating each element of the entire project, recognising that they total £10m, and then selecting the most valuable £2m-worth.

    Regarding your second comment about breaking work down: Yes, breaking things down into shippable 2-3 day chunks is good. And again, the process is (i) let’s break this down, (ii) let’s see if each of these bits is sufficiently small (i.e. 2-3 days), (iii) for any bit that’s not, break it down further. Part (ii) is estimation: it’s estimating whether something is sufficiently small.

    Regarding the latter part of your second comment, in which you ask “Why would you do something else instead of doing the most valuable thing?” The answer is: Because the value is often determined before the cost, and when the cost is discovered it may be found to outweigh the benefit. Of course, this issue goes away if the cost of everything is roughly the same (e.g. 2-3 days). But as I said just now, determining whether or not something is 2-3 days is an act of estimation.

    As aside (and I recognise this is not your point; it’s more directed at those who favour points) it’s good to note that your idea of sufficiently small is 2-3 days, a measure of time, not 2-3 points.

Comments are closed.