preload
Sep 08

scrum sprint cycleThis is a follow up on a post I wrote earlier about how I like to use Scrum and ScrumWorks for my projects. After writing that post I have had some good discussions on how to manage bug fixing in a Scrum sprint. A good friend and former colleague of mine wrote a good post on how they achieve this in mBricks using JIRA and GreenHopper.

The last months I have been handling bug fixes and rapidly incoming change orders in ScrumWorks and this have been (in my opinion) a great success.

The first thing I did was to create two new releases in my uncommitted backlog. One called Bugfix and the other called ChangeOrder.

For each bug report I added the bug as a new backlog item under the Bugfix release and estimated it by detailing the backlog item with all tasks that needed to be done to fix the bug. When I added a new bug I also prioritized this bug against the already existing backlog items under the bugfix release.

By doing so you have control on all the reported bugs and you know the total amount of efforts it takes to fix all bugs.

For each change order I did the same as for bugs; added a new backlog item under the ChangeOrder release, detailed it with estimated tasks and prioritized it against the other existing backlog items. For change order the customer (Product owner) were involved in prioritizing the backlog items.

When planning a new sprint it is easy to drag the prioritized backlog items (from the Bugfix and ChangeOrder release) over to your sprint and commit to them.

If a critical high priority bug or change order is reported in the middle of a sprint you can re prioritize your sprint by committing to the new backlog item(s) and move already committed items out from the sprint and back to the uncommitted backlog.

I think this is a great way to handle bug fixes in Scrum and by using ScrumWorks I also feel that I have full control over the project.

I created a simple consept model showing how development, testing and bug fixing can be combined in Scrum.

Scrum and bugfix

Follow me on twitter @PerOla

Share & enjoy
You can subscribe to my comments feed to keep track of new comments.

7 Comments to “Including bug fixing in the Scrum sprint”

  1. Jason says:

    When do you test the bug fixes? Also, this timeline means that in Sprint #3, developers will be fixing bugs from Sprint #1, so fixes are applied to the code base tagged after Sprint #1?

  2. Hi Jason,

    Bugfixes is a part of the sprint deliveries so they will be tested as a part of the sprint test. I must add that this way of working is not suitable for all kind of projects since there is a few sprints lag from the bug is identified and until it is fixed and tested.

    This model would fit best in a larger project spanning over several sprints. The fixes are applied to the code base tagged with the sprint they are fixed in.

  3. Hi.

    it seems strange for me, or I misundetstood.
    Correct me please if I’m wrong:

    Perhaps it’s good approach for newbuilt projects.
    But if you already have production working server, and develop new features — it means
    that your critical bugfixes would be on production server only after 2 sprints! So customers will see your buggy tool during 2 sprints (4-6 weeks as you said)

    Any solutions for that?

  4. Melany says:

    Ok…..am I the only one that noticed THIS IS JUST WATERFALL?

    Agile is based on continuous delivery…you roll your review and bug fixing into each sprint. The model above just looks like phased waterfall for each feature…maybe you are just using Scrum to manage your tasks each week?

  5. This approach is suitable for larger projects that are not in production yet. I think it is important to differ between maintaining projects that are already in production and projects that are being developed.

  6. Hi Melany,

    I don’t consider this as a waterfall approach. I have defined a number of sprints, when to test sprint deliveries and how to handle bugs/issues found when testing.

    I have not defined what tasks should be placed in each sprint, this is done in sprint planing meetings before the sprint starts. This way it is handled in an agile way with continuous deliveries after each sprint.

  7. Grareme says:

    I agree with Per, this isnt water fall. It is only water fall if you assume that every user story results in a bug fix at a later stage. assuming a decent test system is in place user stories should not introduce bugs. The fact we address bugs as soon as they are raised to me shows this is not a water fall process where we would complete all user stories before doing any real testing, raise bugs, then spend months trying to fix them.

    This method of dealing with bugs early helps us to identify and correct defects far quicker as this is closer to the point of creation. The other reason for this is that the code is still fresh in the developers mind (or on longer term projects, it is more likely the developer responsible is still within the team).

    I have worked on previous projects where large numbers of bugs were being reported on an existing code base. In this case we decided to not use a traditional bug tracking tool and instead raise identifiable user stories (on yellow cards instead of white) and prioritized them in a similar to traditional bugs. In each sprint we would then take a mix of defects and new features.

    On another project a bug report would result in the suspension of all activities until the bug had been corrected (within reason). This was possible due to the use of a highly reliable and effective regression and CI system that allowed early identification of bugs and regressions.

No Pingbacks to “Including bug fixing in the Scrum sprint”

Leave a Reply

Subscribe to my comments feed

Subscribe to my feeds Follow me on Twitter
DZone MVB