“Where should our developers book their hours on when we move to Scrum?” I was asked recently at a client. I am helping them roll out their new development methodology which leverages a big deal of Scrum among 17 teams. One of the questions in the larger organization was, how to do time-tracking. I knew I needed to dive deeper into that.

“Why do you need time-tracking?” “Well, you see we have customer projects alongside with the development of our product platform. Customer projects run in two phases: before feature complete, and going for the real deadline one year later. During the latter phase customers file a lot of bugs when they start testing the functionalities we delivered earlier. Sometimes we want to fix a bug for all customers, then this becomes product development effort. Otherwise we charge the project.

“We have customers that are troublesome. In the end, we want to decide which customers don’t pay off well. That’s why we want to keep track of how much development work flows into each of the customer projects.”

A long story short, the 17 teams might find work from either customer project or the platform product in the backlog. A sprint might then be filled with either a mix of items from all of these sources, or it might be just product, or just bug-fixing. Depending on the demand from the customers. Oh, they decided to start with component teams, I think I should say that as well.

I don’t think we came up with a solution that no one else in the world thought of, yet, I found it clever. We came up with the decision that the Product Owners of each of the 17 teams can deliver percentage numbers – how much work did my team for customer X, customer Y, and how much for the product – after the Sprint, or at least on a monthly basis (as this appeared to be the reporting cadence). Let’s look at the benefits of this approach.

Improved accounting

The development team costs the same amount of cash each sprint. In order to do the math for accounting, it’s sufficient to track the development on this granularity level and after the fact. In fact, it turned out to be more precise than anything in place.

Before our discussion developers also fixed bugs. Usually when it came to tracking their time the developers were struggling with where to book the particular 10 minute bugfix. Did the product manager approve to include that in his budget? Is this a bugfix just for customer X, even though customer Y needs this as well? In the end, developers ended up tracking their bugfixing efforts for the budget that was easily available to them – and that usually did not have to do anything with booking hours to the right cost center.

That said, with the old approach they were hardly able to answer their initial question: Which customer projects pay off, and which should we abandon in the future? The numbers were ambiguous because the structure behind it did not support the people who needed to use the system. With the new approach, the numbers were still vague, but a bit more reliable when it comes to answering the initial question – and therefore more helpful.

Empowering of Product Owners

The Product Owners become more empowered since they now have real accountability in regards to how they juggle the different efforts with their ordering in their product backlogs. Since they should report the percentage split among the different cost centers, they now have to deal with the accounting side of the efforts. They are now really in charge to care for the money that their development team costs, and might even have to negotiate those numbers with the project managers for the different customer projects.

The development team costs the same amount of cash each sprint. After the Sprint it reviewed, the Product Owners have a clear picture about which bugs are fixed, which backlog items have been completed (and which maybe didn’t), and how much effort was put into each of the different cost centers. By negotiating the numbers on the larger portfolio level, they now even need to really think about where to get money from. I expect these conversations to change over time into “we need to charge customer X for this thing more than we thought” or something like that.

Easier time tracking for developers

The initial thought before involving me was to create cost centers for all customer projects, and each component team. Together with separating between development efforts, bug fixing efforts, and meeting efforts this would have become a nightmare for every developer involved in the teams.

Now, the proposal included that each component team simply gets one dedicated cost center. Developers book all their hours one effort: “My Scrum Team”. We even dropped the separation between “development”, “bug fixing”, and “meetings”. That means that the overhead of the Scrum meetings, or any larger organizational meetings is now spread across the different customer projects in fair amounts. Thereby the particular pick of development methodology also flows into the contracts for future customer projects.

Simplicity

I think we did not re-invent time-tracking. In fact I am quite sure that someone already did something like that. I like the approach as it answers a reasonable question from the business perspective while it favors simplicity. The development manager talked right away with accounting and the HR department whether the approach would be feasible, and they want to give a try.