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?