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.

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.

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.