Want To Get Better at Estimating Time at Work? Track Your Pace

Developers hate estimating time.

All of ‘em.

And it’s not really surprising. When you think about the task of estimating time and effort, there are just a lot of unknown variables that can get in there and screw everything up. 

Worst of all, when developers try to structure their estimates in a way that actually make sense for the unpredictable nature of development work, other stakeholders in the company have no freaking clue what’s going on. 

Tools like Effort and Storypoints may be helpful for you, as an engineer, but the salesperson who’s partnered on the project doesn’t know a storypoint from a salami. She just wants to know when the damn thing will be done.

And you probably end up just throwing out a number so you can get back to work.

It’s something we all do every day, because every project needs a deadline. But it’s something we do poorly, because deadlines get missed all the time.

What if there were a simple calculation you could use to help your team better estimate how long it will take them to complete projects, features, and work items?

That’s pace.

Pace is like a reality check that you really need, but you’re probably too scared to calculate. 

Calculating pace for yourself or your team team can help you evaluate your time estimations, meaning you’ll be better able to manage projects and deliver on deadlines. And knowing your team’s average pace means you can flag pace discrepancies, which are often signs that work needs to be adjusted in some way.

This isn’t to say that pace is a magical metric that is the key to never blowing a deadline again. If that metric existed, engineers, project managers, and DevOps teams would be falling over themselves to learn and use it. But pace is one more tool a developer can have in their arsenal to help them get a better understanding of their work, the time it takes, the time they should estimate for future work, and how they can adjust projects or their working style to make better estimations moving forward.

How to Calculate Pace

Let’s keep this as simple as possible. Pace is calculated with this equation:

If you use 7pace Timetracker, you can skip doing the math yourself, because you can see your pace in the iterations tab, where it’s calculated by work item.

If you aren’t able to use 7pace Timetracker, you can calculate your pace manually. Since pace is meant to be a tool that can help you evaluate your time estimates, a good place to start is by looking at past projects or work items and calculate yours or your team’s pace working on those – having a GitHub project management system in place makes this process even easier. Calculate your pace on a number of past projects over time and look for an average over multiple iterations.

What Factors Can Impact Pace?

Pace isn’t a single number that always stays the same no matter what you’re working on. Sure, you can average your pace. But it’s still likely to fluctuate from iteration to iteration — you’re not likely to complete a project at your exact average pace. Don’t panic — this is totally normal. To know what factors can affect your pace, you have to look at the two parts of the equation you use to calculate it.

Changes to Your Tracked Time

The first part of the calculation is your tracked time, which means anything that impacts your tracked time can also impact your pace. That goes for both changes to the hours spent working, and changes to the team or how many people are working.

For example, when a new person joins the team, they add hours to your tracked time, but you can’t expect them to be contributing meaningful deliverables right away, so this can actually cause your pace number to go up. People leaving can also affect your pace, because the number of tracked hours will decrease, and so might the number of story points or amount of effort you accomplish.

Unexpected delays can add hours to your tracked time without accomplishing story points. This goes for extra-long company meetings, people calling in sick, and when team members go on vacations.

Incorrect Estimation of Story Points

Over or underestimating story points or effort is a bad habit, but one that many developers and teams are guilty of having. If you overestimate the effort a task will need, your pace number will be lower. If you underestimate, your pace number will be higher.

That’s why tracking your average pace can help you get better at making those estimations. This is what your average pace tells you about whether your estimates are accurate.

If your pace number falls roughly in the middle of that scale, you’re making pretty good estimations of the effort tasks and projects will take. If your pace number is far to the left or right on that scale, you might need to tweak your estimations.

What’s a “Good” Pace?

That might make you think that if your team has a pace smack in the middle of the scale, it’s a “good” pace. But pace isn’t a metric that anyone should be holding over a developer’s head. It’s a very team-based metric, in that if everyone on the team is happy with the pace, it’s a good pace for your team.

Different teams will work at different paces; there’s no way around that. If one team finishes work at an average pace of 5.2, while another team finishes at an average pace of 8, does that mean one team is better than the other? Not at all. It just means they’re different teams.

A good way to look at pace is to compare it to the RPM in a car. If there are two cars, one in fourth gear, and one in third, they’ll have different RPM readings. But they’ll still get to the same destination in the same way, and that’s why different teams having different paces shouldn’t be seen as a positive or negative thing. There’s no one-size-fits-all pace that’s “correct” or “good” for everyone.

How Tracking Pace Can Help Your Team

We promised that this would help you better estimate the time it would take to complete projects, and here’s how: Once you know your average pace, you can plug it into the pace equation and solve for time instead. Here’s an example.

Your team’s average pace is 5. You want to know how much time you need to complete a work item that’s 4 story points. So plug those numbers into the pace equation.

5 = X hours of tracked time / 4

That means a good guess would be 20 hours of tracked time.

And while anything that helps developers make more accurate time estimations is great, that’s not the only way Pace can help you or your team.

Before we get into this, here’s something that actually happened with the 7pace team. One of our developers was going ham on a work item that was estimated to be three story points. But around the 80th hour of tracked time, we realized something was wrong.

Here’s the math, in case you haven’t done it already.

Pace = 80 hours of tracked time / 3 story points.

Pace = 26.67, in this case. Our team’s average pace is 5. Knowing that it’s OK for pace to fluctuate a little sometimes is fine. But a pace more than 21 points higher than our average? That’s an indication that we need to take a closer look at this project. 

This is a great example of how you can use pace to help your team. If your pace on a specific project is way off, there are a few things you can look at.

If your pace is low, you should:

• Check your estimates. If your pace is consistently low, you might be overestimating effort.

If your pace is high, you should:

• See if the work item needs to be split into multiple work items.
• Check if the acceptance criteria could be changed. If it’s a small acceptance criteria that isn’t super important but causes a ton of work, you need to reevaluate that acceptance criteria.
• Label the project a black hole and move it to your backlog so you can continue on.

In the case of that 7pace developer, we needed to realize that this wasn’t a work item, but rather a whole new feature. If we hadn’t been tracking pace, it wouldn’t have been so easy to see that there was an issue there.

A few other tips for how to use pace:

• Don’t be critical of the person or team. Instead, be critical of the work item or feature they’re working on. Pace should never be used as a measure of a developer’s value.
• Be careful of overestimating effort in order to keep pace down. If you notice an average pace that’s consistently high, look at other reasons it might be high. Or, if the team is OK with high pace, then there’s nothing wrong with high pace.
• Encourage members of your team to figure out their own average pace, but don’t use it for management of your people or team. Pace is a useful informational metric, and nothing more.

For an easy way to keep track of your average pace, try 7pace Timetracker, which integrates directly into Azure DevOps and Azure Boards to help you track your time, all while delivering data and insights that can help you become a better engineer. Track your pace and other useful metrics that can help you constantly help you improve your skills, productivity, time management, and more.