Don't Use Story Points for Billing & Procurement!
Introduction
Currently, I'm engaged with a Fortune 500 Automotive OEM. Together with other Scrum Masters, I'm part of a community supporting the Agile Journey on the Management and Team/Project Level.
Recently there was a discussion in our Scrum Master community about estimating sub-tasks of user Stories and billing. One of us started by raising the innocent question "What about estimating sub-tasks of user Stories with Story Points? It's easy in Jira to detail a Story with sub-tasks. Should we estimate these tasks as well?"
Well, I'm not a fan of Story-Pointing tasks/sub-tasks of user Stories. Story Points describe at a high-level the amount/complexity to realize the entire Story. They take into account:
- the complexity of the tasks to be completed.
- the number of tasks to be completed.
- the uncertainty in the implementation of the user Story.
- the risk of implementing new techniques.
If the team estimates a Story with 12 points it's irrelevant how many subtasks the Story contains. Remember, Story Points are estimates and all estimates are wrong per se -- So we shouldn't be too detailed and bureaucratic wasting your time on detailed estimates. This results only in feelings of false Security and false Safety!
However, the discussion on Story Points for sub-tasks continues. Someone in the community replies, "...but for some external companies, Story Points are the base for billing."
Now my toenails began to curl.
AARRGH! — Stop buying Story Points!!
Why Story Points Don’t Fit For Billing And Procurement
The whole point to use Story Points for estimating was to demonstrate the fact that time estimates in engineering hours are garbage. Men-Hours are far from being objective or absolute and are stressed by personal change.
The question "What is the cost of a Story Point?" is irrelevant!
The point is, we can work out the cost of a Story Point for a particular team during a particular sprint after the sprint is finished only. Since these are situational historical data, they must not be used for forecasting. The data strongly depends on the past situation: swap a team member, change the scope slightly or change the circumstances in which work gets estimated and the result might be completely different.
Thus, Don't use Story Points for Procurement!
Story Point estimates are relative and subjective, factoring in a team's unique blend of experience and skills. 15 Story Points in team A for user Story X, is in team B — for the same Story — 7 points only.
Ok, if we really should use Story Points for billing, here is a business case for points-based procurement. When using Story Points for billing, the buyer had to send each vendor a reference 1 Story Point Story upfront. Then the vendors relate their estimates to this reference and respond by sending their quotes.
But, again, don't estimate sub-tasks of the Story.
Subtasks are only reminders or suggestions of potential work to be done to complete the user Story in the sprint. And their completeness is quite uncertain. During the sprint, we might realize that there is more to do than initially planned. A Story with 16 Story Points having 3 subtasks is equal in effort/complexity as a Story with 16 Story Points and 12 subtasks.
Thus, estimate on Story level only. Don't detail to sub-tasks.
The most crucial point in points-based procurement is Delivery Thinking. Points-based procurement misuse Agile to deliver ordered features. At its worse, the agile teams are captured in the Feature Factory mindset and the products to be developed might be doomed to Feature Hell, Product Death Cycle, and Product Build Trap. These terms name the consequence that products don't satisfy customers' needs and aren't accepted by the buyer resp. market. For more on this see my blog post about Agile Value Creation.
Two more reasons not to use Story Points for billing and procurement:
- A points-based procurement incentivizes the delivery of Story Points, not the value.
- Because Story Points are subjective and relative (no connection to hours), they’re quite easy to manipulate.
Both arguments are related to the well-known Hawthorne effect. The Hawthorne effect is a type of reactivity in which individuals modify an aspect of their behaviour in response to their awareness of being observed. If we know that Story Points count, how much are we paid, we trick the system by screwing up the number of Story Points we allegedly will need to finish the job.
In the Agile Community there are many better proposals for Agile Contracting than Story Points: Fix Price capacity, Full-Time Equivalent, Capped Time and Materials Contracts, Target Cost Contracts, and Incremental Delivery Contracts to name a few.
But, NEVER EVER use Story Points for billing and procurement!
To acquire agile delivery there are many ways. The buyer may purchase complete teams, individuals, or a service. The contractor can deliver variable scope on a fixed-price basis, using time and materials (capped or not), or some combination. Billing and payments can be based on completed sprints (the regular cycles of development and delivery) but may also be driven by other calendar dates, deployments, or any event that the parties believe is a fair milestone that is within their control.
Fix Price Capacity
The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial test phase after which the budget, due date, and the way of steering the scope within the framework are agreed upon.
This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance.
Full-Time Equivalent
A full-Time Equivalent is a unit of time defined to measure the workload or availability or capacity of an employee. In other words, FTE is the hours worked by a single employee on a full-time basis.
FTE is the simplest kind of agile fix-price contract. For example, a Scrum Team of 3 full-time employees and 2 part-time employees, working 40 hours a week (1 FTE) i.e., 8 hours for 5 days are the standard working time. Thus the team's total FTE becomes (3*1) + (2*0.6) = 4.2 per week. the FTE o a 2 weeks Sprint becomes 8.4.
Capped Time and Materials Contracts
Capped Time and Materials Contracts work like traditional Time and Materials contracts. However, in this agile contract management, an upper limit on customers’ payments is set. As a result, suppliers get benefits in case of early time-frame changes. On the other hand, customers need to pay up to the capped cost limit. It is a standardized measure to calculate project hours and staff count.
Target Cost Contracts
In this type of agile contract, the supplier and customer agree on a final price during project cost negotiation. These agile contracts work as a means of cost savings for both customer and supplier if contract value runs below budget. However, these agile contracts may allow both parties to face additional costs if it runs above budget.
Incremental Delivery Contracts
In these agile contracts, customers can review contracts during the contract lifecycle at pre-negotiated designated points of the contract lifecycle. These are the points where customers can make required changes, and continue or terminate the project.
Time and Materials
Perhaps the simplest of agile contracts is the time and materials agreement. This sort of contract works precisely as it sounds in that the supplier is paid for the time spent creating a product or delivering a service as well as for the materials that were used in its creation and delivery.
Leave A Comment