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.
Do you count the hours spent on bug fixes towards the scrum? [closed]
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.
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 –
Hoad
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.
EDIT: Just realized that by mentioning the "bug-backlog" i open up for the "multiple backlogs" which is a bad idea. A better way could be to mark the entry in the backlog with a bug flag or just accept it as any other story in the 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.
EDIT: Realized something else - sometimes working on a scrum team won't always protect you from the reality of having to maintain other applications, support, etc. While this really sucks and makes the whole idea of being on a team with a single backlog and focus not really work, the reality is often that you need to reserve a fixed number of hours a week for support/maintain. Don't encourage this, but if this is the reality try and assign a single person (on rotation so (s)he doesn't turn sad) each week a fixed number of hours dedicated to said support role. This way, you know what to expect since velocity is relative - it will somehow seem like a smaller impact on the sprints.
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") –
Barmen
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 –
Hoad
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. –
Barmen
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.
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. –
Hoad
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. –
Barmen
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 –
Hoad
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. –
Barmen
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 –
Hoad
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 –
Krp
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. –
Hoad
Bug fixing Sprints are a Scrum anti-pattern: blogs.msdn.com/b/progressive_development/archive/2008/05/27/… –
Habituate
However, from the dialog in that MSDN blog article: "However, past experience and the reality of software development have made me realize that bug fix sprints can be a necessity in large organizations practicing agile development." –
Fons
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.
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.
© 2022 - 2024 — McMap. All rights reserved.