In my company, a single task can never be completed by one individual. There is going to be a separate person to QA and Code Review each task. What this means is that each individual will give their estimates, per task, as to how much time it will take to complete.
The problem is, how should I approach burn down? If I aggregate the hours together, assume the following estimate:
10 hrs - Dev time
4 hrs - QA
4 hrs - Code Review.
Task Estimate = 18hrs
At the end of each day I ask that the task be updated with "how much time is left until it is done". However, each person generally just thinks about their part of it. Should they mark the effort remaining, and then ADD the effort estimates to that? How are you guys doing this?
UPDATE
To help clarify a few things, at my organization each Task within a story requires 3 people.
Someone to develop the task. (do unit tests, ect...)
A QA specialist to review task (they primarily do integration and regression tests)
A Tech lead to do code review.
I don't think there is a wrong way or a right way, but this is our way ... and that won't be changing. We work as a team to complete even the smallest level of a story whenever possible. You cannot actually test if something works until it is dev complete, and you cannot review the quality of the code either ... so the best you can do is split things up into small logical slices so that the bare minimum functionality can be tested and reviewed as early into the process as possible.
My question to those that work this way would be how to burn down a "task" when they are setup this way. Unless a Task has it's own sub-tasks (which JIRA doesn't allow) ... I'm not sure the best way to accomplish tracking "what's left" on a daily basis.
