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.
4
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.
4
TL;DR
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.
Burn-Down
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.
Time-Boxing
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.
4
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.
3
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
3