We recently worked with a client who do outsourced software development. They were looking to start using Scrum with a bit more discipline than they had in the past with their own home grown implementation. We ran a pilot with 2 teams over 6 weeks, which turned out to be a great success. The teams were deliberately considered with two particular test cases to see how well the approach worked in their environment. One team was focussed on work for one particular client. The second team was doing work across multiple clients.
One of the key issues that came up in the pilot was how they would transition to a billing model that would work well with Scrum. This was particularly true for the team that was working on several different client projects in a single sprint. This was further complicated because each client has a different contractual relationship. Some were time and materials contracts, some fixed price, some paid for a number of FTEs (Full Time Equivalent). Their traditional timesheet approach was difficult to use in this scenario.
Some of their challenges were:
- How do they record a 2 hour backlog grooming session which covers 4 different client’s items, without having to fill in time sheets practically by the minute?
- How do they ensure that a client who paid for one FTE, got their money’s worth when work was no longer assigned to individuals?
- How do they track what fixed cost projects actually cost them?
- How did they know what to bill time and materials clients each month?
Here is an outline of an approach we presented to solve these problems.
Time and Materials
Most employees I’ve ever met loath time sheets. Usually someone has to be the timesheet nazi who nags people to fill it in before billing can be done. Often when it is filled in it’s not accurate because people can’t actually remember what they did. So I’m always interested in finding ways to get rid of time sheets. If you are using story points, and velocity it’s pretty easy to do this.
Imagine:
We have a team of 5 people, plus a Scrum Master and Product Owner – so 7 people.
Let’s assume they each work an average of 150 billable hours per month (80% utilisation), this allows some time each month for leave, holidays etc. You can change this figure to whatever is normal for your organisation.
The team does 2 week sprints, so for the sake of simplicity we say they do 2 sprints per month.
Therefore each sprint is ( 5 people * 150 billable hours ) / 2 sprints in a month = 375 billable hours in a sprint.
If the team does 20 points in total for the sprint, you can calculate the billable hours per point. 375/20 = 18.75
Now if client A had 8 points done in the sprint, you should bill them for 8 * 18.75 hours = 150 hours.
FTE (Full Time Equivalent)
For FTE’s you need to change the way you schedule work, rather than how you bill it. Usually the client is paying a fixed amount for the equivalent of 2 full time people. However those people are now part of a team. Instead of getting 2 people, they are actually paying for a fixed percentage of a team.
Imagine:
With the same team above of 7 people. Imagine one client is paying for 2 FTEs on that team. That means they are paying for 2/7 or 28% of that team’s capacity.
When planning work for a sprint the Product Owner should reserve 28% of the team’s velocity each sprint for work from that client.
Again if their average velocity (over the last 3 sprints) was 20 points per sprint. Then this client should get 28% x 20 points = 5.7 points of work each sprint. Obviously there is no such thing as 5.7, but this would mean 5 or 6 points each sprint depending on what work is prioritised, but you can be a bit flexible. If the team took on say 8 points in one sprint, they might only do 4 in the next sprint. This would average to 28% over the 2 sprints.
Fixed Price
What about fixed price? Although this doesn’t impact the client, the company still needs to track how much time it spends on these projects to ensure it is profitable. You can do this simply by applying the Time and Materials approach and tracking the hours spent vs the estimate. However if you’d like to get rid of the time component completely, for example if you’d like to track the cost of an internal project, you can just use story points and the cost of the team.
Imagine:
The team above is also working on a fixed price project. You need to add up how many points the team did in total each sprint, as well as the points for the fixed price project.
In sprint 1 they did 6 points out of 20 on the Fixed Price Project and in sprint 2 they did 6 points out of 25 on the Fixed Price Project
You also need to know the cost of the team. You can work out a monthly cost of a team by adding up each persons cost to company. Be sure to include any standard overheads like office space etc. Divide the monthly cost by 2 to get a cost per sprint. For the sake of simplicity lets say this team costs $100,000 per sprint.
In sprint 1: 6/20 or 30% was on the fixed price project = 30% * $100,000 = $30,000
In sprint 2: 6/25 or 24% was on the fixed price project = 24% * $100,000 = $24,000
Total spend on the project for the month was $54,000
Estimating costs with Agile
The examples above all show how you can invoice work done with Scrum, that was contracted on a more traditional basis. This is critical for teams that are transitioning and still have old contracts in place that they need to service. However going forward it helps alot to try to make the estimation and contracts fit better with agile. Some options for how to do this are:
Cost per story point
If you know how much the team costs you, and hence how much you want to bill them out for, you can calculate a billing rate per story point by dividing the team rate by their average velocity. Let’s say I’d like a 25% profit on my $100,000 team. I bill them out at $125,000 per sprint. Their average velocity is 20 points, so a point costs $6250. Now when the team size an item in backlog grooming you can immediately translate it to a cost for the client. e.g. a 5 point feature will cost $31,250.
Cost for capacity of a team
An alternative if a client wants to reserve a fixed amount of capacity (for example for support), you can find out how much they are willing to pay and work out what % of the team’s capacity that buys them. $125,000 buys them the full capacity for 1 sprint, so $250,000 buys the whole month. If a client only has $100,000 per month, they can buy 40% of the team’s capacity.
Then when scheduling work, the Product Owner applies a similar calculation to the FTE model above. i.e. with a velocity of 20 points, 8 points each sprint should be reserved for this client. In sprint planning each sprint the team will agree with the client what work to cover for those 8 points.
Important Notes
Here are a couple of things to note if you do give this a try:
Velocity changes over time – be sure to redo the calculations at least quarterly because velocities change, and use an average velocity over at least 3 sprints. You will also have to redo any cost calculations anytime something on the team changes, like new members, or salary increases.
Scrum Masters should be billed – often people think that Scrum Masters shouldn’t be billed to clients because they don’t work on the product. However any vaguely decent Scrum Master should be improving the productivity of the team by more than 20% which pays for their cost on a team of 5 people.
Scrum might be more expensive at the start – A big surprise for our client is that Scrum seemed a lot more expensive to their clients when calculated this way with the data from their first 3 sprints. We reminded them that the team takes a few sprints to find their feet, so the first few sprints are not necessarily indicative of the future. During the first few sprints they are learning a new process, a new way of working and so velocity should improve quite quickly. Quality is much better almost immediatly, so although the upfront cost is more they total cost of ownership in terms of support and maintenance should be much lower.
Not transferrable – team costs, estimates and velocity are not transferable between teams. So be cautious about applying one standard formula across all teams.
Run in parallel – If you are not quite ready to jump in with 2 feet, try running this approach in parallel with your current billing approach for a month or two. If the figures are similar, ask yourself: which is the least amount of effort?