Sunday, January 8, 2012

Accomodate Bug fixing in a scrum sprint- (Scrum or Kanban)

A scrum sprint entirely devoted to bug fixing is very bad. But such situations are not very rare.

Scrum works perfectly with known feature deployment. Bug fixing works better with kanban. Bugs are unknown entity; unless team do some sort of exploration/spike work, they cannot commit on it.  

We have adopted a mix of Scrum/Kanban model for fixing bugs.
One of my team is in maintenance. During sprint planning we decide on the priority of the bugs and timebox all the issues based on the teams capacity. During the daily scrum meeting we discuss about the progress made. If the issue is critical, an update is send to the entire team every four hours. If any new issues are reported in between, PO prioritizes that and if it is the highest priority, team stops the work on the current bug and starts fixing the new issue. We encourage multiple people to work on the bugs. Once the top priority bugs are fixed, team moves to the next item in the backlog. If we take more time to fix than the anticipated timebox we inform the PO. Based on the discussion team will continue working on the exiting bug or work on a new higher prioritized bug.

Read the following also

Scrum : Non functional requirements testing in scrum sprint

The NFR’s and technical requirements should be part of the user story. These can be added as constraints to the story or along with the definition of “done”. Most of these NFR’s can be tested with unit test framework or automated test scripts. Sometimes the process cannot be tested directly. Suppose software requires triple encryption of bank transactions or such things then it will be very difficult to check the state in between. You will have to test the results to verify the process. The ticket generation or the account balance after the transaction will give a correct picture. Performance testing can be integrated with Continuous integrations build or nightly builds.