We all (generally) love story points.

Having these amorphous blobs of effort provide a huge level of flexibility and agility. They’re really the backbone of SCRUM and other agile methodologies.

The central thesis is that work shouldn’t be defined in hours and minutes, but be estimated on the basis of its complexity. That sounds great. And it works well–most of the time.

But when you’re inside an iteration, story points become impossible units of measurement.

Because of the very nature of the story point system, you cannot deconstruct tasks into smaller increments. And you can’t decrease the number of story points remaining as you complete parts of the specific user story.

This makes it difficult–or even impossible–to answer basic questions about the health or your iteration.

Any team practicing SCRUM has undoubtedly had this problem. Each day, the story point count remains the same. Until the final few days, when it begins to decrease. This leaves a void in the middle where you’re stuck with no information. You still have 20 points of work remaining, but will it take 10 days to complete or just 2?

It’s like if you wanted to know the time, but the only unit of measure that you could use was the year. I guess it’s useful to know what year we’re in, but it doesn’t help me make it to my appointment on time.

While story points are great for scoping and planning work at the iteration level, they are pretty lousy at telling you how things are going at any given point once the work is underway.

There’s no mechanism for agile teams to break down the amount of work that has gone toward the completion of a particular user story.

So, instead, most teams just guess at how well things are going inside an iteration.

They have 5 story points remaining, so they estimate that it might take them an additional 30 hours to complete the work necessary to complete that specific story. But, how does your team know this is true without some measurement of time?

That estimate is not backed by any data or analysis of how much time has been spent on the completed tasks.

It could be the case that the first half of a 5-point story has actually taken 35 hours of work. So, it would follow that the amount of work remaining will actually take another 35 hours–that’s a 10 hour difference from the original estimate.

This is the role we see for timetracking in the development process.

Insert the task-hour

Because of the void left by using only story points to measure progress and work completed, many teams have adopted a task-hour measurement to be used as a way to better understand the time that is spent on individual tasks.

This additional measurement allows teams to add precision to their estimates and base their progress on real data, rather than rough estimates.

At the risk of sounding like a broken record, it shouldn’t be a measure of overall progress or efficiency from management’s perspective. (That’s what story points and velocity are meant for). But, rather, it’s a way for the team to understand and assess their health and progress from inside an active iteration.

It’s a way to answer specific, tactical questions that affect your ability to complete a sprint:

• Are we on track to finish this thing?
• How far away is that thing from being done?
• Who needs help completing their work for this iteration?

Each of these answers is valuable. And they are virtually impossible to answer with any precision if your only unit of measurement is a mile wide.

Measure, but don’t mix

One of the biggest contentions with time tracking for agile teams is that having time measurements seems to open up the possibility for those time measurements to be superimposed onto some other unit of work. E.g., many engineers fear that if they track time in hours and minutes, this will invariably lead to story points being converted into units of time.

The point of measuring both time and effort is not to mix the two variables. Yes, it would be rather trivial to take these two measurements and say that, according to this data, one story point is equivalent to X hours of work.

That would defeat the entire purpose.

Fight any urge or pressure to mix these different ways of understanding progress.

Yes, they are correlated. But that doesn’t make it wise to equate them with one another.

Time measurements and product measurements (e.g., story points) should exist in parallel and serve the needs of different stakeholders. Product owners need a high-level view of the work that is in progress, will be completed, and/or has been done. But the team needs something more granular and precise to measure their progress while that happens.

If you breach the barrier and allow time measurements to become a managerial tool, you risk alienating the team and destroying the trust and autonomy that are so central to the entire agile philosophy.

But, if it’s done right, time tracking can become a valuable tool for teams who want to have a better understanding–and better control–over their own work.

Any time teams can stop guessing and start measuring, it’s usually a good thing.

7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.