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?
4
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.
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.
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.
4
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.)
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.