Bugs Source #1: Unclear User Stories
I think unclear specifications is #1 source of bugs. If you deliver something that was not intended, there will be many complaints from customers. In customer’s opinion almost all these complaints are bugs. Also, without instant communication it is very easy to miss important details and release an un-polished user story with a number of small glitches.
Agile development is very rapid. In many cases the path from idea to user story in progress is extremely short, it may be even 1 day. With this hard pressure on, it is very easy to make errors in user story description. Product Owner may miss some important details and as a result the story will do something wrong, something that was not expected.
This is the first question you must ask… is it a bug, or is it a change? I’ve seen a lot of bugs that have come up that were “We asked you for x, never thinking about y, so could you please change the system so that y is covered?” It’s a business scenario, so there’s no reason to expect a developer or tester to anticipate/test it. I know where we’ve struggled is in injecting items into the product backlog, we tend to classify it as a bug and so we end up with a lot of bugs, but not a lot of change in the back log. That’s exactly what I think we’re supposed to be avoiding in Scrum or any other agile methodology. As we see change, we should be taking it on as a feature and prioritizing it accordingly. Only when it’s something broken should it be called a bug.— Jim Leonardo
The best solution to this problem is communication.
Clarification meeting
The important thing in software development is to put everyone on the same page. Developer, Tester and Product Owner should run a small meeting about user story, thus forming a mini-team. If a user story has several developers and several testers, all should participate.
The goals of the meeting are:
- Ensure that everyone understands what should be implemented.
- Brainstorm acceptance tests/test cases and create a check list.
- Reveal and eliminate all discrepancies in story description/specification.
We have these meetings at TargetProcess and they are very efficient and helpful. Recently there have been some stories with no meetings, and as a result the stories had more defects and a longer cycle time. Side effect of the meeting is that Product Owner receives less questions about functionality later, thus having less interruptions (which is good).
Stories should be ready before iteration start
It is a good idea to have all user stories described with good details before iteration start. Thus testers and developers will have time to review them and prepare questions to the iteration meeting. It may trigger a much better discussion and reveal some interesting problems that were unclear initially.
There is a danger to document more user stories than required, and it will be a form of a waste. Product Owner should maintain good balance here.
