Production hotfixes and Scrum

I would prefer to start with X amount buffer per sprint for hot fixes and over a period of time you will get to know how much effort goes into these issues and team can adjust the commitment accordingly. This will ensure the transparency too.

I am assuming that team is estimating the hot fixes in story points as soon as they are coming into sprint backlog.

Cheers
Sanjay

Posted By Franck van der Sluijs on 07 Apr 2014 05:40 AM
Of course our sprints have to be result in shippable software, but we are just started using Scrum and I believe even when using Scrum production bugs will always exists.

Hi Franck,
this sounds to me as if you do not believe in the team's ability to ever deliver a shippable increment.
I agree with you that software is never bugfree. However, the increment has to be in sufficient quality for production. If it is not, the solution is not a bugfix release (just a workaround), but process improvement.
Try to figure out with your team what you can improve in your process so the critical bugs which are not accepted in production do not emerge. You will see that building and deploying bugfix releases is pure waste.

Posted By Ludwig on 07 Apr 2014 10:07 AM

Posted By Franck van der Sluijs on 07 Apr 2014 05:40 AM
Of course our sprints have to be result in shippable software, but we are just started using Scrum and I believe even when using Scrum production bugs will always exists.

Hi Franck,
this sounds to me as if you do not believe in the team's ability to ever deliver a shippable increment.
I agree with you that software is never bugfree. However, the increment has to be in sufficient quality for production. If it is not, the solution is not a bugfix release (just a workaround), but process improvement.
Try to figure out with your team what you can improve in your process so the critical bugs which are not accepted in production do not emerge. You will see that building and deploying bugfix releases is pure waste.

I agree, but my question is how to deal with our current situation. We are using Scrum since a few weeks, but our product exists many years.

We are not building a new product but we are maintaining an existing product. Every release contains bug fixes and new features. Sometimes a bug fix can’t wait for the next release. That’s what we name a “Hotfix”. The discussion within my company is how to handle these hotfixes (not how to prevent making bugs).

I believe when we improve the process we create less bugs and less hotfixes are needed. But for now we have to deal with the current situation.

OK I understand. So maybe it is really an option to include an item "Bugfix release" in each planning, because you already know you will need it. You just don't know yet which bugs are included and when it is needed.
Another option is to play the "more is learned" card within the sprint and to re-negotiate the sprint backlog between PO and the dev team. This option is reasonable if the need is expected to arise in rare cases only, because it can be abused by the PO for quick changes. It is important he understands the consequences to productivity.

Hi Franck,

when we or someone else discover a bug, first we talk to Product Owner if it's hot or not.

If it isn't hot, we will add on the top on our backlog to deal with it during next sprint (or later).

If it's hot and we have to work on it immediately, we'll move the UserStory(-ies) from the backlog to the Corner of Hope (agreed with PO of course) and assign one or more people (or only for % of his/her time) to work on a bug depends on PO's decision how sever the glitch is.

The problem is a bit more complicated, because usually it's impossible to estimate bugs.

BR,
Bartek

Posted By Xebord on 07 Apr 2014 03:37 PM
when we or someone else discover a bug, first we talk to Product Owner if it's hot or not.

If it isn't hot, we will add on the top on our backlog to deal with it during next sprint (or later).

If it's hot and we have to work on it immediately, we'll move the UserStory(-ies) from the backlog to the Corner of Hope (agreed with PO of course) and assign one or more people (or only for % of his/her time) to work on a bug depends on PO's decision how sever the glitch is.

The problem is a bit more complicated, because usually it's impossible to estimate bugs.

Thanks for the reply. What’s the “Corner of Hope”, is that part of the current sprint backlog? Or is that a separate list?

The "Corner of Hope" is a part of the current sprint backlog where are stored User Stores which the dev team would like to finish, but they are not promised to do it. Hence there is no problem, if the team doesn't complete them.

So if the new fault is found and needs to be solved immediately with already defined backlog, the team has to removed the lowest priority US to make space for the fault. But instead of removing it for the backlog completely, put it in to COH.

Hence the team is sending the message to PO: we are going to work on the fault, we have to move some USs to COH, but still we will try to finish them.


BR,
Bartek

I don't believe in the "buffer" or "separate list" strategies.

My preferred method is to do this: http://www.ScrumCrazy.com/bugs

A "shorter method" ..."If it's an business emergency, do it now, and then adjust sprint scope based on the impact." ... "Not a biz emergency, goes on the PBL and ordered by the PO just like any other PBI"

Posted By Charles Bradley on 08 Apr 2014 03:13 PM
I don't believe in the "buffer" or "separate list" strategies.

My preferred method is to do this: http://www.ScrumCrazy.com/bugs

A "shorter method" ..."If it's an business emergency, do it now, and then adjust sprint scope based on the impact." ... "Not a biz emergency, goes on the PBL and ordered by the PO just like any other PBI"

Nice bug chart, thanks!

Franck, great, hope it helps!

In Lean theory, a case can be made for immediately dropping all Work In Progress and fixing a defect regardless of how trivial it may be. This is because the process evidently needs to be fixed even if the product itself is not (yet) seriously compromised. After all, deferring a minor fix doesn't just mean deferring the release of a more valuable product. It also means allowing a faulty process to continue at the risk of potentially introducing more serious defects, and compounding the waste incurred, due to the shortcoming not being addressed.

Well that's the theory. In Scrum practice however, this risk of continuing with a broken process needs to be weighed against the risk of not delivering a Sprint increment at all. The management of risk, just like the delivery of scope, is time-boxed in Scrum. That's why it's important to have a strategy like Charles' for triaging defects into or out of the current Sprint, and for revising the sprint forecast if necessary. The worst thing is not to have a strategy at all.

> The "Corner of Hope" is a part of the current
> sprint backlog where are stored User Stores
> which the dev team would like to finish, but
> they are not promised to do it.

Just out of interest, what does that make the remaining stories? The Backlog of Despair?

> The Backlog of Despair?

:-DDDD

but it sounds you are a bit sceptical, doesn't it?

If so, could you elaborate a bit?

BR,
Bartek

Hi Charles,

nice chart, it's good that it focuses on fixing the bug.

Let me please summarize it: if it's severe bug, fix it now. If not, fix it later. Right?

But what about sprint goal? And the current User Stories? It's not covered by the chart.

Let's assume that the bug appears at the beginning of the sprint and it takes half of the sprint to solve it . What next? Cancelling the sprint?

I don't understand, why do you suggest not to track the bug (3A)?


BR,
Bartek

Your summary is decent, but it skips a whole bunch of other stuff about whether things go on the PBL, the SBL, or not tracked.

Sprint goal not mentioned by the chart, agreed, not meant to. If you have a biz emergency, I would expect that the SG would no longer be nearly as important. (not to mention Scrum)

Re the current PBI's, see the bubble with the asterisk(*)

Re: 3A -- if the issue is very small (immaterial/tiny, etc), then the time spent to track it is not nearly as important as just fixing it. This is to prevent us from getting caught up in red tape and paperwork waste. Much important to just fix it!

Also re: 3A ... More value in "responding to change" over "following a plan"... and more value in "working software" over "comprehensive documentation.