Archive for February, 2008

What do you do with bugs that you find in a sprint?

February 2, 2008

What do you do with bugs that you find in a sprint?

For those who are not familiar with an Agile software development processs, a sprint (or iteration) is an interval of time during which developers create the next set of deliverables.  A sprint is usually one to four weeks long.  At the end of the sprint, the deliverables are usually code that is ready for deployment.  In some cases for complex systems, it means that the code is production ready and can be tested (though it may not be ready for deployment because of other undeveloped pieces).

As we test during a sprint, the question often comes up, “Where do we put the bugs?”  That is, do we deal with them immediately, deal with them sometime during the sprint, or schedule them for a future sprint.  The answer, as usual, depends on several things.  If we find bugs in the functionality of the current sprint, then they are put on cards with “BUG” in big red letters and the card is placed in the column of work for the current sprint.  If possible, the testers develop automated tests to verify the bug is fixed and as  furture regression tests.  Any bugs that remain at the end of the sprint are entered into a bug tracking system so they will not be lost.  The card goes in the backlog for the next sprint and is prioritized by the customer with all the other cards in the backlog.

If the bug that is found is in legacy code, the bug is entered into a bug tracking system so that it will not be lost and it will be prioritized with other work for future sprints unless the functionality for the current sprint depends on getting this bug fixed.  In this case there will probably have to be an evaluation to see if the bug can be fixed in the sprint and the other work completed too.

Usually before there is a release there is a sprint that is devoted to bug fixing, practice deployments, and the actual deployment.  I have found it very useful to write the remaining bugs that must be fixed before the release on a whiteboard during one of these sprints.  All the bugs that have to be fixed before release and the top like-to-fix if there is time bugs, go on whiteboards.  In addition, I include tasks like practice deployments and release reviews too.  Any new bugs that are found during this sprint are added to the whiteboard.  A developer puts their initials next to one when they start working on it.  When they think they have fixed it, they write RTT by it (Ready To Test) along with the date and time.  If it passes testing, the tester writes “Done” next to it.  At the beginning of the next day, all the bugs that are “Done” are erased off the white board.  I believe this helps put all the work that needs to be done for the release out in front of everybody.  Instead of erasing the bugs that are fixed, you can simply draw a line through them if you want them to stay up for reference.  Personally, I like to erase them.  It gives more of a sense of progress as the white boards that were full of bugs turn more and more white.

I have used this at several different companies and it seems to work well when you are in a bug fix mode.  As with any Agile practice this should be adapted to your particular situation and culture.