Time Tracking in Scrum

Question

Note : Before asking this question I did an exhaustive search, and found little bits of the answer in various other questions, for example:

• What is the best resource for learning Scrum?
• Scrum Process Management - tips, pitfalls, ideas
• Two questions regarding Scrum

However, I feel like this question hasn't been directly addressed (if it has, please let me know).

Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not? Can you adjust those tasks and estimates?

Background: Our new VP of development came from a Scrum environment, and so we're all learning about the process, but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.

But it was my understanding that agile practices, specifically Scrum, were based upon the concept of tasks being buckets that store individual deliverable goals, and you add/remove/adjust them as the clients' needs evolve after each sprint.

I realize this could potentially be argumentative, but I assume that viewing Scrum as a process, only one of those concepts is the "correct" philosophy for that system.

Solution 1

Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not?

I track the estimated remaining work. This is a must have information. Without this, you can't draw the Burndown Chart. Without the Burndown Chart, you don't know "where" you are, you don't know if your Sprint is still on track or not. This would make this decision tool pretty useless. Yes, the Burndown Chart is not a tracking tool, it's a decision tool.

Can you adjust those tasks and estimates?

Sure!

Actually, the team owns the estimates, nobody else, and it is the job of the ScrumMaster to guaranty that this principle is applied. This should already answer the question. But there are other reasons.

As I said, a Sprint Backlog and a Burndown chart are decision tools and should thus be representative of where you really are. If you hide the reality, if you are not transparent, these tools won't help you to take any valuable decision, they will be useless. Think about it, what's the point of having good looking numbers if they are useless? What's the point of having a "nice looking burndown" if it doesn't reflect the reality.

So, during a Sprint, team members should obviously update the estimations of the remaining work as soon as they can do it (upward or downward). If a task estimate was initially 6h but the team discovers that more work has to be done and that the task will actually take 8h, the team should update the Sprint Backlog accordingly. If someone spent 4h hours on a task that was initially estimated at 4h but still need 2h work, these 2h should be reported on the Sprint Backlog. If the team discovers a task that has to be done but that wasn't identified, the team must add this task and its estimate to the Sprint Backlog. And being not accurate in the start is not a problem, as long as you update the backlog with the knowledge gathered over time. The sooner you make these updates, the sooner you'll be able to adapt and take decisions.

That said, it can be useful to keep the "initial estimate" and to compare it to the "actual time spent to complete". But not for tracking purpose, only to help the team to make better estimates. Actually, I would advice to not do this if you are transitioning to Scrum. There are often many other impediments to solve, many other things to improve first when you are learning Scrum values and principles. And if you do it, beware of the Waterfall daemons. Be ready to fight them, they may come back very fast.

Solution 2

The answers I see here aren't wrong, but I don't think they've really addressed your question.

I think you're asking, "Should I track the total hours actually spent on a certain task?" The answer is, "You can if you need to, but it isn't part of Scrum."

Scrum is a very lightweight process. It defines/requires only what is needed to make Scrum work. You can (and, in many cases, probably should) overlay other processes on top of Scrum in order to suit your organizational needs. For example, if tracking the total hours actually spent on a task enables you to better estimate similar tasks in the future (as it seems your VP wants), then that might be a good reason to track total hours, provided that it doesn't interfere with productive work too much. Or, perhaps you need to know the total hours for billing purposes. So just because Scrum doesn't require something doesn't mean you shouldn't do it.

However, for the purposes of Scrum itself, there is no need to track the total hours actually spent on a task. It is not needed for any of the Scrum artifacts, which only track the estimated amount of time remaining.

Solution 3

I don't know if our implementation is "correct", but what we do is:

• Have Backlog Items added, which we put an estimated complexity number on (in relation to other backlog items).
• Before each sprint, we go through the backlog items in priority order (prioritized by the product owner), break them down into tasks for which we make a time estimate (in hours).
• When the number of available hours in the sprint are used up, the sprint is full

Then, during the sprint after each day of work we adjust the times on the tasks that we have been working on, so that they show the number of hours that we think is left before the task is done. This means that if I have a 6 hour task, work on it for a full day (we consider 6 hours a full day) and then feel that I still have 2 hours left before it's done, then I take down the "hours left" from 6 to 2. In case the task is time-boxed we need to check actual hours used instead, of course.

Solution 4

I have to add something here because

but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.

Is just plain not scrum so I don't know where your VP got his info. Tasks (know as Sprint Backlog Items) are not created until Planning the next sprint. They are created just in time and certainly not before the project starts. Before the project starts (Sprint 0), the Product Owner creates the Product Backlog and fills it with stories. He can add to it at ANY time during the project. It is his to manage. The team estimates these stories roughly against one another in story points or some other relative measure (ideal days?).

The estimating of tasks in hours is only a tool the team uses to figure out how many stories to commit to in the sprint and then to plot progress to predict success (burndown). Once a team has gelled and has a historical velocity; it may decide to not do any tracking in hours at all and just track their burndown in story points or # of stories. Estimating in hours is a form of waste in itself if the team does not need it to achieve commitment to the sprint goals.

I would ask the VP what these "very careful" estimates are going to accomplish.

Solution 5

Estimate time, but don't really care if it's spot on

Just make sure you are careful and estimate tasks thoroughly. Basically you don't really measure time, because it's more error prone. The best way is to use tasks' time estimates as story points. This way you will gain:

1. If your time estimates are off, research shows that they tend to be consistently off (accuracy factor doesn't change too much), so time estimates can easily be used for story points calculation.
2. If you empirically managed to do x number of story points in previous sprint, you'll probably achieve similar results this time round even though your time estimates are incorrect.
3. You will have to be rather good at estimating all story tasks. Otherwise your sprint story points tend to grow during execution and you won't meet your deadline - even though your velocity will remain practically the same
4. Estimates can change but similar to #3, keep some sprint slack time for these changes to meet sprint deadlines (demo day).

But keep time estimates to actually see which tasks must split or join.

View more solutions

Comments

[NateDSaint]

I chose this answer because it fully responds to all of the criteria of the question, as well as giving a good amount of friendly information. Thanks Pascal!

[Karl Kieninger]

This is a very agile answer. There are lots of reason you might want to add more explicit tracking of time actual spent on top of scrum. The most common is probably cost accounting. That is, being able to but the teams time in to meaningful accounting buckets.