Skip to main content

SCRUM during support phase (Only bug fixing is remaining) ??

Last post 09:13 am March 1, 2019 by vishal Rajadhyaksha
4 replies
11:15 am February 28, 2019

I met one scrum master colleague recently and when we were discussing about scum implementation in his project he pointed out that all ceremonies are not required when your delivery is over and only bug fixing is pending.

According to him, Sprint planning meeting, retrospective, backlog refinement meeting become useless and Only daily standup and review meeting they are conducting in his project and he faced no issues with it. His team could fix all bugs in timely manner without the need of this meeting.

I had never been through this experience as we never came across a situation when our delivery is over.  So, I don't have strong opinion on it. 

I know, Scrum guide says, you can partially implement the scrum but then don't call it scrum. So, I would like to know your views. Can we simply keep aside scrum when only job left is bug fixing ? 

 


01:04 pm February 28, 2019

If bug fixing is pending, then delivery is not over. There is a continuing need to inspect and adapt both product and process, so quality can be improved. Is the elimination of certain Scrum Events likely to help with this?


03:28 pm February 28, 2019

I met one scrum master colleague recently and when we were discussing about scum implementation in his project he pointed out that all ceremonies are not required when your delivery is over and only bug fixing is pending.

Best advice you can return is to suggest further review of the Guide, as a starting point :) Ask them to provide their rationale and arguments as to why they believe so. 

According to him, Sprint planning meeting, retrospective, backlog refinement meeting become useless and Only daily standup and review meeting they are conducting in his project and he faced no issues with it. His team could fix all bugs in timely manner without the need of this meeting.

How come? Is "bug fix" not work? Do code errors, for instance, fix itselves without human interaction (no AI atm)? As long as the team works in accordance with Scrum, then the basic (lightweight) framework should be used as indicated. Don't fall into a "ScrumBut" scenario.

As to "His team could fix all bugs in timely manner" this somewhat reminds me of that [long-established] approach according to which [X] has to (and can) be delivered on time, budget and exactly as requested. How can they be so sure the team is able to fix all bugs in a timely manner? :)


03:51 pm February 28, 2019

I think we can agree that Scrum is about delivering incremental value.   Lets consider a normal user story.  Does it have value?  Actually is has 2 values. Negative until is implemented because it indicates something that is needed but not delivered and positive after it is implemented as it provides additional value. So let's consider a bug/defect.  Does it have value?  Actually it has 2 values.  Negative value as long as it exists and positive value when it is rectified.  In fact the value statement I made for a story applies to bugs as well. 

So, what is the real difference between a bug and a user story?  In my opinion there is none.  Each one should be considered equally by the Product Owner and ordered appropriately.  The Scrum Team should treat them all equal for the sake of refinement, Sprint Planning, Spring Review.  And as long as the Scrum Team is still doing Scrum, then Retrospectives are needed to inspect the working relationship of the team. 

In my coaching, I encourage my teams to create only one type of item in the Product Backlog.  Everything is a story they just tell different opportunities to deliver value. 


09:13 am March 1, 2019

Thank you Ian, Eugene and Daniel for your clarifixation regarding this doubt. Highly appreciate your valuable time. 


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.