Let’s say you are working on a piece of legacy code that was written before your company started using an Agile methodology like Scrum.
Now let’s say you discover a bug in the field that needs to be fixed and there was never a story for that feature written up. Everyone on the team knows what that particularly feature is and how it is supposed to behave but just no story associated with it.
Now in the current sprint you are to work on that defect because Marketing & Support are tired of dealing with the issue.
Do you create a story in retrospect for that defect to be linked to?
Do you relabel your defect as a story and modify the formatting so that it looks like a story?
If you don’t create a story, do you get points for the defect?
If you do create a story, do you get points for fixing the defect (via the story’s points)?
What’s the best way to handle this situation?
Update: Let’s say that all the sudden the installation process started to blue screen the system on Windows 7 64-bit and there has always been a requirement that the application installs on all Windows platforms. The new issue may have come about because of service pack 1 or something like that.
Yes. It’s worthy of review, also, to be sure everyone agrees on the story.
If it’s a bug-free, but annoying interface, then you are really modifying the workflow, and it does need to be memorialized as a proper story.
If there’s a bug involved, then there are unit tests which should have found the bug (but didn’t). This doesn’t seem to be your situation, but it’s common that incomplete unit tests don’t find a bug. Extending the unit tests (after fixing the story) is also very important.
Not really. The defect is just a defect, whether or not there’s a story in place.
Defects go away. Stories don’t.
Why not?
Edit. The story points issue is difficult. Ideally, the points track the work done and value created. Story == effort == points. But the issues arise in handling reuse, release and rework.
You have several, unrelated issues: effort, quality and value. The points can track one of those. It can’t track either of the others.
If you think velocity should reflect effort, then you can’t take points away because of bugs or requirements changes. It doesn’t track value created, and can’t be used for that.
If you think velocity should track value, then you must take the points away. It doesn’t track effort because the work was done, but credit for it was removed.
Rework is tough. Bugs and requirements changes are the same thing, they’re rework. You’ve got a whole spectrum of candidates.
“Simple” bugs where the implementation is wrong, but the story is “right”. Ideally, this doesn’t count toward velocity. Right?
“Incomplete story” bugs, where the implementation is right, but the story omitted some crucial (and technical) detail. Hmm. Who’s to blame? Who’s velocity measurement should be penalized for this?
What are we measuring? Effort? Work was done. Value? Value was not created.
“Wrong story” bugs, where the implementation is right, but the story was a bad idea from the get-go, and no one caught it. This can be called the “lying user scenario”. It happens. Ideally, this counts toward velocity. The users lied. But, how can you distinguish this from any other rework? What’s the “rule”?
“Changed story” bugs, where the implementation is right, and the story was right. But the overall context changed, and the story needs to change. This is just “enhancement” or “adaptation” and is like new work. Except of course, it isn’t full-effort work, is it? It might be just a tweak to existing code, so you don’t want to over-reward this with the full value created.
What are we measuring? Effort? Some was done, but not much. Value? Value was created.
Bottom Line. Points are a political weapon and don’t measure much. Either effort or value, but not both. And not well.