| Context | A bug has been reported. |
| Problem | If this is a bug, when should it be fixed? First, changes and bugs need to be separated. If a web site does not look like the Product Owner likes it to be but the corresponding requirements have been fulfilled by the Development Team, it is no bug. Another issue are bug tracking systems which get fileld up by bugs over bugs, because new feature are more important to the client side than fixing bugs. |
| Forces | too little/too much focus on new functionality |
| Solution | Fix small and medium-sized bugs as well as critical bugs immediately, everything else goes into the Product Backlog. Everything which is no bug, has to be moved to the Product Backlog, otherwise there is a shortcut into the Sprint to add requirements outside a Sprint Planning I meeting and without the Development Team requesting more work. To avoid an ever-increasing queue of bugs, it is important to get them out of the way asap. Small and medium bugs can be fixed within the Sprint, but the Development Team needs to but aside a certain amount of time for fixing these categories of bugs when committing on Selected Backlog. Critical bugs need to be adressed immediately anyway. But all other bugs can be managed using the Product Backlog. This ensures that they are fixed according to their business value. |
| Resulting Context | The bug will either been fixed immediately or it will be moved to the Product Backlog for the next Sprint. |
Dieser Artikel wurde von Andreas Heilwagen am 12.05.2011 um 07:19 gepostet und unter Scrum eingeordnet. Sie können Kommentaren über den RSS 2.0-Feed folgen. Das Posting steht unter der Creative Commons-Lizenz wenn nicht anders vermerkt.
