Cost management without time tracking in Scrum

Question

In my company I'm responsible for several software development teams. Lately our managers asked me to establish a time tracking system for our developers to have better overview over the actual costs of specific projects.

I get the intention and of course I see that there not only needs to be a mechanism to calculate prices for our customers, but also to understand and interpret the performance of our company and its optimization potentials.

Since there a lots of companies out there selling tools for time tracking and pretty much everybody is used to do time tracking, I only find information on how to do time tracking, but nearly nothing about how to handle the situation based on other metrics than time.

The reason I'm searching for this alternative is, that I feel our recently pretty successful Scrum process is in danger. In contrast to other teams in my company, we deliver on time, have less software defects and significantly increased our velocity multiple times.

We did not need time tracking to achieve this and to me it seems that things, which would be judged as "waste of time", were not possible anymore. Just to mention some examples, for me it is ok to have the developers to take breaks whenever they feel it is a good idea. Sometimes my impression is, that some types of breaks are even increasing productivity. If this means somebody is working less hours than paid by contract, I'm ok with this as long as the total team results are over average. The current environment encourages team mates to help each others or even other developers which are not part of the team, making the team and the whole organization generally better (= higher return of investment).

Time tracking would reduce this kind of time and IMHO it could kill an environment that is actually based on motivation, trust and the developers inherent will to succeed. I think, a lot of creativity and the strive for innovation could be inhibited. The need to increase not only the own velocity but also the need to increase others productivity could get lost. Not to mention the unnecessary overhead of time tracking.

You will agree that developers are not able to think 8 hours a day without burning out at a certain point. Especially if there is a constant pressure of deadlines or exhausting pair programming sessions, to me it would be a bad long term decision to "make sure", that developers "worked" all their hours.

I even think, that time tracking is misleading. It will not provide actual costs, but estimates or approximations. There are lots of reasons for me to find an alternative. Since the time tracking approach is mostly driven by our "non-technical" management, to a certain degree, it seems to be a request to have at least something™ which enables them to handle the situation, because they simply do not know about software development processes and the impact of command and control structures on Scrum. They would be happy if I could simply provide a mechanism which fits their needs and provides all the necessary information.

My intuitive idea was to ask the developers to check and possibly correct their story point estimates when closing an issue. Then I could use the teams sprint velocity, the teams total amount of costs per sprint and calculate project costs proportionally. (I know, this does not provide the actual cost but neither is time tracking.)

And that is my question. Is this the common way to calculate costs? Do you have better ideas? How do you do it?

Answer 1

If you need to track costs, track it at the Scrum Team level rather than at the individual level.

A simple way to do this is to take a blended cost per person and multiply it by the number of people in the team and the duration of sprints.

For example:

Average cost of staff is £600 per day and Scrum Team 1 has 7 people in it and do a two week sprint. 600 x 7 x 10 = £42,000 per sprint

Working with Scrum you can now justify this cost with the value released in each sprint. All you need to do is answer the following question:

Is the team delivering value equal to or greater than the cost per sprint?

How you determine value is up to you. An example might incorporate:

• Revenue generated by the sale of the team's work
• Cost savings
• Regulatory compliance
• Following strategic objectives

Now there is no need to waste time tracking story points or time estimates. Simply focus on value delivered and sprint cost.

How the team goes about delivery is up to them (taking breaks, collaborating, knowledge sharing, etc.). It is the end result that is measured, not the details of how they do their jobs.

Answer 2

While I agree with Barnaby that tracking time (or, really, tracking almost anything) at the Team level is better than at the individual level, I agree with you that tracking Time at all is not ideal.

The best course of action is to convince upper management that this is a bad idea. The most effective way to do that, as you've already realized, is to have an alternative.

One thing I suggest you do is to ask the Teams themselves for ideas. If the number of Team members is small enough, this could be done all at once. If not, go one Team at a time, aggregate all the results, then send out in an email afterwards (as one Team may think of something new after hearing the idea of another Team).

Not only would this potentially bring about good ideas (and from people far more knowledgeable about your situation than Strangers on the Internet™ could be), it will also increase Team buy-in. Even in the worst case of not being able to come up with something, the Team will at least be glad to have been consulted, which could mitigate one of the worst drawbacks of time-tracking - lowered morale.

One possible approach (though this strongly depends on your organizational environment, so Your Mileage may Vary), is to point out to upper management how much better your Teams have been doing than other teams (make sure you have metrics!). You can then suggest that, rather than introduce time-tracking, which you and your Teams anticipate will, by itself, lower their productivity, the business could instead focus on converting those other teams to work more similarly to your Teams.