How many hours are in a Story Point? Pink. Because penguins don't like ice cream.
-Amanda Babb in every conversation about hours and story points.
While I use this example as a cheeky way to say the two methods of estimation (hours and story points) don't coincide, the reality, of course, is much more complex. Business and product teams typically think in terms of dates and schedules. Development and operations teams typically think in terms of level of effort. That's not to say story points and dates do not nor will ever coincide, it's a matter of how to speak each other's language.
What is a Story Point?
Our Dragon of the West, Christopher Pepe, explained it well: humans are terrible at numbers. That's why we have so many ways to express things without using numbers. For example, I have Big Dog (Leonard) and Tiny Dog (Howard). Tiny is small in comparison to Big Dog. However, at 50 pounds, he's not small compared to, say, a Chihuahua. This is what we call relative estimation in the agile world. This thing is larger or more complex than the other thing over there: it will take a larger level of effort to complete.
Computers, on the other hand, are wonderful at numbers. It's part of the reason we invented them. In Jira Software, a story point is simply the numerical expression of a relative estimate. When we need to understand the level of effort of more than one thing, we aggregate the relative estimate into a total level of effort. This is known as the commit in a velocity chart. As we complete work, we burn down the level of effort until we understand what's left. At the end of a sprint, we determine whether we met our commit or not. The completion of the work over several sprints determines our velocity. From there, we can reasonably predict the level of effort we can complete during a sprint.
Why can't a team estimate in hours?
It's not a matter of can't. At Praecipio, we've seen many teams succeed well in estimating their level of effort in hours. However, this involved a significant effort to run time studies on routine tasks for the team. In a time study, an outside party will watch a person do a task and time it. Then watch them do it again...and again...and again. Then, the outside party watches another person perform the same task several times. The outside observer will continue with this until they feel they have sufficient data to make a reasonable assumption (read: average) of the time it takes to complete said task. Rinse and repeat for all tasks all personnel complete in a day and through out the week.
Estimating in hours works well in repetitive work environments. The same tasks must be completed the same (or similarly enough) throughout the day and week. However, when we're thinking about software development, we all know this is rarely the case. What may seem like a simple feature request can become a significant effort when looking at how the new feature interacts with the rest of the services, modules, or products. Yes, we've done something similar before and it took four hours. But what has changed since the last time we implemented something similar? What else have we deployed? Did we change our methods? Are we integrating this with another system? Have the APIs been updated or changed? How many releases have been performed since the last time we did this?
The shoulds and shouldn'ts of tracking time in Scrum
Why are teams being asked to track time when they estimate and understand level of effort in story points? In a word, Money. Under complex financial and regulatory practices, most businesses report quarterly earnings to regulatory bodies and markets. The best way a business has to gather and report this information is through complex financial systems that aggregate data from inputs across the organization. One of the more critical inputs? Time tracking. So how should we and shouldn't we track time in a scrum team?
- You should establish the minimum time guideline such as 15-minute or 30-minute increments
- You should not expect accuracy down to the minute for a given task
- You should expect the team(s) to continue to estimate their level of effort in story points
- You should not make the team switch to hours to estimate their level of effort
- You should centralize where the team should track time
- You should not expect the user to log in to multiple tools to track time
- You should download our Lean Budgets White Paper which details different ways of managing the data and provides a solution in Jira Align
- You should not expect to implement a fundamental change in financial tracking and reporting across your organization without help
At Praecipio, we have implemented several solutions to this problem across industries and with all sizes of organizations. For help regarding how your teams can balance time tracking, scrum, and financial reporting, feel free to reach out to us!
