-2

let me paint for you the scenario in question:

I'm working through my weekly sprint using Trello. My board:

My board

is up-to-date. Alas! Here comes a new business-critical feature requirement (e.g. Dancing hamster animation). I'm only 2 days into my sprint! Which of these options do I do!?

  1. drop what I'm doing, add Critical feature to sprint and start working on it immediately
  2. drop what I'm doing and make room for new Critical feature by moving other cards (aka pieces of work) into next week's sprint. Start working on critical feature.
  3. tell the product owner that my sprint is locked and I'll add it to my next sprint
  4. exclaim "Hey! where's my scrum master, he's supposed to shield me from this!" (This is a joke, we are 3 developers and don't have a scrum master).

Currently we implement option 2. This way the sprint remains a manageable unit of work, with a defined release date. After the sprint has finished we (the dev team) will review the sprint and follow up with the business team to see if we can avoid this situation going forwards.

Which option "is the best" or do most people recommend? I know it depends on your implementation of agile and kanban and scrum and all that but I'm looking for the best way for us to handle sprint modifications.

Please be gentle, we're learning agile methodologies. Please don't be overly dogmatic since this approach is called "agile" - not everyone has to do it in the same way.

Many thanks!

sming
  • 801
  • 2
  • 12
  • 25
  • 1
    I'm voting to close this question as off-topic because it would be better on [Programmers Stack Exchange](//programmers.stackexchange.com). – Toby Speight Jan 19 '16 at 17:12
  • 1
    This question is technically on-topic at Programmers (browse the [agile tag](http://programmers.stackexchange.com/questions/tagged/agile) for similar questions), but if asked there would require specific success criteria other than "what is best?" We need requirements such as "we are trying to achieve X, which option will do that?" As it is written, this question would be closed as "primarily opinion-based." Related reading: [On discussions and why they don't make good questions](http://meta.programmers.stackexchange.com/q/6742). –  Jan 19 '16 at 17:16
  • I appreciate the guidance chaps and/or chapettes. Would a subject such as "Is modifying an in-progress Sprint correct?" be better? Also, what's the best way to move this question to [Programmers Stack Exchange](http://programmers.stackexchange.com)? Thanks again. – sming Jan 19 '16 at 21:02

2 Answers2

2

This is going to be highly opinionated, but #2 is what I end up doing most of the time. However, it also depends on your release cycle. If you're releasing at the end of the sprint and need this in, then it takes precedence over what was already scheduled.

Scrum idealists will say #3 is the right answer. It's not the wrong answer, but it also negatively impacts your working capabilities w/ the product owner.

John Ament
  • 11,595
  • 1
  • 36
  • 45
  • 1
    I am what you might describe as a 'Scrum idealist' and I would never refuse to do a business-critical story requested by the Product Owner. In fact, I can't think of an agile coach or Scrum Master I know who would do this. – Barnaby Golden Jan 19 '16 at 15:15
  • glad to hear, Barnaby. A previous workplace of mine rigidly adopted agile with disturbing zeal. Not much fun and I'm not sure it was that helpful as a result. – sming Jan 19 '16 at 21:57
1

Scrum is a team activity. The delivery team works with the Product Owner to deliver maximum value to the organisation as effectively as possible.

If the Product Owner wishes to introduce a business-critical feature to a sprint then the delivery team will usually work together with them to make it happen. However, a number of things need to be kept in mind:

  • Is the newly introduced story ready to be introduced to the sprint? Are there any unknowns about the work? Is there any preperation needed before the work is started?
  • Will the newly introduced story significantly impact on the planning for the sprint? If it will, it may well be worth the Product Owner aborting the sprint and calling a new planning meeting. This isn't ideal, but it can and does happen (particularly with organisations new to Scrum).
  • The impact of the late change to requirements should be raised as a discussion at the team's retrospective. Is there anything that can be done to avoid this situation happening in the future? Perhaps the sprint length is too long to accomodate the rate of change in the organisation?
Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28
  • thanks Barnaby, excellent points. I forgot to mention that we discuss sprint modifications in the subsequent sprint review to see if anything can be learned prevention-wise. I also forgot to add "Abort sprint" as an option. It's a bit drastic but we've done it in the past. Thanks again! – sming Jan 19 '16 at 20:56