Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my organization when we move a task to the "Done" column we write the number of hours it took to complete the task. It can be useful when during retrospective the team tries to understand why certain stories took longer to implement than anticipated. However it is also burdensome and developers feel somewhat micromanaged or stressed when they have to do this.

What do you do in your teams? What do you recommend?

share|improve this question
If they feel stressed about it, perhaps the retro is more about assigning blame then about learning. Looking at spent time versus planned time is a good way to get better at planning. That said, it should never be on a per story basis as that will quickly get in too much details or blaming. Where I work, we do keep track of spent hours, but never look at it during the retro. Product Owner and Scrum Master analyse the figures to spot patterns: stories with characteristics A and B or estimated at XXX vary widely in implementation time. It is good input for the grooming and planning sessions. – Marjan Venema Feb 3 '14 at 11:43
I'm curious as to why the developers feel micromanaged or stressed. How accurate are these time-to-completion for tasks supposed to be? For example, as a government contractor, we have to record project time to the 1/10 of an hour. However, for our tasks (including defect fixes and enhancement implementations), we record estimates of time to complete to the closest couple of hours. For extremely long tasks, even less granular than that (a task that took about a week of design, development, and tested may be recorded as "40 hours"). – Thomas Owens Feb 3 '14 at 13:17
The retrospective should identify processes that could be improved for future iterations. Time taken is a fait accompli. Besides, if all stories for an interation are completed on time - what is the issue? Some stories will take longer than estimated, some less. By itself, endless hand-wringing on why some things take longer than expected achieves nothing. – Robbie Dee Feb 3 '14 at 15:32
"Let's see, Task 1234 took more hours than any other. Bill was spear-heading that task, I Bill, what happened?" This very quickly moves from team as the atomic unity for examination, and becomes about individuals as units for scrutinizing. This almost instantly undermines one of the most valuable points of Scrum/Agile - the unification of the team and collaboration/cooperation - and turns it into people maximizing their own hour reports so as to look good, avoid scrutiny, etc. In short: you should probably throw out that practice completely and skip The Mythical Man Month. – BrianDHall Feb 3 '14 at 20:05

There is no concept of "time taken" in Scrum, simply because all activities in Scrum are time boxed (stories are time boxed within an iteration).

There is a concept of "time left" but that is only useful for building a burn down chart of the current sprint -- it is not an indication of work done by any means (time left can go up, down or stay the same even if people are working on a task).

In other words: the time it takes to do something is not an issue that is relevant in Scrum. Velocity (points per sprint) is interesting instead, but the aim is never to increase it. The aim is to make the team move at a predictable rate.

share|improve this answer

I would recommend not recording elapsed time then!

Firstly, are these metrics actually used, or do they generally say "roughly what the estimate said"? If estimates are all over the place then you have other problems. If estimates are 90% accurate then you will know which problem tasks caused problems and there's no need to record which ones they were - the person working on it will quite happily shout "don't give me another f*** task like that f*** one again" and you can discuss why it was so problematical :)

Overall throughput of work is what matters in Agile systems, if the team is getting the job done, who gives a fig how long each bit took?! (ok, I know, some anally-retentive managerial types do. They need to loosen up and focus on the bigger picture, not micromanage each task).

Don't forget - ultimately tasks are an artificial way of splitting up work into easy-to-accomplish bites. The estimate that gets assigned to them is equally artificial. What matters is what you end up achieving.

share|improve this answer

I never ask teams to record actual time taken for tasks. My experience teaches me that it serves no useful purpose. But I'm also aware that it's not a Scrum Master's decision to make.

Scrum Teams are self-organizing and it's for them to decide whether recording actual task time is useful. If they decide to do so, I might point out the issues I think could arise but mostly, I let them try it for themselves and retrospect on the outcome.

share|improve this answer
According to Mike Cohn it is your decision actually: – Eugene Feb 3 '14 at 16:00
@Eugene I can't see where Mike says that in the article. Perhaps you can point it out for me? – Derek Davidson PST PSM II CSP Feb 3 '14 at 17:52
"a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.” – Eugene Feb 4 '14 at 6:50
@Eugene Mike says "A Scrum Master has authority over the process." A Sprint is part of the process, writing how long a task took is not. In my experience, good Scrum Masters never tell the Development Team what to do. They guide, mentor, coach, assist or facilitate but they never command, or direct. – Derek Davidson PST PSM II CSP Feb 4 '14 at 9:03

I agree with the other answers which say that tracking time per task may not be useful for Scrum purposes. (Velocity is better tracked at an iteration time-frame, not per story or task.)

However, I also believe that software development requires discipline. There are things that professional programmers should do even if they feel like a pain, such as entering useful commit messages into SCM, sharing data regularly, code reviews, etc. Some job requirements just aren't fun, but they've got to get done.

So I'd say you go back to your team (or management) and find out if tracking that time is actually beneficial. If it isn't, get rid of it. But if it is, the team needs to buckle down and do it. Just try to figure out a way to make it as simple as possible. (On my team, we use JIRA to indicate what each team member is working on, so it's fairly simple to log time as we go.)

share|improve this answer

As Sklivvz pointed, Scrum does'nt have the concept of left time over single task: im my experience, the tracking the time of single task can stress the developer in strong way (I remember my ex-boss saying me that he would to measure too the time of personal phone call and minutes in toilette :| ) and you consider context's events out your control (for example, corruption of rigid disks of repository machine and lose of the code (Yes, this heappens :)).

I think the the engaged time is an effect of definition of task; more the time is engaged, more the task has some big-effort-point or some unprevedible or unreproducible problematic event in the context, out your control. I go out the stime, why? Difficult in algorithmic? Late in receive the coherent requirements? Problems with configuration of hardware? Lost time in fixing old bug what give effects in new development?

In my experience, I thinks it's better to utilise some standard metric (Function Point, complexity, etc) and see if the task respect the normal values of this metric of the0re's too much difference.

It's the the business task what determines the effort time, not the time what determines the business goals of the software.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.