Brick by Brick to a Better Time Tracking
Keeping time sheets up to date is one of the least favorite activities of software developers. The reasons for this are manifold but the bad user experience of most time tracking tools is definitely a part of the story.
In his blog post “Why Time Sheets are Lame! “, Jeff Sutherland lists several reasons why time sheets in general make no sense. For legal and accounting reasons, many companies need to keep track of the time spent by their employees. In most cases, the timekeeping is done on an individual basis.
In an agile environment, the problem is not the tracking itself but that it is done on an individual level. We are using Scrum which puts the team into the focus and not the individual team member. At the beginning of the sprint, the development team commits itself (or, as described in the newer scrum guide, “forecasts”) to the sprint goal. Consequently, at the end of a sprint, the success of the team is being measured and not success of individuals.
A company should only be interested in the amount of time spent on a certain type of work (e.g., maintenance, development of new features, infrastructure management, …), as it translates directly into the overall amount of cash invested in the topic.
That is why we decided to try time tracking on the team level only. It is up to the teams to choose the right tool for the job (e.g., simple tally sheets, a software solution, just an Excel sheet …). The only requirement is that the sum of the efforts spent on the types of work has to be sent to our controlling department at the end of a sprint. In order to have more fun and because of its practicality, some of our teams decided to use Lego bricks for time tracking. As a result, our time “tracking sheet” looks like this:
Each developer receives the same number of Lego bricks, according to the length of the sprint. The team of which the photo of the “tracking sheet” above has been taken applies a granularity of one brick per half day.
A big base plate is glued to the wall near the exit of the team room. Attached to the plate are Post-its designating the different types of tasks, e.g., work on feature A, work on feature B, maintenance, infrastructure, consulting/support. We use flat tiles to attach the Post-its safely. At the end of a day (or before lunch), each developer places their two bricks for the day on the plate. At sprint end, the product owner counts the bricks by category and reports the hours electronically.
We have been doing this kind of time tracking for a number of sprints now. So far, the results show the approach to be useful and pragmatic to keep track how much time is spent on which type of task. The advantages are:
- The acceptance rate among the developers is much higher than before.
- Time tracking actually happens during the sprint, not months later after individual reminders.
- The developers have the feeling that this lightweight solution helps them to spend less time on time tracking than before (when they had to use an actually unusable software solution).
- By using Lego bricks the whole process has a playful note which helps to motivate all persons involved.
- Collecting the bricks visibly in the team room is part of an informative workplace and gives instant feedback how the team spends (or wastes) time during each sprint.
- The data can also be valuable input for the retrospective.
We are interested in your opinion to this approach of time tracking. Will you try it as well? Do you know others that have a similar approach? Please leave a comment!