Table of Contents
How Do I Convert Points and Velocity to Dollars?
Or “How do I figure out how much I've spent on something?”
Or “Do we still need to track time in a time tracking system for progress reporting?”
One base idea with agile to focus on completion of work rather than the effort it takes to get the work done. So, for example, we track the remaining work on a story rather than the counting the number of hours we spent on a story. This makes sense because while the effort might be interesting, we are really interested in the value delivered. Even if we now have the effort, it is history, so there is nothing we can do to change what happened.
Despite this you will sometimes hear calls to track how much time was spent on something. This is couched in terms of “Upper management wants us to use this information so they can see/say how much a certain epic or feature ‘cost’”. This is a valid business request. We should know how much we have spent or been spending on an epic or feature. The problem is that the first reaction often is call for tracking how many hours we spent on a user story and so we can understand how much time we spent on an epic. There are a number of problems with this approach (see below) but an alternative approach to getting what we need is to use the proportion of points a team spends on the epic.
Using Points to Calculate Cost
The process for calculating the cost is to determine the proportion of the total velocity the team applies to an epic or feature and then multiple that by the cost of the team. So:
For each epic_or_feature For each team working on the epic_or_feature Sum For each sprint calculate (points completed on epic_or_feature / velocity of team) * burdened cost of team in dollars
In other words we determine the cost by proportioning the work associated with the thing we are interested in (here epic_or_feature) over the burdened cost of the team.
The burdened cost of a Team allows us to factor in things like different labor rates in the different countries if that is important to the organization.
Benefits of Using This Approach
There are a number of benefits if we use this approach:
- Works right now if you have access to burdened cost of team (average US team is $100K per month – more accurate information is available from accounts)
- Includes all the costs of the team including Scrum Masters, Product Owners, and the level of overhead such as individuals doing other things (eg email) etc
- Allows us to use point estimates that are faster to produce and without the same kind of biases that that result when you use hour based estimates
- If you need to make it more accurate, use “actual points” for work that has been done (note: most teams find the proportions are pretty close between doing actuals versus original estimate and so don't see the value in this idea)
- Allows team to focus on completion, not effort.
- Does not require additional reporting (“oh the UI is so simple everyone can do it” is just another road bump for people who should be focusing on producing value)
In reality, if the work is large enough you’ll find an close enough approximation by simply counting the number of user stories in an epic as you do the work and proportioning the cost of the team that way (law of large numbers takes over - see Do We Need Points To Generate a Release Burn-up Chart? for more on this thinking). In the same way I expect you’ll eventually find that if you do to proportioning of cost via hours, you end up with pretty close to the same result as points. Many argue that ratios of points produce a better result than hours since it is more complete and both the people doing the work and the managers of that work talk about the same thing.
You can also come up with a “cost / point” calculation based on team velocity and cost (eg For a quarter, divide the total cost of the team by the total points completed by the team, (including Product Owner, Scrum Master, team members and the appropriate percentage of part-time contributor salaries). You now have the “cost per point”). Some will find this useful for looking ahead when estimates are required for projects, for example.
The benefit of this approach is that you can:
- The velocity numbers are self-leveling so represent real capacity of the team to deliver value
- Leverage the fact that our estimates are pretty good at the story level
- Easily come up with ranges that represent future probability. For example you could say “if I do this work at my minimum velocity which represents a 90% probability that I will get it done, then the cost / date will be X while if I do this work at my average velocity which represents a 50% probability that I will get it done, then the cost / date will be Y”. Plans can then be evaluated based on these probabilities.
Why Not Just Track Hours Like We Traditionally Do?
So what are the problems associated with using tracking hours? Some of the problems are:
- With agile we only plan to 5 or 6 hours a day (or some other amount depending on what people end up doing). We could ask teams to record “everything” but that is an overhead (tasks for everything like doing email). This is the purview of a “time tracking” system. We could just multiple all numbers by 8/5 to get to something more real, but is this any better than using points which we already have?
- Today I get people asking questions like “well I worked 7 hours on this thing, but we only planned for 5, what do I put in?” My answer has been “you put in how much work you have remaining …”. I expect this is because people still think they want to track time they spent on something, for whatever reason. If we start tracking time we are going to have to reconcile all the “ideal time” discussions with the “real time” happenings and come up with recommendations for these.
- Traditional time reporting is based on guesses. This is because generally people will try to minimize the amount of times they go into the time tracking system. So, for example, at the end of the week, people will go into the system and fill in the time card for the whole week. At best these are good guesses. At worse they are not related to reality at all.
- Traditional time reporting is based on budgets. Why is this bad? If a person on the team knows, for example, that the budget is gone for an area she is being asked to work or an area where she knows there is scrutiny and focus, there is a tendency to put the effort into another bucket to avoid the conversation. This means the data is inaccurate at best.
- One reason we work in points and velocity is that it is faster to produce estimates (bigger or smaller than something we know about) and provides better data (more accurate based on self-leveling of velocity information) than hour based estimates. This allows for faster decision making, using more accurate data, with a better view of the trade-offs. (Note: Some argue that “people convert points to hours anyway - this is an anti-pattern - for more information on this see Why Do We Use Story Points Instead of Hours or Days?)
- “Estimated effort” is highly correlated with actual work time. Since the team produces estimates to help them make good commitments, and since there is constant feedback on how well they were able to meet commitments (at the end of Sprints) agile practices help teams drive toward high correlation between estimation points and actual time.
- To me easier approach for cost is to determine burdened rate of team and use sum of completed versus sum of total for each epic to come up with a cost each team who has worked an epic. After all, we really only care about commitment and completion.
But my biggest issue is the impact of putting this type of system in place from a cultural perspective. People say to me “you know, when we first started agile / Scrum it was great because we could focus on getting the work done. Now we have slowly reintroduced all the bureaucracy we used to have back into the system so our ability to work has decreased.” My view is that this is a natural tendency of organizations – to introduce more and more cruft rather than trying to keep things simple. I think we need to be very careful about putting systems and bureaucracy in place.
Worse than this, time recording takes people out of the mode of producing value and, in the worst cases, forces people to focus on creative ways to make time reports look real (or more accurately, good). It is sometimes too easy to focus on the question of how much something costs to produce, when the question we really should be driving is “how do we increase the production of value?”
See Can We Trust Story Points as a Measure of Effort? for additional thinking here.