3

Say the product backlog has 90 stories and about 30 stories which make part of functionality of the application is developed and delivered during previous sprints. The PO choose to release this delivered functionality and put it in production.
Currently, I am at sprint 6 and the sprint duration is 3 weeks. The sprint has started with about 5 stories as it's sprint backlog items and by now one week of the sprint has passed.

Now the PO discovers a production bug or an important functionality that needs to be added on the production application on top priority. The estimate for this fix or functionality is just few story points that can be delivered in few hours based on teams velocity.

By now hopefully you see the situation the PO is in. Even if the development team (as only DT can modify the sprint backlog not the PO) is willing to take this fix/functionality in to there sprint backlog, the delivery of it will take another 2 weeks (as only one week of the 3 weeks of sprint has passed) and the PO can not wait that long.

What can the PO do in this situation.
1) Can he initiate another new Sprint that lasts only few hours or at most for a day (I would like to call this micro sprints). So here part of the question - Can sprints last for few hours or for a day or two at most. (from what i have read any where, the shortest sprint duration's I have read or heard is of 1 week) So I have this doubt, is it possible to have short sprints of few hours or a day and are they valid and acceptable in scrum.
2) what do you suggestion on how the PO should handle this top priority and urgent fix/functionality that needs immediate delivery.

Note: every thing on the project should be done through a formal scrum process only.

Improve this question
4
  • No. Sprints must always schedule the same size for a time box. However, you can abort your current Sprint and start a new 3-week Sprint at the PO's discretion.
    – Todd A. Jacobs ♦
    Sep 7, 2017 at 5:51
  • thanks for the "No. Sprints must always schedule the same size for a time box." clarification. But by cancelling the ongoing sprint and starting another 3 week sprint the problem still won't resolve as the PO wants an immediate delivery of the critical fix/functionality which he knows will take only few hours. He can't wait for 3 weeks for a few hours work. So what best do he do. Kempeth answer add's clarification unless you wan't to point to a different approach.
    – samshers
    Sep 7, 2017 at 7:37
  • The Scrum Guide
    – Alan Larimer
    Oct 3, 2017 at 17:55
  • Sprints must always schedule the same size for a time box is problematic grammatically and incorrect. A Sprint is a time-box. Though recommended, Sprint length is not required to be consistent. Because A new Sprint starts immediately after the conclusion of the previous Sprint the next does not start at the PO's discretion.
    – Alan Larimer
    Jan 27, 2018 at 3:20

6 Answers 6

Reset to default
8

Great answers above.

But I'll add ... Take some time with the PO & DT to discuss Production Bug fixes and try to have a policy in place so your team will have a better understanding of Scrum Vs Emergency fixes.

Usually teams adopt a ... "If it's that important ... Fix it, deploy it, return to sprint tasks" methodology.

Then watch out for PO's sneaking change in as emergencies when in fact they are just missed requirements.

Good Luck!

Improve this answer
3
  • "If it's that important ... Fix it, deploy it, return to sprint tasks" . Gr8 I really agree. This way I don't have to interrupt the spring backlog and need not worry about regression's due to new functionallity added to the product.. which might not be required on the fixed version of product. Now what do I call this delivery mechanism... another short sprint.
    – samshers
    Sep 7, 2017 at 9:45
  • +1 for keeping vigilant. I considered mentioning that in my answer.
    – Kempeth
    Sep 7, 2017 at 10:47
  • Its a swarm ... you swarm issues... but its not a sprint within a sprint .. thats a "No No"
    – Andy L
    Sep 7, 2017 at 13:04
7

Scrum is vehicle to get to your destination faster and more comfortably. Not a club to beat each other over the head...

There is nothing in Scrum stopping you from renegotiating the scope of this sprint or releasing a new version during the sprint. SCRUM only says that sprints should be short enough that usually this kind of thing is not necessary (Ie. the PO can wait for the next sprint for everything that comes up). But the whole point of agile is that you can adapt to changing circumstances. Also Scrum doesn't say you can only deliver at the end of the sprint, but that you should be able to release at the end of the sprint.

If the impact of the bug or missing functionality is as big as the PO says then you should address this immediately and push out a new version within the sprint. You should also use your next retrospective to address how it was possible to miss this issue.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Improve this answer
2
  • gr8, so how PO address this issue is by allowing the fix/functionality to be added to ongoing sprint with the DT's acceptance. Then let DT fix or add the functionality. And once done instead of waiting for the end of the sprint, the PO can accept the working software during sprint and release it.
    – samshers
    Sep 7, 2017 at 7:24
  • 2
    Nothing in Scrum prevents you from releasing daily or even hourly (or whenever) if you want.
    – vvmann
    Sep 7, 2017 at 10:43
1

I've seen people add an emergency lane to their Kanban board - and those tickets get priority.

This prevents breaking the Kanban concept - but, as Kempeth already answered so eloquently, Project Management tools exist to facilitate (and hopefully speed up) the delivery process, in the ultimate hope of making the company rich. :-)

Treating PjM as immutable rules is silly, though you have to be careful that you don't have an unending list of "emergencies" that destroy the entire concept.

Improve this answer
1

I would say there are a few different things there to address.

The situation is different if it's a bug or a missing functonality. If it is a bug, look really into the scope and possible impact of it. The Product Owner should be able to really decide with common sense if this is something that can wait until the next sprint. Usually it can. And if not, the approach should probably be: fix it, go back to the sprint and take this into account when the Scrum Team inspects that sprint in the retrospective and talk about how to improve so that doesn't hapend many times in the future. For example: Did the team have a Definition of done? Did the development deployed pass the Definition of done "checklist"?

If it is a missing functionality, negotiate with the Development Team. It is important not to change the scope of a Sprint because you are afecting your Sprint Goal. If it is hust a few hours of work, probably they can agree to work on it. But again, talk about this in the retrospective and try to analyze why a functionality, that seams to be some missing requirement suddenly appears in a such urgent way that can't wait for the next sprint.

Abou deployments, Scrum says you should have a product increment at the end of the sprint. It doesn't say you have to deploy functionality just at the end of the sprint. You can have as many deploys as you want, need or can do during a sprint.

Improve this answer
0

Many ways to deal with this but in my opinion, the following two are the most sustainable:

  1. If the team's velocity is 50 stories, go into the sprint with 35 stories. Leaving 15 for bug fixed and/or continuous improvement/learning.
  2. Shorten the sprint as much as possible. There is no point in distracting the team with bugs. Majority of bugs will be able to wait for the next sprint planning to get prioritized.

Obviously, the longer term goal should be to minimize bugs by introducing practices that promote quality. If you do have a large % of effort going towards bugs, then the above will be helpful.

After doing everything, production show stoppers may still seldom appear. My approach to that is stop the whole team, fix it, move on.

Improve this answer
0

What we do at the moment.

We have a sprint planned which consist of 2 parts.

  • new development (70%)
  • Fixing bugs/incidents/production on fire

With this proposition you take into account the time to fix bugs. You don't fix them all in one sprint, but you just take a continuous approach to that. When the PO has a very high production issue, it goes into account of the bug time. That way the new development doesn't stall and you can fix the production issue.

This is a situation in where the product is live and we have a lot of bugs (bought the damn thing fixed price). It works fairly well for us.

Be aware of calling this little sprints or so. If this is really a problem, perhaps take a little while shorter sprints. 1 (or max 2) weeks. That way you can also deliver faster those pesky production issues

Improve this answer
1
  • With this approach, the root issue of quality is not being addressed.
    – Alan Larimer
    Jan 27, 2018 at 3:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.