4

We have a project that is reaching a deadline for the final production release. It's a fixed price project and up till now we've managed to work in 2 week iterations, doing regular releases to our "inner test environment" where BAs and people acting as POs from the client's side had a chance to have a look, give feedback etc.

We're now at the point where we have only 4 weeks to end this project and as we go to deploy the separate modules of this application to the client's environment, we've been struggling with a lot of bugs appearing.

We have some functionality to be done still but my question is - what is the best way to handle those bugs as they appear?

Since theres really a lot of them; due to project specifics, we didn't have the ability to test it on client's environment earlier. It is impossible to estimate them up front + we have only 4 weeks till the end, does it make sense to keep Scrum or switch to Tech Lead dispatching work daily to the devs directly?

Improve this question

4 Answers 4

Reset to default
8

It sounds like you haven't really been doing Scrum, or at least, environment in which you're developing is not best for it.

Scrum has the concept of "Potentially Shippable", that is, your product could be released at the end of any Sprint. You have not been following that practice.

Scrum also focuses on developing products, not component teams. Scrum expects the team to work end-to-end. By saving up integration till the end, you've introduced a massive amount of risk. You can not deliver any value until you have integrated. In Scrum, you should prefer to do this continuously (i.e. every Sprint).

Since you have a list of bugs and four weeks to do it, then you should probably just fix as many bugs as you can in four weeks. I'd suggest you keep the list prioritized and just let developers pick the most important bug until they're done. There would be very little value in actually trying to do Scrum at this stage. Just keep things simple.

Not much else you can do. You're paying the price for diverging from the process.

Improve this answer
1
  • This is the right answer. You haven't been following Scrum sufficiently, so now the only option really is to list the bugs and let the PO decide on priority.
    – Morten Kirsbo
    Jun 26, 2014 at 20:22
3

Well, you problem is "solved" already, but maybe this helps someone else. Scrum requires "definition of done" be applicable for each story. In my opinion, those definitions should include:

  • Update of documentation (test procedures, system documentation; but manuals should be written after development)
  • Formal testing including test reports.

This usually results in higher estimates regarding story points but is (again IMHO) the only way to be (almost) all-the-time deployable.

For your problem:

  1. Stop development of new functions. If you keep going as usual, this will just result in new bugs.
  2. Prioritize the bug list together with some of your user experts / representatives from show-stopper to nice-to-have.
  3. Start with twice-a-week bug sessions, discussion progress, supporting activities, possible solutions, etc. for the top bugs.
Improve this answer
1
  • 1
    Hello and welcome to Project Management SE. Thanks for writing a great first post. I edited a bit to clean up the formatting, as well as some spelling and grammar so this will indeed be useful to future visitors. Keep in mind no question is really solved here, and you're always free to add a better answer at any time. Thanks for participating.
    – jmort253
    Jun 25, 2014 at 5:41
2

The possible changes I can recommend you to implement based on my experience from similar situations:

  1. Changing 2-week sprints to 1-week sprints to allow the team to faster handle the feedback from the customer
  2. Create a user story for bug handling and add bugs as subtasks ( estimate the user story the same way as any other user story )
  3. If there are A LOT of bug reports, create a separate Kanban board for those reports and set a time limit for each sprint, which can be used to work on Kanban tasks.
  4. If your priority is fully on fixing bugs, then switch fully to Kanban

In my experience it is likely that to the end of a project there would be more bug reports, no matter how perfectly polished is your Scrum process.

Improve this answer
0

I would mostly agree with the above, with two small suggestions

1) You shouldn't feel terrible about yourself because you need a hardening sprint or two - these should be a great opportunity for retrospective cycles to help you understand ways of getting quality up in each sprint (one thing that leaps to mind is to spend time in future projects more closely replicating the client's system if possible)

2) I wouldn't say you need to abandon all of scrum's rituals in order to complete your work - just take the ones that you can continue to use and explain why you're keeping them. Example - daily standups are still a good way to ensure that the work the team is taking on is the most valuable - it may be that the tech lead acts more as the product owner and the "sprints" are one day long, but you can keep that cadence and practice intact. I'm sure there are other parts of your scrum implementation that still apply.

In order to not confuse, would that I were to go this route I would be explicit that we are taking some good practices and NOT modifying our implementation of Scrum. Explaining how you're thinking about what's good practice and why the combination falls short of Scrum is another place to guide understanding of the framework - never waste a teachable moment!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.