Leveraging Time Tracking to Reduce Waste and Build Trust Capital

Agile teams are always looking to reduce waste so that they can produce customer value quicker and more efficiently.  For example, the Scrum builds in a meeting called the Sprint Retrospective to give teams an opportunity to reflect on their own efficiencies – allowing them to reinforce practices that are going well, and identify and resolve issues that are causing waste. Scrum teams also have a time-boxed meeting called a Daily Scrum, which among other things, asks “what are your impediments” to help the team quickly identify things that are getting in their way (aka waste) so it can be dealt with.

In order to understand waste, you must first be able to understand value. Ultimately, agile teams want to provide value to their customers.  It’s generally accepted that customers find value in working software that they can use to solve their problems. Therefore, anything that gets in the way of producing working software that customers can actively use should be considered waste. Based on this, here are a few things that could be considered waste:

1. Fixing bugs
2. Support
3. Partially done work
4. Handoffs
5. Waiting for something
6. Switching between tasks

In a perfect world, we wouldn’t have any bugs or time spent on support.  We don’t live in a perfect world.  Try as we may to completely eliminate these from our world, in reality, the best we can do is to learn from these forms of waste, and try to minimize them.

One very important aspect of almost every successful agile team is their ability to measure. Agile teams like to capture all sorts of metrics about the rate they produce value and the rate at which features flow through the development process. This information gives them insight into how much value they can produce, and ultimately set the right expectations with the customer. These metrics can also be used as baseline for process improvement.

So, how can time tracking help? Most agile teams start by capturing metrics such as “how many story points can be produced by the team in a single iteration / sprint” – the team should of course always want to increase this value by becoming more efficient and reducing time spent on work that doesn’t produce value.  Sometimes, however, you might not understand where the waste is in order to eliminate it. One way to understand what type of waste to focus on reducing is to capture how much time people are spending on the production of value versus time spent on work that could be considered wasteful.

For example, let’s assume the team suspects that they are spending much too much time on support forums and bug fixing. One way they can confirm this is by leveraging time tracking to help gather metrics that proves this. A team can simply capture the amount of time per day in a few basic categories – producing value, working on support issues, working on bugs. The team can then use this data to form a baseline by which they can continue to improve against.

After taking a look at their time tracking data the team finds out that in a given week of a team of 4 people, 40 hours were collectively spent on support and 20 hours went into resolving critical bugs found by customers. Clearly, out of 160 potential working hours (assuming there is a 40 hour work week for the team), ¼ of the time is spent on support.   Armed with data, the team can really focus their retrospective meeting on identifying what is causing the support requests.  During this analysis, they find that the installation routine is not robust enough and is causing many problems for customers resulting in calls to the support line. The team quickly realizes that if they resolve the issues with the installer, support could go down considerably – so they decide to fix this problem and measure the results. They find that after they enhance the installer they were able to cut their support costs down to 20 hours per week. This also resulted in the team being able to add 12 additional story points to the week due to the waste they were able to remove.

Time tracking can also help detect when teams and customer expectations may not be met. Setting expectations, even at the level of a Sprint (which can be anywhere from 1 to 4 weeks long) is more important than most teams realize.  When you set out on a sprint (at least if you are using Scrum as your process), you produce something called a Sprint Backlog. Don’t take this list for granted…as your customer may see this list slightly differently than your team – they “perceive it” as a promise to delivery something within a small period of time while your team may consider this a list a target. Some teams don’t release the contents of the sprint backlog to customers for this very reason – however, customers generally like to know what they are getting next ;-) When you make such a “commitment” (and yes, we all know it’s not a true commitment – but more of a forecast with hopes of a small amount of variability) the customer’s expectations become set. If you under-deliver, an awful thing happens.  You erode a small amount of trust that the customer has with your team.  You start eating away at your Trust Capital.  I’m not sure I can explain all of the psychology involved, but even with GREAT customers, even a small difference between what they expect to get and what they get makes an impact on Trust Capital. Trust is something you want to build, not erode (like all forms of capital) – so, you want to govern how you plan your iterations around success rather than hope.

Time tracking can give you an early indication that expectations may not be met.  If you’re finding that entered time drastically exceeds estimated time for work, this could be a flag that expectations, and thus trust, may be threatened.  Looking at this form of variance allows the team to have a discussion – giving them an opportunity to try to resolve the underlying issue, make compensating adjustments to approach, or to immediately and transparently reset expectations. By the way, being completely transparent on a project and pre-emptively resetting expectations also builds trust due mostly to the fact that customers don’t like to be surprised. Transparency, even when things are going bad – as long as it happens early – works to build trust.

So, in essence, time tracking can go beyond traditional uses and can be a handy tool for teams not only learn from, but to help manage the delivery process.

On that note, I’m proud to announce that TeamPulse now has ime tracking.  Time tracking in TeamPulse can be used for traditional purposes, such as to product billing and invoicing reports, as well as act as another tool your team can use to measure productivity, help identify waste, and to manage the delivery process.

This is our initial release of Time Tracking and we can’t wait to get your feedback.

Explore TeamPulse Time Tracking

Joel Semeniuk

Microsoft Regional Director, MVP Microsoft ALM, and
Executive VP of Agile Project Management at Telerik

@JoelSemeniuk