A few months ago someone from our team asked a few product owners how they figure out delivery dates in for their teams. We got a lot of 'I guess' and 'I try not to', but we also got this strangely correct and poetic answer.
"I take the time and double it, then take the unit and bump it up. Something that I think should take 2 hours, will actually take 4 days... and of course I keep enough money in the budget to take the boss out for beers so I can tell him that we're running behind."
I mean... I guess that's one way to do it? 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.
Calculating Pace
Why Does Pace Matter?
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...
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.
What to do if your pace is high/low
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.
TDLR;
- pace = time tracked/effort or story points
- it helps you estimate delivery time better than guessing
- if your pace is lower than usual, you're overestimating effort
- if your pace is higher than usual, check to see if the item needs to be split into smaller tasks, take a look at the acceptance criteria, or label the item or project a black hole
This is a no-nonsense short and sweet version of this article.
Top comments (0)