Micro sprints or extreme agile?

How do you commit to a sprint which only include bug fixes? Can you commit to solving bugs 35-69? This came up as a long discussion during the Friday sprint planning session. It after a while became clear that you cannot commit to a so long list for a so long time. So what we'll do is turn to very very short sprints. Every sprint will be just one day long (lunch-lunch). Every sprint will start with a quick sprint planning session when we create tasks for the bugs we commit to working on during the sprint. And then we get cracking. Parallel to the bug fixing, the test team will test the previous sprint increment to form a list of the most prioritized bugs for the upcoming sprint.

Of course we'll have problems with hard to solve bugs which takes more than a day to fix but we hope that this will be a method which works during this month. We will also need a very involved product owner who can work on the product backlog every day. If the sprints turn out to be too short, we can make them longer. But by working like this, the product owner can decide when he believe the product is as good as we want it and when we have a release candidate, which is the real objective of the sprint.

We'll start the new sprint length Wednesday lunch. Get back to you with the result.