Timeline for How to approach scrum task burn down when tasks have multiple peoples involvement?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 1, 2013 at 16:06 | comment | added | AgileMan | 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. | |
| Sep 27, 2013 at 21:37 | comment | added | Matthew Flynn | @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. | |
| Sep 27, 2013 at 19:07 | comment | added | Doc Brown | 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? | |
| Sep 27, 2013 at 17:14 | history | edited | Matthew Flynn | CC BY-SA 3.0 | deleted 3 characters in body |
| Sep 27, 2013 at 17:05 | history | answered | Matthew Flynn | CC BY-SA 3.0 |