HI, I am new to the scrum methodology and looking for some help to get comfortable with the environment and wondering if there needs to be a bucket to track Developers and QA hours spent on deployments and bug fixes and retests. Seems like it could have major impact on the graph.
+1
A:
The way I tend to handle this is to move bug fixing outside of the sprint. So a three week sprint might be followed by a week's bug fixing before demo/ release.
It isn't an ideal solution as no attempt is made to estimate the number of bugs that will be fixed in the bug fixing phase though. So I'm looking forward to others giving a better solution than me.
David Arno
2008-10-06 17:45:08
HI, it is likely that you have some High or critical bugs during the scrum which needs the immediate developers attention and hence could cause a impact on the rest of the deliverables.
Chanakya
2008-10-06 17:56:07
What are the odds that a huge critical bug only emerges just before a new release - like david mentioned, the release sprint will ofcourse be more focused on fixing/closing bugs.
Per Hornshøj-Schierbeck
2008-10-06 18:01:53
Its not just before the release, but during the sprint some bugs may take longer than expected and my question is how we count the hours for these. I think it should add on additional hours to original expected guess and that may affect the graph
Chanakya
2008-10-06 18:37:14
Remember you do not track hours spend, but hours remaining - with or without new bugs. Tasks taking longer than expected or bugs/stuff uncovered during a sprint might result in hours remaining increasing.
Per Hornshøj-Schierbeck
2008-10-06 19:23:21
Yes, so that will take the things over the budget as we are not adding another resource and by keeping the hours in hours remaining bucket we are in a way not accurately budgeting the stuff by not reporting the directly hours we spent on bug-fixes
Chanakya
2008-10-06 19:55:37
Chanakya, if you get "High or critical bugs during the scrum which needs the immediate developers attention", then they should be treated as unplanned items and added to the backlog. Anything else takes lower priority than the sprint and so waits until afterwards
David Arno
2008-10-07 09:20:37
David, I believe only low priority items can be moved to backlog, high ones should get immediate attention no matter what as it seriously affects the testing efforts. The idea of moving some other items to next scrum makes sense.
Chanakya
2008-10-07 13:35:55
+2
A:
Bugs uncovered during the sprint, belonging to that sprint should be fixed automaticly as if the task/story wasn't done to begin with. Bugs emerging from previous sprints could be entered into a bug-backlog and prioritized just like the normal backlog.
The number of severe bugs emerging in a sprint should be minimal as everything is already tested before accepted and delivered to the project owner at the end of the sprint.
In reality it shouldn't impact the graph since you will commit to fixing a certain amount of bugs (by the choise of the PO - some bugs have lower priority than new functionality) and when bugs emerge from a sprint itself, well the task really wasn't done so it's ok to realize that and spend time fixing it.
Per Hornshøj-Schierbeck
2008-10-06 18:00:18
Yeah well i added the comment above, but some teams end with a release-sprint just before a new release. Some teams release after each sprint, but they are normally really good at uncovering bugs during the sprint itself (they might have really good tests and practices to develop "bugfree")
Per Hornshøj-Schierbeck
2008-10-06 18:03:27
Thanks for the comment. If we decide to tie these bugs back to the original sprint bucket still we have to count this time we spent on fix and retest somewhere in the sprint. So it may create a spike or something in a graph for additional hours and hence going to affect the outcome
Chanakya
2008-10-06 18:33:28
Spikes are ok - if you uncover stuff during a sprint you reestimate and recalculate remaining work. That often results in either a flatning of the burndown or even a spike up.
Per Hornshøj-Schierbeck
2008-10-06 19:21:46
+1
A:
In each sprint I have two 'tasks' - one for bugs found in the current sprint (i.e. on unshipped code), and one for issues found in anything else (any shipped release). This helps me keep track of how much time is lost (per developer) fixing bugs.
Any time logged in the latter category is regarded as waste and it's a key target for reduction. Time logged in the former is reviewed for how it can be more closely linked to the features and changes that caused it.
Don't put estimates against bugs, instead try to add that time to the estimates for unit/functional testing against the features you're working on.
Feel free to adapt any model to suit how your team works - there should be a culture of continuous improvment in any Scrum team, and the devs should be able to suggest and try out improvements as they learn Scrum.
Keith
2008-10-06 18:52:14
+11
A:
My team is supporting a number of legacy apps, so there's quite a bit of unplanned bug fixing that occurs during each sprint. We've adopted the following practice:
- If the bug is easy/quick to fix (one liner, etc), then just fix it.
- If the bug is not trivial, and not a blocker, then add it to the backlog.
- If the bug is a blocker then add a task (to the current sprint) to capture the work required to fix it, and start working on it. This requires that something else be moved (from the current sprint) to the backlog to account for the new hours because your total hours available hasn't changed.
When we add new bug tasks we'll mark them differently from the planned tasks so make them easy to see during the sprint review. Sometimes unplanned work ends up being >50% of our sprint, but because we're pushing planned items to the backlog we know very early what we're not delivering this sprint that we had planned on.
This has proven to be very useful for our team in dealing with legacy apps where none of us are as familiar or confident with the systems as we'd like to be.
jpeacock
2008-10-06 20:48:10
Thank you for sharing the knowledge. This is really something I was looking for to improve our practice. This is a big help. Thanks again
Chanakya
2008-10-06 21:07:48
A:
I think it's hard to estimate the effort for bug fixes before you've diagnosed the problem, and diagnosis is often the lion's share of the time spent.
If your bug volume is fairly consistent, I would just let it "come out in the wash" against velocity. This is what I usually do for production defects that impact a team's iteration goals.
If you realize mid-iteration that you're falling behind (e.g. you see a burn-up chart that's not looking like it will intersect with your scope line by end-of-iteration) due to bug issues, then you can adapt scope (drop out the lowest priority story) to accommodate the extra work.
Adrian Wible
2008-10-07 15:31:55