Short Term "Urgent" Features

Julien, there are several other factors to consider under your "hypothetical" situation:

• Why are requests to the team originating from someone other than the PO?   This doesn't involve an apparent lack of communication between this boss and the PO, but instead reflect an apparent inability by both the PO and the SM to protect the team from outside interference during the sprint
• One of the Agile Principles state "Agile processes promote sustainable development".   Team members working overtime to complete unplanned items is not a sustainable practice
• Why does this "boss" have a preference for working in a reactive manner, and not a proactive way?   What is the boss' understanding of Agile/Scrum?
• The Development Team should never have work pushed/forced to them.   The Development Team should only accommodate unplanned items if they have a high degree of certainty of completing them in the sprint, such unplanned work does not place the Sprint Goal in jeopardy, and the Development Team makes any needed adjustments to their Sprint Backlog / forecast to allow for the unplanned items

Hi Timothy, thank you very much for your input!

your "hypothetical" situation

I started my preparation for the PSM II and I am trying to think of scenarios that might be asked and that seem realistic. Let's be honest, high prio urgent features that occur during a sprint are indeed a real world scenario (e.g. a critical bug in production the tests did not cover).

I am aware of the fact that this interruption should be avoided by the SM to protect the team, nevertheless it is a situation that might occur. (having worked in a non-scrum environment as a service provider for customers I have sometimes made this experience on my own)

It is quite clear that the SM should find a way to avoid such situations in the future (e.g. increase the awareness on how scrum works, increasing the proactive acting, etc.)  and that something went wrong in the past.

I welcome your analysis of the situation, still I am missing a hint on what would be an appropriate measure to take. Even if the request would be directed to the PO, there would be some action to be taken.

Even if the request would be directed to the PO, there would be some action to be taken.

A Scrum Master is an agile coach to the team and also to the wider organization, including management. Might there be coaching opportunities to be followed up on?

The PO should be asked to prioritize the backlog more effectively going forward? - Yes.

The SM should step in and protect dev team since updating the sprint backlog regularly hurts team's morale? - Yes.

As Ian mentioned, there most certainly are coaching opportunities for the management. But all of that is secondary - first and most important step that we need to take in this scenario is - if dev team has capacity, and have not yet started working on some of the sprint goals (user stories) as planned earlier, they should accommodate these changes coming in and trade off (after clear discussion with PO) some goals from the current sprint backlog.

I believe that, in no scenario, should productivity and business value be impacted.

Might there be coaching opportunities to be followed up on?

@Ian Mitchell: I really like the coaching attitude which you use all over the forum to answer questions by asking counter-questions :)

• I completely agree with both of you that there would be definitely a need to increase Scrum awareness and knowledge by some coaching to the management.
• Also it is clear that the SM should take responsibility and act accordingly to protect the team from such interruptions.

What I really like about your answer @Adwait Vaidya that it does not only contain the long term approaches to prevent such scenarios in the future, but also an Idea on how to de-escalate the current situation (of course there is no generally applicable solution).

If the situation is an exception, would it be appropriate to completely cancel the sprint and replan another sprint including the needed changes?

The scrum guide states:

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

@Julien

Cancellation of a sprint should only be considered if the Sprint Goal no longer makes sense to pursue.   In my opinion, the attempt by management to introduce other items mid-sprint is an educational opportunity (Scrum and Lean concepts), but doesn't seem to render the Sprint Goal as something that no longer makes sense to pursue.   

Part of the "education" with management should be around patience and the benefit of being proactive instead of reactive.   Can their suddenly urgent items (unplanned, potentially brand new) wait until the end of the sprint in order to work on them properly and give the Development Team a much higher chance of success?

@Adwait

have not yet started working on some of the sprint goals (user stories) as planned earlier, they should accommodate these changes coming in and trade off (after clear discussion with PO) some goals from the current sprint backlog

I am assuming you meant sprint items, and not goals, since the Scrum Guide is very explicit that each sprint should have only one Sprint Goal?

Part of the "education" with management should be around patience and the benefit of being proactive instead of reactive.   Can their suddenly urgent items (unplanned, potentially brand new) wait until the end of the sprint in order to work on them properly and give the Development Team a much higher chance of success?

One of the Scrum Values is focus. When focus is missing, the chances of delivering the most valuable possible Increment are reduced. It can also be incredibly damaging for team morale.

If the Scrum Team and stakeholders were to focus on the most valuable thing, would they agree that it is the current Sprint Goal, or would it be something else? Usually, it should be the Sprint Goal, in which case extra work is a distraction, and should wait until the goal is achieved.

In exceptional circumstances, the Sprint Goal is no longer the most valuable thing. It may make sense to cancel the Sprint and set a better Sprint Goal. This might be the right decision, but it will come at a cost; as focus is automatically shifted, some work may need to be discarded, and in a lot of cases, the morale of the team will suffer.

@Timothy,

Yes - i meant items. :)

@Simon/All,

I have so far never had to face a situation where Sprint needs to be cancelled. Theoretically, yes - I understand that if sprint goal doesn't make sense we should cancel the sprint. Out of curiosity, if you guys have experienced and can share some real-life examples on why sprint was cancelled, that would be really helpful!

Cheers,

Adwait Vaidya.

Thank you all for your input. As expected there is of course no "one action fits all" approach. It is interesting to see the different possibilities that raised from the discussion!

Julien, given that "Your boss needs two unplanned features to be included in the current sprint" it is worth understing the current status of those features. Have they been properly discussed (groomed), have clear acceptance criteria, do they have estimates? If they are not ready for development from the DT's perspective, chances are they cannot be completed under the DoD standards and there are considerable risks of not only low quality or missing requirements, but also future impact (poor code quality > bugs); as such, they should not be included in the current sprint at all costs. Rather, the team should, as a good will gesture (given it's a repetitive issue), try to refine the features and see whether they can potentially complete one or both during sprint - but without endangering the sprint goal.

Which brings me to another point:

Timothy, you mentioned "the Scrum Guide is very explicit that each sprint should have only one Sprint Goal?". While the Scrum Guide words are clear to everyone, to my mind (and the way I've been practicing), the sprint goal can be both a single piece but also a collection of two or more individual pieces (objectives), which, combined, constitute the sprint goal. In fact, most of the sprint goals I've dealt with/encountered are multiple-piece rather than single-piece. Do you (or anybody else) practice otherwise - that is, sprint goal being a single piece?

to my mind (and the way I've been practicing), the sprint goal can be both a single piece but also a collection of two or more individual pieces (objectives), which, combined, constitute the sprint goal

Regardless of how many pieces there are, do they express a coherence, as described in the Scrum Guide?

I guess it depends how one interprets coherence (strictly or broadly).

In my current company, we provide a single product to different markets, each with its own characteristics (so the product is in fact tailored). The PO organizes the backlog depending on his understanding/knowledge of the market needs/changes, and during planning we may select different stories (ie 2 improvements for market A, 3 new features for market B - which can't be implemented for other markets, so are exclusive for B, etc) that address different business needs, in different markets - but all related to the same product.

To some this may not sound like pure coherence.

Eugene, I have experience helping POs and Dev Teams craft sprint goals that encompass much of the Sprint forecast, or only a small segment of the forecast.   One thing that I strongly caution against is associating a Sprint Goal with a single PBI.   There is inherently more risk in missing the Sprint Goal with that approach (single point of failure), and is usually indicative of an item that contains a lot of unknowns.



I've found success designing Sprint Goals around value-based verbage, such as "Improve...", "Provide...", "Include...". "Restrict...", "Add...", "Enhance...", etc.

Regarding Sprint Goals I really like the template provided by Roman Pichler: https://www.romanpichler.com/blog/sprint-goal-template/

Nearly everyone knows the concept of SMART Goals (https://en.wikipedia.org/wiki/SMART_criteria), do you think this is a thing to keep in mind when crafting the sprint goal?

Time-related is covered by the sprint itself, assignable would be the development team, specific, measurable and realistic would be the criteria to be contained in the phrasing of the goal?

In my practice, A stands for Achievable (not for Assignable). Do you practice otherwise, @Julien?

PS: Fully agreed, Timothy

@Eugene: of course you are right.

I was reading through the article and the "assignable" mentioned in the history section somehow got stuck in my head for the time typing the post.