Skip to main content

Do somebody apply scrum on Bug-fix project?

Last post 08:31 am September 26, 2013 by Chee-Hong Hsia
3 replies
05:18 am September 22, 2013

Hi,

I have a project which mission is to solve bugs in Phone system. The bugs are coming from Bug system everyday, my team mission is fixed them. Do somebody have experience to apply scrum method on this type project? How can I define Product backlog and sprint backlog?

Any Suggestion?

Thanks.

Duan


06:48 am September 22, 2013


Posted By magicduan on 22 Sep 2013 05:18 AM
Hi,

I have a project which mission is to solve bugs in Phone system. The bugs are coming from Bug system everyday, my team mission is fixed them. Do somebody have experience to apply scrum method on this type project? How can I define Product backlog and sprint backlog?

Any Suggestion?

Thanks.

Duan



Hi Duan,

What kind of bugs are we talking about? Operational bugs that randomly comes which makes the priority fluctuate, needs to be fixed and put in production a.s.a.p.?

If that is the case, perhaps you should check out Kan Ban?

It is not a good idea to use Scrum just for the sake of using Scrum. The goal is to be Agile and there are any other methodologies to enable Agility.

Cheers, Chee-Hong



07:36 am September 23, 2013

Using Scrum for everyday defect fixing implies that you have a Product Owner who can prioritize each of these defects on a backlog, and help the rest of the team plan them into a Sprint Backlog with a meaningful Sprint Goal.

Is that a realistic prospect in your situation? If not, you might want to consider Kanban as Chee-Hong suggests. In my experience, Kanban is well suited for Business As Usual (BAU) work such as templated changes and defect fixes. Scrum is well suited for project work where there is greater scope uncertainty to be de-risked, and where backlog items are more likely to align to Sprint Goals and the corresponding potential release of business value.


08:31 am September 26, 2013

I do strongly believe that once a team adapts Scrum to its fullest, Kan Ban is like the next step in terms of becoming Agile. I see that happening to the last couple of companies that I have been coaching. It is quite an interesting transformation from a organisational point of view.

Once the team starts deliver increments in a steady pace, has a stable velocity and product ownership has been applied correctly, the whole idea of a Sprint becomes more and more irrelevant. At some point, it is not about “which high value items can a team deliver in a Sprint” but more towards “which item has the highest value that can be delivered first”.

For me Kan Ban is like the next step in Agility, but unfortunately it’s not implementable for every situation. I’m just happy that I had the opportunity to coach these kind of transformations.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.