Best way to modify my sprint

Question

let me paint for you the scenario in question:

I'm working through my weekly sprint using Trello. 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!

Answer 1

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.

Answer 2

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?