Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Agile Methodology

Last post 01:00 pm December 1, 2015 by Ravi Landu
5 replies
11:06 am July 22, 2014

Hello all,

I am new to Agile methodology. We have planned for 4 sprints for the completion of our project. We are currently in the 3rd sprint. Currently our customer wants us to implement a small sprint of 10 days at the end of 3rd sprint in which we can solve the bugs that arises from the previous sprint. Please let me know if this approach is right or wrong ?

Thanks & Regards,
Narayanan K


02:28 pm July 22, 2014

What agile "methodology" is your question about ... many use the term srpints now.

Is your customer the Scrum Master for your project , why would you change sprint durations, why do you need a sprint just for bugs, ?

Forum / Scrum.org
Discuss issues relating to Scrum.org including assessments, programs, classes, and any other aspect of the organization


07:18 pm July 23, 2014

How long are your sprints typically?

One of the big things with Scrum is consistent sprint length, so I would recommend against executing a shorter sprint.

As far as bug fixes go, my team typically builds them into our sprints. For example, each sprint we'll have one or more stories that are bug fixes. We treat those just like any other story, we point them, and plan them during sprint planning. I'd try to advise your customer that you can keep the same sprint duration, and still work on the bug fixes. Of course, they wouldn't see the results until the end of the sprint (which may be what their concern is, they want the bug fixes asap).


09:53 pm August 1, 2014

Are you looking in to the root cause of the bugs? Each Sprint should deliver a slice (increment) of code that is potentially releasable - meaning it has been tested in isolation and tested integrated in with the app. Hopefully these bugs weren't "happy path" bugs which should have been caught using the Acceptance Criteria.


06:02 am August 4, 2014

Please let me know if this approach is right or wrong ?

To be clear, it is wrong. Your increment is not potentially shippable, which means either your team does not fulfill the definition of done or the definition of done is not complete. What your customer thinks is, that you are doing a project and there is a stabilisation phase in the end. This almost never works. What you really can do:
1. find the root causes of the bugs and eliminate them by adjusting the definition of done and enforce it as the law. From remote, my first guess is do excessive testing within the sprint.
2. Maybe you can reduce sprint length generally, so your client does not have to wait that long. This is up to you.


01:00 pm December 1, 2015

Few of points to be noted here:
1. In Scrum, the Sprint duration should NOT change. If it changes, then it would become difficult to calculate/predict the velocity.
2. The customer needs to be educated about Agile and Scrum
3. The bug fixes also can add as increment. It is basically clearing the debt. The sprint end deliverable will be the functionalities with bugs fixed. Meaning, some functionality which was not working earlier is now fixed and delivered.
4. The bugs need to be prioritized before they can be taken for fixing.
5. If the number of bugs are too many to fix in a sprint, then pick only the top few prioritized defects.