GET STARTED
Published:Jul 04, 2017

Time Tracking for Agile Software Teams

It’s no secret that tracking time is not something most software developers enjoy.

Keeping time has a reputation for being restricting, wasteful–even machiavellian. Much of that feeling goes back to old-school time tracking systems that were arduous and burdensome or restrictive timekeeping policies that required developers to spend hours of time keeping track of every second spent on each work item.

On the flipside, many software teams have openly and eagerly embraced agile development methodologies as a way to break through the stalemates of software development, get more work done, and make management simpler and more manageable.

To many developers, these two things may seem at odds–but they shouldn’t.

[upgrade]

Time tracking without the time-suck.

7pace is built for development teams who don’t have time to waste counting every second they spend working.

Fully integrated timetracking for TFS and VSTS that’s out of the way and works like magic (almost).

Learn more about 7pace

[/upgrade]

If we consider the reasons we use agile methodologies, it becomes clear how measuring and managing time aligns with our goals of creating better software in a more predictable, incremental way.

Why we love agile

The reason we embrace agile development methods is because it gives us freedom and autonomy over the work that we do. As developers, we are in control, but that also means accepting the ultimate responsibility for our own time and effort spent creating software. In this environment, we must face the realities of our progress every day or every week, which makes us more accountable to ourselves and our team.

In a waterfall system, it may be easy to cover up projects that take longer than expected or features that delay the project for a few extra days or weeks. Over time, they compound, but it’s difficult to point back to one particular feature or issue that set back the entire schedule.

But in an agile environment, we’re acutely aware of what is holding us up, how long it’s taking, and what it means for the health of the current iteration.

This is scary, but also liberating.

The more we know about the health of our progress, the more we’re able to control the outcome. This is one of the main reasons that teams are turning to agile methodologies. It gives teams more power to understand their work and therefore improve.

At the heart of agile is a cycle of continuous evaluation and improvement–a drive to do better.

But in order to get better, we need to understand all of the variables at work and then understand how we can control them to our benefit. That’s why time tracking is such a valuable exercise for agile teams–it gives us insight into how and where time is being spent at a more granular level, which allows us to better account and control for those minutes and hours.

Agile in practice

At the center of any effective agile process is planning.

Sprints and iterations are the currencies of agile teams. But if we break them down, there are really two components that go into planning:

  1. Time
  2. Work

That’s it. This is the beauty of agile–it’s simple.

But railing against timekeeping robs you of one of the essential components that’s used to actually make your life easier and better.

Sure, you can estimate that it will take you 3 story points to implement a new feature. But how do you track and measure what those story points represent? How do you know if your pace is improving? How do you plan future sprints with more accuracy?

The only way you can gain this kind of insight–and the only way you can systematically improve your sprint-planning process–is by keeping accurate time records and then using them to make decisions in the future. Keeping time records may seem obsolete as management and executives have learned and accepted (sometimes after much teeth gnashing) that agile planning succeeds better without time control. But does that mean that development teams don’t need to further improve their processes and methodologies?

While we may use some kind of time abstraction like story points for reporting purposes, the fact of the matter is this: time matters. There are only so many hours in the day and only so many days in each iteration. This means that all of the planning, work, and testing that we do must ultimately fit into a finite number of minutes available each day.

Changing the story

There’s a discrepancy at the center of this debate that’s important to point out.

Many software developers and teams have the view that tracking time is a “stick” for management–a way to critique and chastise work done versus time spent.

But that’s not the case in an agile methodology. On agile teams, developers themselves are ultimately the ones who are responsible for managing time and work.

As such, timekeeping in agile is for the benefit of developers–not managers. (Although it may give some insight for managers to better understand the work that’s being done, it’s not a mechanism to control that work.)

As developers, time recording allows us to introduce some level of objective measurement, learning, and growth to the work that we do. This really gets to the heart of the agile philosophy–iterative process, efficient systems, and continuous improvement.

Teams often struggle to dial in their velocity because they have no actual data to inform their estimates. They’re left either overworked to meet looming commitments, discouraged by impossible, failed iterations, or bored and unchallenged by the work at hand.

This is how time tracking helps.

Having time tracking in an agile system allows those story points to be translated into real units of time, meaning that you’re better able to control and estimate the amount of time you’ll be spending on each task.

As a developer, you gain more control over the work that you do. You’re able to track your progress and understand your own abilities. This allows you to quickly and accurately understand the definition of the story points within an iteration and gain insight into which features and user stories may be quick wins and which ones may cause deadlock.

In turn, your entire team becomes more effective and efficient.

As a whole, you’re able to provide more accurate estimates and scope iterations with more precision and insight. And if your story points can be translated into hours, you have a better understanding for how to adjust your iterations based on changes in the schedule like vacation, holidays, and onboarding/training time.

This is why tracking time shouldn’t be seen as an enemy, but as a weapon for software teams.

Time tracking shouldn’t take long

Admittedly, many teams also shy from tracking time because logging minutes and hours can be a time-suck all its own.

It doesn’t need to be.

[upgrade]

Keep time. Don’t waste it.

7pace is built for development teams who don’t have time to waste counting every second they spend working.

Fully integrated timetracking for TFS and VSTS that’s out of the way and works like magic (almost).

Learn more about 7pace

[/upgrade]

Tasks are already being moved from one state to the next and put in progress as they happen. So, it would make sense that time should be tracked accordingly.

That’s exactly what a good time-tracking software does. It records time as a function of the existing development process without creating additional work of logging time itself.

This isn’t the time tracking of the past where developers frantically make up time sheets to “get it done.” In an agile framework, it becomes a real, tangible tool for everyone involved. The data that’s collected informs everyone on progress and provides insight into how the team is improving over time. This is valuable information that helps teams better manage their workload, achieve a sustainable pace, and avoid burnout.

But those benefits must come without heavy cognitive overhead. If timekeeping is difficult, it becomes a barrier rather than a benefit.

Teams that are able to track their time without additional effort will get the benefits of time recording without the hassle. At that point, it’s really a no-brainer.

Free eBook

Rethinking Timekeeping for Developers:

Turning a Timesuck Into Time Well Spent

3 comments

JT

08-21-2017 09:29

Story points are a measure of size, not time. Velocity includes time, but varies with resources and the work characteristics. So you get a time based measure - velocity - through story points per sprint. Equating story points with a time value is actively harmful, as it encourages estimation by time rather than size. It also leads to fallacious comparisons of velocity.

Tyler Hakes

08-23-2017 14:38

Hey JT, Thanks for your response. I totally agree that we shouldn't conflate the idea of story points with the idea of time/hours. From our view, time measurements are a better and more accurate way to measure the pace of work. It's good for analyzing and understanding the work that has been done and the overall capabilities of the team. But, it's certainly not good for estimating future stories, tasks, etc. We look at it as a parallel measurement. But, teams should definitely avoid any temptation to "convert" those story points into hours, even if it seems like a reasonable thing to do with the data.

How Software Developers Can Use Science to Manage Their Time – 7pace Blog

06-26-2018 14:09

[…] Time tracking is different. […]

Send