The Origin of the Question: Agile vs. The Invoice
The intersection of agile development methodologies and commercial necessity is often a friction point in the technology sector. Fun Man Andy, a strategic growth consultant focused on driving organizational change through culture, brought this very topic to a recent Braindate session at Atlassian Team ‘25 Europe in Barcelona to discuss with his peers.
Having spent years working in and consultant at a variety of companies in varied industries, Andy recognized a persistent and fundamental misunderstanding: how to credibly charge a customer for work estimated in Story Points. The core of this problem stems from an organisational divide:
Teams focussed on planning and delivering according to their complexities versus senior management who want to see their invoicing in good old traditional values: dollars against hours!
In this blog he dives into the not so subtle nuances, and what the answer is to this major conundrum that seems to confound almost all companies across the world.
From Complexity to Currency: A Consultant’s Dilemma
For over a decade, Andy’s message to business leaders has been consistent: “five story points is not $100,”!
Story points are purely a measure of complexity for the development team; they are not a currency that translates directly into a billable figure.
This disconnect was starkly illustrated by a CEO he once consulted for, a former sales executive who simply could not grasp the technical perspective. Andy presented two projects that were active in order to try and help explain Story Points vs Dollar Value, and coincidentally, both were budgeted out to be approximately $100K.
The difference was in the complexities:
Project A: was 80% R&D, high complexity, and low clarity.
Project B: was off-the-shelf software with some customizations, low complexity, and clear requirements.
The CEO noted that the total story points for the two projects did not add up to the same number, and he immediately asked, “How are they BOTH plus/minus $100,000?“.
The answer is that “in our company R&D burns huge amount of time, against highly expensive resources, and a high-complexity user story must be broken down massively to even begin estimation of those hours.
The off-the-shelf software with customizations, has a lot of hours on it, has a longer time frame, but is - for the most part - using junior resources who can handle low complexity.
Complexities in either research or more simple complexities are not a linear translation of a single story point number. At the end of the day:
“Story points have nothing to do with hours, estimates, or project timelines.” - Fun Man Andy
The problem is amplified when commercial pressure hits. Commercial Project Managers (PMs) often face a director who has “never done software development before“ but is “breathing down our necks“ for an estimate when a customer lead is hot.
Agile ceremonies are essential to work out complexity first, but in commercial environments, one must quickly pivot from story points to hours, and eventually against billable rates based on the required role.
The Time-Block Alternative
One participant in the Braindate - Sachin Dhamale of Amrut Software, an esteemed Solutions Consulting company - noted that their team often sidesteps story points entirely, opting to go “straight into the estimations” using time blocks.
“We, as an operational team, define cost based on hours, which is then used by our sales team against defined hourly rates for different roles. This is a pragmatic, business-first approach to defining cost, as businesses “have to have the estimation“ to answer the cost question.”
The conversation then highlighted the commercial pitfall of technical discovery, especially in complex areas like cross-system migrations. Andy notes business managers often typically balk at a discovery phase during pre-sales, viewing it as “free work” that a customer could simply use to put out an RFP to other vendors.
However, as a technical lead, without understanding a system’s complexity, you are essentially “going in blind” with an estimate. You must insist on a discovery period—even a paid one—to gather critical information and avoid blind estimation.
Often this is the point where Andy brings in technology to remove the human aspect and help teams focus on how to define their own Agile Ceremonies, bringing structure to the conversations, and often - for Atlassian users in particular - he turns to Scrum Poker by Catapult Labs. One of the key choices for this is in what Luis Ortiz once told him over a coffee at a Summit some time ago:
“We built apps that focus on Agile Ceremonies, and in particular Scrum Poker for Jira and Confluence, because we recognised that agile teams needed more engaging sprint planning sessions, and be empowered in reaching a structure concensus on estimation.
Scrum Masters wanted to avoid “groupthink”, and needed seperate voting, waiting to reveal each members estimate until everyone is ready!
Thereafter, by being directly in the tools the team use for their project work, estimates flow more naturally into the planning dashboard!
📣 Come join Fun Man Andy live during our upcoming Webinar on January 22nd, as he - supported by the Catapult Labs team - takes you through a Story Points vs Billable Hours adventure, fuelled by coffee!
The Coffee Metaphor: Complexity Defined
To truly capture the divergence between complexity and a simple cost, Andy often uses his infamous coffee metaphor to help understand the conundrum:
The Simple User Story:
”As a simple coffee drinker with a De’Longhi cap machine, I want a coffee ready in 5 minutes, so that I can get a quick caffeine fix and stay awake longer.”
This is low complexity and can easily be assigned 6 story points.The Complex User Story:
”As an artisan coffee maker with an Elektra Q1r Belle Epoque Riforma Limited Edition 3 Units, I want a coffee that takes almost forty minutes to create, so that I can feel superior to all other coffee drinkers and they will regard me with deep jealousy.”
This requires weighing beans, grinding, tamping, and pressure control. This is high complexity and is easily a 500-point task*.
*Nota bene to business managers: 500 points doesn’t exist in Scrum Poker. It is a facetious Fun Man joke.
The output - a cup of coffee - is somewhat the same, but the development effort, the process and the hardware, and therefore the estimated time, are massively different.
This comparison vividly proves that complexity (story points) should never be the basis for a uniform billable rate.
Another participant - Aaron Williams of RELEX Solutions, a highly experienced Atlassian System Specialist - loved The Coffee Metaphor:
“In my line of work, I am the type that’ll use a really inexpensive coffee machine to get the job done, and half the time with better quality than people with more expensive machines. My coffee machine only costs 80 bucks, but it tastes great! My work is the same…”
Sachin, Aaron and Andy enjoying a delightful debate on the subject, during the Atlassian Braindate session at Team 25 Europe, in Barcelona.
Conclusion: Drop Story Points for Billable Projects!
The final consensus from the Braindate was clear and Fun Man believes resolutely that it is critical for any organization in a commercial environment to:
“Drop the story points from commercially billable projects.”
For any project where invoicing is involved - whether time and material or fixed price - the process must move quickly to a detailed work breakdown structure with time estimates. Story points should only be used internally to determine if a user story is too large (e.g., over a threshold like 12) and needs to be broken down into smaller, more manageable stories.
Once broken down, the focus must shift to tasks and the hours required to complete them. As a participant noted, tracking hours is the only way to accurately calculate if a project is profitable. Tools in the Atlassian ecosystem, such as those used for finance and logging work, can help define a budget, track consumption, and ensure that the project stays in the “green zone,” but only if the underlying process is sound.
Ultimately, the tool is never the “silver bullet” that solves process and cultural problems. The people and their understanding of the difference between a development metric (complexity) and a financial metric (cost) must be aligned first. When the invoice needs to go out, abandon the complexity metric and focus on the time and materials required. As The Fun Man defined for himself and the companies he works for over the years, for billable work, you simply have to go straight into the estimates.
Only half of the answer
To be honest though - and Fun Man says he does truly feels great remorse that in this final segment of the blog - this is not the truly full answer to your dollar value billables, because the other aspect that is crucial in the war of Story Points vs Hour Estimates is, as mentioned above:
Work Breakdown Structure.
And that is a whole other blog in and of itself. But do not fret… we are working on it with great focus and tempo, and it will be launched soon! In the meantime, get yourself a seat in our upcoming webinar, check our DevEx Solutioning, and get acquainted with some amazing ceremonies apps that can help you with your Story Points and Hours Estimates.
📣 If you want to immediately learn more about the tooling behind DevEx Solutioning and Agile Ceremonies, check out Catapult Labs’ info on the subject.