Is it wise to generate stories for defects when using Scrum and there is no story already created?

Question

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.

Answer 1

Do you create a story in retrospect for that defect to be linked to?

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.

Do you relabel your defect as a story and modify the formatting so that it looks like a story?

Not really. The defect is just a defect, whether or not there's a story in place.

Defects go away. Stories don't.

If you do create a story, do you get points for fixing the defect (via the story's points)?

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.

Answer 2

In Scrum, there are only user stories. A defect, like a feature, is a request by the product owner that some change be made to the system to deliver new business value.

If a defect is reported after release, that should go into the backlog as a new story. It's perfectly fine to track some notes on the details of the defect (who reported it, environment, etc). As a story, it should be estimated by the team prior to selection for a sprint by the PO.

If a defect is reporting during a sprint and the decision by the PO (and the team) is that it's low-level and doesn't cause the story to fail, that defect moves back into the backlog as a new story for future consideration.

In my teams, we often find that defect based user stories come in at 0.5-1 point in size - not always, but often enough. We've found that selecting a suite of 0.5-1 point stories can introduce some noise into the velocity in the sprint since each estimated story builds in some estimation error. We'll cluster several stories together, if very small like this, and create a story cluster estimate. We've found that sometimes due to overlap of the various fixes that the estimate is different - (5) 1-point stories might total to 3 points overall for the cluster.

Answer 3

There are more ways to do it. I usually create the original story and the bug. I give the original 0 story points because there is no work remaining on it -- and the work remaining should always be the main focus of story points -- not "team scores".

IMHO you don't "score" story points. What you do is eat them during the sprint. If you are a good boy and eat it all you can have dessert (more backlog items). If not, then you eat leftovers in the next sprint :-)

Update: You can also only write the defect, since you really didn't implement the origninal story in the sprint (or in the current project for that matter)

Answer 4

I would like to suggest keeping things simple. I don't see a real, valuable difference between a story and fix to a defect. Both of them change the system; both if them will bring some value to the user out customer upon completion; both of them have a cost; both of them are more important than some stories (and defects), and less than others.

So, if it walks like a duck, and quacks like a duck... I'll call it a user story.

Treat it as any story (you could write it up like "in order to be able to save my high scores, as a fire fox user, I want JIRA 234 to be fixed").

That way the PO can decide when to deal with the bug, like any other task.

Hope this helps, Assaf.

Answer 5

TLDR:

A story is needed to capture the requirement (as you would capture any requirement) with the defect you want to fix. The story is needed to write a test against so that you know when the defect has been fixed.

Long version:

You have a defect.

How do you know what piece of functionality is defective ?

The functionality that is defective must be documented as a requirement or have some specification somewhere; be it in on paper, in an email or someones mind.

So IMHO it makes sense capture it as a Story.

Why ?

Because you need a story, everything you do should be against a story. How will you know when you have fixed this defect ?

The only way to know is with some kind of test. How will you know when the test has passed ?

A defect will tell you give you a test fail criteria, it wont tell you when it should pass. Note: If you happen to have a description of what should happen in the bug report, then that info can be captured as [part of] a story and be captured as pass criteria for a a test.

So to know if your test has passed, to know a piece of functionality is no longer defective is to have a requirement of how that test will be passed, you should capture that requirement as a Story, like you capture all your other requirements.