Tuesday, April 14, 2009

Are defects the original user stories?

Just asking, and yes the defect comes after you've written something and someone somewhere found out it was not working as expected, but they feel similar to me.  Well at least similar in the context of "We have to have a requirements document signed off by everyone up to the CEO before we can even begin to consider to think about starting some kind of technical specification for the solution, so we could never use stories."

I would guess you already have defects, and when you are decide to fix these there isn't a document that bundles them together in some way (why would you try to do this, most defects would be independent, not all, but most).  There wouldn't be a sign off process, there is nothing to sign off.  The person doing the fix would need to spend time talking with the people who found the defect, and others to work out how to fix it and what the fix will look like - hopefully.

The defects would be - to a greater extent - recorded from the perspective of someone outside the system, rather than a technical task.  Of course there would be some prioritisation on what to fix first, because some defects have a greater impact/value than others.

Defects come with test criteria as standard.

It all feels very story like to me.  Surely if you can work with defects, then it shouldn't be too much of a leap to work with stories.  Maybe.

2 comments:

Darren Cotterill said...

Hmm.. our projects are even more similar than I knew.

People are used to the prioritisation too. There is usually a fixed test phase where all the defects won't get fixed, so are prioritised, and all the 'minor' issues probably won't make it in. This doesn't seem to trouble people, but not having 'minor features' does.

Maybe we need to stop building good quality software - write a 'feature' that doesn't work in 1 second, say it's done, then track everything as prioritised issues :-D

L said...

It's so crazy it might just work.