Is it possible to give accurate estimates and planning without tracking time for tasks?

Question

I work within a small team of developers. We don't track our time so we have no data to work off when we give estimates. Basically, I'm wondering if it's possible to have a successful plan and give accurate estimates when developers or others don't track their time for tasks.

Difficulties we're facing are being able to accurately plan when not knowing how much time people have available (more difficult now that we're working multiple projects simultaneously), convincing people to track time when they haven't been required to for years, and how to best accomplish it without interfering with work and "flow".

I've been thinking of inadvertent ways to track time, such as using a tool like Jira and using the time in each work lane to do reporting.

Answer 1

To answer your question, yes: it is possible to provide relative estimates without tracking time. Estimates should provide context into the amount of effort that goes into a work item, not the amount of time it'll take to perform the work. Remember, these estimates are effort forecasts, not commitments. The team should use the acceptance criteria and goal for each piece of work to estimate the amount of effort will go into the work. This can be done a number of ways, but most teams use a point system or T-shirt sizing method to provide relative context across various items.

Estimating based on effort has two main artifacts:

First, it allows a development team and its product owner to make longer term forecasts about how much can be delivered by a certain date. It allows teams to answers questions regarding how much can be expected to be delivered by a certain date and at what point in time will the product see 'x' amount of work completed.

Second, it aides product owners in prioritizing work. Priorities should be set based on the expected benefits and opportunity costs of the estimated work items relative to one another. If there is a quick, value add win that has a low estimated effort, that may take precedence over a piece of high-effort work that does not provide as much value. Knowing relative-sizing is critical in prioritizing value before development work even begins.

That said, in the event you want to begin using time as a means to provide transparency, I recommend reading the Kanban Guide for Scrum Teams to glean some ideas. This guide will show you reasons to use things like cycle times, work item age, throughput, SLEs, and WIP limits to provide hyperfocus into how to inspect and adapt your development practices as you move through a project. I've found these metrics also help with the estimating portion of our work as it provides empirical context into past estimates.

Answer 2

As it seems to me, accurate estimation without having formal stats is possible when you:

• act in the circumstances of stable risk factors (which impact your team with some stable risk measure).
• have stable core of your team.

First point means that there could be hidden risk factors that are not obviouse when you do a subjective estimation. However looking retrospectively at the "estimated vs actual" or just "actual" logged time for stories having relatively similar complexity you can detect (using statistical methods) impact of the risk which has not been accounted before

The second point means that having the team core changing frequently the new members might not have the full picture of the environment and might not account certain specific of that environment. Thus having the work stats they would apply it to their personal subjective estimations mitigating the risks of introduced by their environmental knowledge.

Answer 3

Depends on your definition of accuracy. Historical information is an important input into the estimating process, whether it is your own historical data or that of industry. Obviously, your own historical data that comes from the type of work you do would be more valuable than industry data. So, if you're not tracking it, then you are doing without a valuable piece of information.

A good estimate is one that provides the probabilistic range, not just a discreet value. If you're not tracking historical data, then your cone of uncertainty will be naturally greater. With history, you could arrive at a tighter estimate for a piece of work that might look like: best case -- $1,200,000; worst case -- $4,000,000; most likely -- $2,300,000. Without history, you may end up with an estimate of best case -- $1,000,000; worst case -- $6,000,000; most likely -- $3,000,000. This makes it harder to choose a planning value to price and against which to track.

To answer explicitly: you can get away with it but you are carrying more risk, risk of a ton of loss on any given project or even risk of losing a competitive bid.

Answer 4

As Keith said, it’s possible, in fact some big companies I’ve worked for, don’t log times and yet they are productive and get things done! It all depends on use cases and being very aware of what’s bringing value and what’s not. (Just to clarify, in general I do believe in the value of logging times for several reasons like the ones found in your comments and in other's people's posts).

Now, going through your post, I want to mention that the fact that they didn’t track their time for years, wether it was right or not, it’s not an argument to say that they shouldn’t log it now. Projects evolved and processes (“flow”) need to adapt in order to work effectively. Once suggestion to convince them is taking a “baby steps” approach, maybe they are thinking that logging will require a lot of their time, but you can always start simple and dedicate say, 20 minutes a week to estimate high level, what tasks you worked on and how much time they took (before sprint planning perhaps?).

Create a nice presentation explaining why you believe it’s now necessary. Show how the project has evolved and maybe add some numbers to quantify how difficult it has been lately to do planning, remember to mention that in the end is to improve the ways of working and that they’ll ultimately benefit from doing it.

On a side note, I feel that you need to make sure that you actually understand what’s the problem, what’s the root cause and how can you solve it, maybe it’s also better to chat with some members of your team and figure out what’s the best approach to solve it.

Answer 5

Tracking time for tasks is required for estimation, recorded by handwriting or soft copy, just as you like.

Re Sarov: We need figures for estimation of task time, some people like timesheet to record task time and some like for example Excel worksheet to record task time. Some people like using averages/ minimums/ maximums, you can choose as appropriate. Estimation of task time is for task/ project management. If you think it is not important, you may not do this.