Sometimes when bugs are found, the resulting damage from trying to fix the bug can be more intimidating than the actual problem itself. Very often it depends on the situation, but often you can run into scenarios like the following person did:
“Imagine we have a user story that is closed (feature complete, acceptance passed, etc…) some time ago, say, several sprints ago, Then we find a bug that is closely related to said user story. [The] bug needs fixing, obviously.
Do you open that user story, including the bug found and related tasks, create a new one for bug fixing, or something else?”
Problems like this can puzzle anyone, as seen by the above comment. Bugs are a tricky issue, and not everyone knows how to properly handle them. However, a few experts have weighed in to give their advice on how the best way to save the full story.
The main piece of advice to focus on is NOT to open the story back up, as there is no real value in opening the story up; it is better to fix the bug directly rather than try to reopen the story. Also, one should create a new item in the product backlog, saved as a product backlog item (PBI), which shows the product owner where the problems occurred in development, and what should be done in the future to handle such bugs in the future. Also, any bugs in the development of the product should be mentioned to the development team to avoid mistakes in the future.
There is also the issue that creating a new user story can cause too much confusion if you create a new story every time you fix a bug. In order to make sure the backlog does not get clogged with entries every time you make a new story, it is better to do one of two things: either create a new series of new user stories and link them all together, or don’t create a story and just anonymously fix the bug without adding it to the log.
With the second method there can be serious problems; if there is no log that the bug was fixed, there is a chance in the future that if another bug led to that problem in the first place it will cause real damage to the system later on, and you will never know what caused that damage unless you have a great memory for everything that you changed. So, it is probably better to make a new entry every time that you have a bug, and link all of those entries together to make sure that the entries are both easy-to-find and contain a complete record of all the maintenance that was done to the story.
One thing has to be made clear from the beginning: there WILL be bugs when you develop software. It just happens, because no programmer or development team has ever made a perfect product. However, there has to be a way to quickly fix bugs that do happen, and often quick, logged edits are the best way to fix those problems. Also, the analysis about WHY the bug happened in the first place is as a good a use of time a fixing the bug itself. The more the team studies what bugs did happen, the less likely they are to make the same mistake in the future.
So what should you take away from this about how to handle opening up the story if a bug is found? Here are the steps that you need to take if a bug is found:
- Expect that bugs WILL be found
- When a bug is found, do not open the user story. Fix the bug, and save the edits as a PBI.
- Keep looking for bugs, and fix as necessary.
- Review any found bugs with the team to prevent mistakes in the future.
Opening the user story back up is rarely a good use of time, but saving the progress is essential to a good product. The keys to a good product are few bugs which are fixed as they are found, and reviewing all the findings with the team to prevent such bugs in the future. Once you fix and review, fix and review, over and over again, you’ll have a product that is the best you can make it!