Estimations in budgets and costs

It’s been many years since I’ve estimated feature effort in meaningless measurements, such as “story points” or “feature points”, and this makes me quite happy. Several years ago, on a long agile project, we estimated all effort in points. But nobody knew what that meant. What is a point? How do you know what a point is? Relative complexity? We heard comments describing this process as a “Shell Game”.

Ultimately, our currency is time. Looking at the iron triangle, where we see “schedule”, the only true constant is time:


I’ve seen budgets change, I’ve seen scope added and removed, but I’ve rarely seen a deadline extended. And unless a we’re traveling a significant percentage of the speed of light, we can’t really stretch our time.

Yet I meet many teams that still estimate in points. But to anyone that actually writes a check, a point is meaningless. Teams have a known cost in salary, and the salary is paid on a periodic basis. We can calculate with great certainty the cost of a developer. Those approving projects and budgets deal in dollars and cents. Coming to them with the cost of software in imaginary points is a quick way to get laughed out of the room.

Instead, I want to deal in concretes. Hours or dollars. How much is this feature expected to cost me? Points vary over time. What was complex last month might be easy this month. Time doesn’t change, however. If the people approving projects and budgets deal with dollars or time, our estimates should match their expectations and their realities, not our own fictional cost.

Budgets and costs

Instead of thinking in terms of estimates, I want to deal in costs. How much is this feature going to cost me? How much should I allocate to specific areas?

When looking at personal finance, we generally deal in budgets. There’s a certain amount of income per month, and a certain amount of dollars we want to allocate to certain areas:


We know we cannot exceed our total spend (there’s no credit in software development), but what we can play with is the relative amounts within each area. Software estimation works the same way. There are different areas of concern (reporting, administration, etc.) that can be given a certain amount of budget (time) within a certain scope of release. This budget can be made of either time or dollars, but those are effectively equivalent if we average salaries in our team.

From there, we start looking at costs of individual items. We don’t know exactly what our electric bill may be this month, but we can make an educated guess, looking at past months. In estimating software features, we need two things to estimate well:

  • Small, understandable scope
  • Well understood, agreed upon design

Typically, I like a story to be flushed out well. “Card and a conversation” is OK for initial planning, but for deciding what to actually work on, lots of details need to be understood to get an accurate understanding of cost. For an item that costs 3 days of development, I might expect a day of design/elaboration/documentation. All parties involved need to have a shared expectation of what is to be delivered. Shared expectations means much, much less rework. I like my stories to be in a persistent medium, whether it’s a wiki, JIRA, Google Docs, whatever. A card on a wall can only really be a pointer to the real story, not the actual story itself. Small stories are important. If the estimate is over 2-3 days, it’s less accurate and more difficult to design, develop, test and generally agree upon.

Budget’s aren’t perfect, and neither are estimates. But the ultimate constant is our overall available time allocation. If bills are unexpectedly higher one month, we have less to spend on movies and entertainment. Similarly, our stories have priorities so that if something goes over, something gets pushed out. It’s the only sane way to maintain a sustainable pace. If something goes wildly over, we have a quick retrospective to understand why and how we can fix it (no need to wait for some periodic meeting to do so, have the conversation while the wound is fresh).

The cone of uncertainty still applies, which is why we talk in budgets instead of costs early on. I can’t know how much I’ll spend on a meal a year from now, but I can at least commit to a budget for a group of meals, and vary the scope of meals as I understand exactly where and when I’ll be eating.

Ultimately, points mean nothing. What we do have is dollars and time. By approaching estimation similar to budgeting, everyone, including stakeholders, can share a common understanding of costs and priorities. We can finally bypass tiresome arguments about what exactly a story point means.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jaime

    I’m think is an interesting notion, how do you deal with the initial sprints/milestones estimation? I’m mean if your building something you haven’t built before, chances are that your initial “educated guesses” are going to be off by a good amount. In my mind points help you abstract the conversion ratio points/time and adjust it as you get more stage velocity, if you estimate in time/cost per story when your off by 50% the perception is that the project is going to cost 50% more, when in reality you’re just adjusting your velocity.

    What do you think?

  • Pingback: Estimations in budgets and costs | I can explai...

  • Adrian

    In the UK, most of the projects I work on, time isn’t any more constant than the budget or scope, all 3 constantly extend. Projects continually overrun and the biggest cause isn’t the methodology, but lack of any software experience in the management or team leaders. I think if anyone hires someone as publicly active in the DDD sphere as yourself, then they’re already making a smart move. They’re saying “I know you know your stuff, so I’m hiring you to run the show”. A lot of the time, I work for people who once managed production lines, a coach travel company, sell carpets or they have a masters degree in languages. They really don’t know what they’re doing and their ego doesn’t let them admit this and give control to someone who does.

  • Jas

    I’m not sure I fully understand the method you used to make better estimations. I agree you can’t go to users and talk in fairy points, but why not convert “points” into a currency that the user/decision makers understand such as time or $?

    • jbogard

      Why convert at all then? Why not just talk in absolutes?

      • Robert Daniel Moore

        Because developers are really bad at estimating how long something will take, but much better at estimating the relative complexity of two different pieces of work.

        In saying that, if you move to more of a lean/kanban approach then you can simply try and keep all work items roughly the same sort of size and it doesn’t matter – you just plough through a prioritised list and optimise for flow. Some of what you wrote in the post hinted at this type of approach.

        There is also some really interesting stuff coming out of the #noestimates camp, e.g.:

        • Nathan Alden, Sr.

          It’s not that developers are bad at estimating. Hearing that parroted all over the Internet is getting tiresome. Estimating the creation of software, especially in a team environment, is almost impossible to do precisely or accurately. No one can predict the future; all we can do is look at past data (trends) to see what is statistically likely to happen in the next couple of weeks. Would you expect a painter to be able to estimate with precision a great work of art? No, you wouldn’t. Modern software is inherently complex and is mostly a *human and communication* problem–two things that are flaky and imprecise by their very natures. We’re not simply putting together the same widget in the same way over and over again; we’re painting–unless you’re NASA.

          Point estimation acknowledges and embraces the imprecise nature of software development. Estimating in points is valuable in order to gauge *relative complexity.* Point estimation is *not* valuable for figuring out if a deadline will be met; for that, use trend analysis (velocity).

          Let’s stop pretending we can predict the future with certainty. I can’t tell you if Product A will be done by Date B because chances are even *you* don’t know exactly what features and functionality define Product A.

          • Robert Daniel Moore

            I completely agree with you FYI – it’s just easier to say “developers are bad at estimating how long something will take” – as you point out there is no way they could be good at it, because it’s a fundamentally flawed concept ;)

  • kelly brownsberger

    This hasn’t been my experience at all, but we have never tried to use points as something we speak to stakeholders about. Point estimation is a tool we use within our team to stay focused and lean – estimation is an imprecise exercise and therefore you really should aggressively cap the amount of effort you pour into it.

    Before story points we would spend *enormous* amounts of time just trying to get a rough estimate. More often than not our stakeholders care less about precision of estimates and care more about minimizing the amount of work sunk into trying to achieve precision. Story points are a great tool to let the team think in terms of relativity instead of absolutes. When you demand absolutes from the team, estimates skyrocket and so does the cost of estimating.

    We track what the relative story was we based our estimates on. We also track actuals in hours. So, converting points to hours/$$ is trivial. And we always do that before talking to stakeholders :)

  • Christopher

    I started to reply in a comment, but decide to blog instead