Our 45/55 resource split (or lack of resources) has become apparent on our new product development. We spend 45% of our time on new product work (a very exciting WPF application, Ript) and the other 55% on internal enterprise work (to keep the tv station up and running). This split yields about 4 development days on Ript during each two week sprint .
We're all excited about Ript and want to share it with our friends and family. This gives us extra drive to complete the list of stories left for release!
This drive coupled with the lack of time has become evident in a recent spike in bugs and refactoring cards. The goal of the current sprint is stabilize the application, because we ended our last sprint with an unreleasable application. So, our burndown for the sprint included every known bug in application.
Our burndown looks something like this:
Sprint goal: Stabilize application -- fix 18 open issues
Bugs fixed so far: 26
Bugs left: 16 (I told you that last release was unreleasable!)
Because our goal is stabilize the application, we're treating the bugs as stories and adding stories to the sprint as bugs are found.
How did we get here? We are all profession, strong developers who are very committed to quality...
What went wrong?
Well... we've been "finishing" stories when they aren't really "done."
This isn't happening because we are lazy or over worked or don't understand the requirements, but because we are so desperate to move forward in the project.
When you have a 2 week iteration, even if you don't spend all 2 weeks on the project, you want to finish 2 weeks of work. Especially after a few weeks of enterprise work that take up more than 55%...
Enough explaining why we have bugs...
What was this post about anyway? Oh yeah... making bugs stories...
I had an ah ha moment the other day when I was thinking about where bugs belong in the sprint backlog. As a developer and a user of an application, I don't want any bugs. Our customer proxy may want features before bugs are fixed, but we may want to fix bugs before adding new features, because the bug could be a smell of a bad design or some needed refactoring... basically prioritizing bugs difficult!
Have you seen this bug rating system before (or something similar)?
Priority 1: Application crashes, no work around, data corrupted/lost
Priority 2: Application crashes, work around OR bug, data corrupted/lost, no work around
Priority 3: bug, no data corrupted/lost, no work around
Priority 4: bug, data corrupted/lost, work around
Priority 5: UI interaction, nuisance, no loss of data or work
This makes prioritizing bugs easy, but there are a lot of times a priority 5 issue, which is usually considered releasable, could be the downfall of an application. Meanwhile there could be a random crashing issue that occurs on one machine that gets fixed first because it is priority 1... not to mention, its so random it takes days to track down (there goes an entire sprint!)
Not only do these make little sense for prioritizing your sprint, they also offer no help when it comes to quantifying the impact of bugs on the teams velocity...
Introducing my new system of bugs:
Rules:
1. All bugs are stories
2. Like other stories, they are prioritized by the client and estimated by the team
3. If a bug appears as a direct result of a story completed in the sprint, it is added to the sprint and impacts velocity
4. Every sprint there is a small timebox to fixing/investigating bugs that the client hasn't included in the sprint (this doesn't affect velocity and the sprint should be planned accordingly)
5. Although the client prioritizes the backlog, the developers should feel confident about their codebase and may request bugs get fixed ahead of higher priority stories
What do you think?
The main idea is that bugs, like anything else, need to be user facing and should impact your velocity and sprint planning.
Like some other things, bugs happen :)
Subscribe to:
Post Comments (Atom)
2 comments:
Questions about your suggestion:
1) If something is a bug, isn't it by nature very difficult to estimate?
2) If quality is a non-negotiable and owned by the team, isn't it wrong to put the customer in charge of deciding whether it's OK to have things broken?
1)Not necessarily. I've found that bugs go either way, you can or can't estimate them... And the ones you can't, you usually can after a few hours of investigation... Thats something rule "4" helps with.
2)That's what rule "5" is for :)
However, I'm not convinced non-negotiable quality, application bugs and "broken" are all relative or mutually exclusive. It really depends on the bugs, whats "broken," when you're releasing and what the customer wants.
3) Aren't you on VACATION???
Post a Comment