SCRUM during support phase (Only bug fixing is remaining) ??
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 ?
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?
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? :)
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.
Thank you Ian, Eugene and Daniel for your clarifixation regarding this doubt. Highly appreciate your valuable time.