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?


To help clarify a few things, at my organization each Task within a story requires 3 people.

  1. Someone to develop the task. (do unit tests, ect...)
  2. A QA specialist to review task (they primarily do integration and regression tests)
  3. 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.

  • 8
    Could you describe what your process is? We never use hours in our Scrum planning, and we never report hours remaining. Tasks are done when they're done.
    – dcaswell
    Commented Sep 27, 2013 at 17:08
  • 1
    @user814064: Good point. Every time I've seen teams estimating every task, they always got it wrong. Sometimes by a factor of 1/10 and more. Commented Sep 27, 2013 at 17:10
  • This process is new for me. In the past we have been burning down the task when it was complete. HOWEVER, I am trying to encourage people to get better at estimating. We can look back on our estimates and compare them to our actual and hopefully learn from it. It may be a fruitless endeavor, but it's something I want the teams to try for awhile.
    – AgileMan
    Commented Oct 1, 2013 at 16:12
  • It's kind of hard to explain why you shouldn't do this in the few characters you're allowed to type in here. Estimating is exactly what it name implies: it's vague, it's a ballpark figure and you can't get better at it in any meaningful, cost-effort balanced way. After all, it's called "estimating", not "calculating". I would advise you to read Neil Killick's posts on #NoEstimates: neilkillick.com/2013/01/31/… Commented Nov 7, 2013 at 15:24

6 Answers 6


That is 3 tasks, not one.

It may be one feature/story, but it is three tasks. A single task can be completed by a single person in finite time.

  • @user814064: it's not an assumption; the OP listed estimates for each task in the post Commented Sep 30, 2013 at 18:56
  • I should have been more specific ... this is ALREADY at the task level. For example, EVERY task (the small piece of the story) needs to be developed, tested, and reviewed. Even though the task was accomplished by a single individual ... others will spend time to assure it's completion. I suppose you can make each task have their own tasks ... but I'm not sure how that would work.
    – AgileMan
    Commented Oct 1, 2013 at 15:50
  • 3
    @AgileMan: in a common-sense world, a task is a single unit of work that can be done by one person, and three tasks in series by three different people is a project. In the scrum world...it's the same thing. (e.g. www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms#1129). Story-1-dev, Story-1-QA-review, and Story-1-code-review are 3 different tasks. If you must model 3-part tasks, perhaps 3 different burndown charts would be appropriate ;) Commented Oct 3, 2013 at 18:51
  • If this is needed at a task level you really need to work on your definition of done and break down your tasks. It should be a simple yes/no to know if a task is completed, not a process through multiple people.
    – SpoonerNZ
    Commented Oct 11, 2013 at 15:34


You are using the burn-down incorrectly in several ways. Tasks and stories are either done or not-done; by trying to track deviations from time-based planning estimates in your burn-down, you are actually re-estimating your schedule rather than estimating work-product remaining.

In Scrum, you should be measuring progress towards a Sprint Goal rather than measuring the Sprint's time-box. This keeps the focus on team capacity and feature delivery rather than on continuous scheduling adjustments.

Tasks vs. Stories

You are conflating tasks and stories. Stories comprise all the tasks required to complete the story per your team's "definition of done." The story is considered 100% incomplete unless all its tasks are complete. In Scrum, stories are always estimated in some way; most frequently, they are estimated in story points.

The tasks are the steps or milestones needed to complete the story. While each task may have dependencies and prerequisites, you can certainly say that the code review is complete or not, independently of the other tasks.


In Scrum, your burn-down chart shows the amount of work remaining for the sprint or project. Real burn-down charts often have plateaus; in some cases, the graph can even rise. For example, on a one-week sprint with two stories worth 3 and 5 points, your data points may look something like this:

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

In this idealistic scenario, you start with 8 story points. The 3-point story was completed Tuesday afternoon, while the 5-point story wasn't completed until Friday. The story points aren't deducted from the burn-down until the story has met the definition of done. If you're using ideal hours instead of story points, the only thing that changes is your scale.


The generally-accepted practice is to ensure that your tasks are decomposed into bite-sized chunks between 1/2 day and 2 days. Variance of more than one day should be self-evident from the daily stand-ups or the Sprint Backlog; there should be no need to perform a formal status pull.

You can also perform statistical analysis on the burn-down chart to determine if your sprint is trending correctly. Small deviations or plateaus are normal, but if no one is raising any blockers in the daily stand-ups but your burn-down seems stuck, that's generally a sign that the Sprint Backlog has been mis-estimated or there is "invisible work" that needs to be made explicit in your process.

  • I don't think we agree totally. Sure, the burndown chart does measure progress toward a sprint goal ... but it does this by measuring progress on specific sprint stories. Generally you can choose to burn down once a story is 100% complete, or you can burn down hours on each story each day as work is being completed. I am trying to do the latter ... but I'm finding it challenging for the teams to do. I feel as if your post strays from the question I originally asked.
    – AgileMan
    Commented Oct 1, 2013 at 16:09
  • one of the risks of not allowing a task to close 100% is having 100% of your tasks 99% done, which means nothing is actually "done"
    – hanzolo
    Commented Oct 1, 2013 at 16:19
  • 1
    @AgileMan You're finding it "challenging for the teams to do" because you're measuring the wrong thing. You're certainly welcome to apply any methodology that works for you and your team, but I'll stand by the statement that measuring original estimates - elapsed time is not the same thing as measuring work-product remaining. Do whatever works for your project, but don't be afraid to question the assumptions that underpin your current metrics.
    – CodeGnome
    Commented Oct 1, 2013 at 16:57
  • @CodeGnome. There is a simple mis-communication going on here. I'm not trying to track "elapsed time". I'm trying to determine "remaining time". When will this task be done? That is all I'm trying to determine. However, since even the smallest task (generally) involves multiple people, the challenge is how to determine what is left in a way that is simple & straight forward.
    – AgileMan
    Commented Oct 1, 2013 at 18:52

Can you define the dev task as "done" before QA does their part? Can you define code review as "done" before dev is done? Can QA be "done" if the dev and code review are not?

I would say that you should aggregate the three items into a single task and the three people should work together on it.

Scrum does NOT say that any item is any one team member's responsibility. Just the opposite--sprint log items are the TEAM's responsibility. If it takes three people to perform a task, then that's what it takes.

  • I have some doubts about that suggestion. To me, a dev task can be done before QA and code review, but code review and QA (which are individual tasks for themselves) most probably produce new dev tasks which can be "burnt down" individually. Of course, if "task" means "implement a full user story", then you are right, but why shall task be so coarse?
    – Doc Brown
    Commented Sep 27, 2013 at 19:07
  • @DocBrown - I've done it both ways. I have found that saying a task is done when it has not been verified (review and test) has not proven useful for tracking progress. Putting everyone one the hook for completing the task helps maintain urgency for all involved. Commented Sep 27, 2013 at 21:37
  • Obviously, nothing is "done" until it has gone through the DoD process. However, things can progress to a point where it can be beneficial to be reviewed by other parties. As it currently stands, I merge all "work" required for each small task into a aggregated hour as you have mentioned. The challenge is when one person is trying to report what is left, they usually have to account for their portion of it, and then add the other individuals estimates on top ... so it's kind of a lot of busy work. I feel like there is a better way.
    – AgileMan
    Commented Oct 1, 2013 at 16:06

It doesn't matter. As long as it's relatively consistent across stories, your burndown chart will still work either way. Use whichever way is most natural for your team to report.

My team actually does a sort of hybrid, although not by formal agreement. We put 16 hours if we think a task will take one person two days, but if two people end up working on it together, we don't change it.

After the initial estimate, it informally becomes more of a percent complete for our team than an hours remaining. If we originally thought it would take two days, but after one day, we think it's only 25% complete, we take 4 of the original 16 hours off. That leaves 12 hours where technically we're estimating 24, because we'll probably deduct 4 hours for the remaining 3 days.

That annoyed me as a scrum master at first, but strange as it seems, it's a very natural way to give estimates, because developers really hate to add hours to an estimate. It all averages out to make the burndown still useful, and that's what's important.


Task remaining time doesn't matter much: nothing can be delivered until the whole story is done.

If you want to track how much time is left on a story (overall) by having people fill in remaining time on tasks, then split tasks per person.

That said:

  • Big tasks might be an indication your stories are too big. In this case, the best solution is to reduce the scope and size of stories, and if you reduce it enough tracking remaining time on tasks doesn't matter any more (they're either done or not - sum of estimate on non done tasks is granular enough).
  • SCRUM encourages everyone to pick up what needs doing. If you are assigning tasks to persons (as opposed to roles), then you're potentially preventing yourself from delivering a story, even if developer is doing nothing - because QA is bottlenecked.

Divide the task into multiple tasks and enter them as tasks where each is handled by a different person.

Original Task: Fix something

New Tasks: (child of parent of original task)

  • Dev A - Fixing the issue
  • Dev B - Helping Dev A in fixing the issue (i.e. pair programming, code review)
  • Dev A - dev testing the fix using Dataset X
  • Dev B - dev testing the fix using Dataset Y
  • question states that sub tasks aren't allowed
    – gnat
    Commented Nov 7, 2013 at 6:01
  • i never meant sub task per se.. i mean break the task into tasks and make them all child of a story or bug.. i will rephrase my answer.. Commented Nov 7, 2013 at 9:02
  • well breaking it the way you describe has been already suggested and explained in at least two prior answers (top voted at this moment): "That is 3 tasks, not one..." "You are conflating tasks and stories..."
    – gnat
    Commented Nov 7, 2013 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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