When I was first introduced to scrum methodology, time estimation seemed rather mysterious. How are you supposed to know how long something is going to take until you’ve actually done it?
Making good estimates is tricky. It means taking into account all the time spent researching, all the false starts, all the time spent (not wasted!) on trial and error. It means facing the reality that sometimes we go in circles. And it means admitting, out loud, in front of our peers, how long we think something is really going take.
Our ability to estimate the amount of time needed improves with experience. We learn to consider the likelihood that once we dig into the details, an issue in our sprint will be more complex than expected, or that expectations will change along the way, or that the bit of code we thought we could reuse won’t quite work. But our ability to make realistic estimates doesn’t improve as much as one would think. Even as mature adults we tend to underestimate the time (and frequently, the money) needed to complete our projects.
Why We Get Time Estimates Wrong
Even the most cynical among us tend to be overly optimistic when it comes to estimating time needed. Psychology has a name for this – the planning fallacy. When we make plans, we imagine things working as they should. We don’t account for all of the surprises, all the things that go wrong.
Of course scope creep is another cause of items in a sprint taking longer than planned. We want to please. We want to build cool features and sometimes it’s hard to resist when you see that by investing just a little more time, you could deliver new functionality beyond what’s expected.
The other reason we get estimates wrong is because we’re human, and our perception of time is just that – perception. The pandemic has provided a good example. Remember how agonizingly long 2020 felt, especially compared to 2019 and even 2021?
We can try to mitigate these affects with sober planning, by adding those extra ideas to the backlog rather than the current sprint, and by using consensus (playing poker) to estimate time. Developers get better at estimating time with time experience, but in the end, until you bring some real data into play, your estimates will always be guesstimates.
How Clockwork for Jira Can Help
One of the best ways we can improve our ability to estimate time is by accessing data on the true amount of time that we’ve needed for past activities. Clockwork Automated Time Tracking for Jira can help you do this. Here’s how it works:
If automatic timers have been enabled, then Clockwork will track any time that the issue is assigned and in an active status. (You can control which statuses are considered active. By default, Clockwork will use any status that is part of the In Progress status category as an active status.) This means the timers will start automatically and time will be tracked in accordance with your team’s workflow.
Once you have automatic time tracking in place, you can create a report that can be reviewed during retrospectives to see how much time planned activities really took. Since Clockworks lets you breakdown timesheet reports project, fix version, epics, and issues (among other elements), it’s easy to drill down to specific items and see how long they took. Then you can go into your next sprint meeting armed with real knowledge about how long issues usually take.
The advantages of using Clockwork are simple. You have a way to collect real data on how long tasks take. Automated timers means you’re not relying on the users to remember to start the clock, and detailed reports allow you to see actual time spent, broken down in a way that’s useful for making future estimates.
