Menu
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.
305
Effort spent on fixing bugs is negative work, so not accounting it in velocity helps us focus on the business value that is being delivered, sprint after sprint. Instead of adding story points to bugs, we should work towards improving the velocity by reducing the number of bugs.
There are, of course, scenarios in many companies where development teams do not have the luxury of working in a shared space. People will work in cubes, offices, or worse, distributed. Any sort of separation introduces issues, not only with bug management, but with any sort of team-based development models like Scrum.
Bill and I both do real-time bug fixing. In The Scrum Field Guide, I advocate fixing high and mid-priority bugs in real-time, but putting low-priority bugs on the product backlog. Bill fixes every bug in real time, even the low-priority ones. We’ll come back to that whole putting-on-the-product-backlog later.
How Defects should be handled in Scrum? There could be different category (requirement defects/production defects) of defects of different severity/priority (urgent/showstopper/critical/non-critical) getting identified by team at different stages such as during sprint/in production/from prior sprints. 1.
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:
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.
199
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.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
