Suggestion Sprints can be "freezed" and "unfreezed"

How often does this happen?

Scrum is structured, and is good for plannable work. After multiple sprints of the same duration, the team develops a kind of tempo, and begins to develop at a less variable velocity. Pausing sprints would disrupt this.

In addition, if the team stops and works on something else for a few weeks, when they come back to the work they'll have forgotten many details, and you're better off doing sprint planning again anyway.

Cancelling the sprint can also be seen as somewhat of a dramatic event, which provides additional visibility of the impact of these "we need this now" requests.

An alternative, and I don't know if this is possible in your situation, is to complete the sprint and begin on the new unplanned project in the next sprint. This way you don't change your requirements mid-sprint, but business is still able to set priorities. You could keep sprints short (2 weeks) to account for this.

SandraU,

Per the Scrum Guide, here is what is seen on canceling a Sprint:
When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.
.
.
.
It appears that what you're trying to achieve would still work with a canceled Sprint. I would think that "freezing" items would indicate that you simply put the unfinished work back to a backlog and address it later ("unfreeze"). The team should meet to get an indication of whether something can be accepted by the Product Owner.

Once ready to go back, the team starts with Sprint Planning.

I agree with you that one should consider whether this is high priority, or there are other reasons to go down this path.

I also agree with @Robert where there are some questions one can ask, but I would consider shortening the sprint length to minimize the risk.

Hello,

I am new in the team. I do not know how often it happens. I will ask.
The Sprint is already two weeks long.

So one question is: what is the difference between: cancelling and freezing.
Cancelling is some kind of bad experience for the team. Maybe we need
a different term or at least a different attitude to this?

I will look what they are doing when something like this happens
and how they feel about it.

Regards,
Sandra

Sandra, cancelling being a bad experience is kind of the point... being interrupted from your development and being told to do something else IS bad, and it negatively affects the progress of the team.

The people who are responsible for this abrupt change in priorities need to be aware of its negative impact. The team shouldn't be masking this and pretending that it's good. One of the goals of scrum is to protect the team from changing requirements DURING a sprint. The business can change the priority of the product backlog as much as they want, however they want. But once a sprint starts, the sprint backlog is owned by the team and can only be changed with their agreement.

IMO, you shouldn't be thinking about changing the attitude of the team, but rather the attitude of the people who "need" the team to drop everything now and start doing something else.

Hello Robert,

yes, I like the idea that the Team is protected by the Scrum Master.
(I did not find this in the Scrum Guide 2013, it was in the Scrum Guide 2010?)

I learnt that there is theory and practice.
Truth is that something there are things happen, that happens.
This interruption cannot be avoided, because of change of market.
I do fully understand this. My concern is how we can reduce the impact to the team,
and make them hopefully still smiling.

Maybe from business point of view, they could give some kind of warning ahead:
Maybe we will get an unplanned project in x weeks. Then the team could maybe
make a shorter sprint to be ready?

I also work in an environment where interruptions are something unavoidable. Basically, critical live production problems will take priority over regular development. We try to shield the team by having other people do this work but sometimes their involvement is necessary. So yes, practice is very different than theory. But by talking about theory we try to work towards an ideal situation, and make transparent the things that are keeping us from that ideal.

The team should not be (overly) discouraged at a sprint cancellation from external sources. The narrative is "folks, we need to cancel the sprint because so and so has asked/directed that we drop everything because this new thing is really important and they need our help".

As you say, if business can give warning it would help greatly. And X weeks = 2 since your sprints are 2 weeks. My recommendation would be to try to integrate these interruptions into the scrum process. I.e. have stories or PBIs prepared for them and do them as a standard sprint.

Looking at the scrum guide...

For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No
one is allowed to tell the Development Team to work from a different set of requirements, and
the Development Team isn’t allowed to act on what anyone else says

In your context, this means that these interruptions should flow through the Product Owner. If business needs the team to work on something else, they should inform the PO who would then prepare stories or Product Backlog Items for the next sprint.

You're right, I couldn't find anything specific about how the Scrum Master protects the team from external influence, specifically management. It seems like a glaring omission.

> But what about business environment where unplanned
> projects request the team to stop the current sprint
> and work first on this unplanned project?

Scrum is an empirical approach based upon transparency and a regular cadence of inspection and adaptation. Scrum Teams and their stakeholders are expected to commit to that framework. Freezing sprints compromises all three of these legs upon which Scrum stands. When a sprint is frozen, the window of transparency is shuttered and the cycle of inspection and adaptation is no longer in effect.

The right thing to do in the situation you describe is not to freeze a sprint, or even to cancel it. The problem you have indicated is one of scope and prioritization, which makes it a Product Ownership issue. You need to identify the Product Owner in this situation as the role seems to be rather vague. Then the new work should be added to the team's Product Backlog so they can handle it within the context of Scrum and ongoing iterative delivery.

It would appear that you have a "hidden" Product Owner somewhere...the authority who has determined that this other work trumps the product you are working on. This is the person who *really* determines priorities and who is responsible for return on investment. Your current PO would appear to be a proxy for this authority. I recommend clarifying product ownership with the stakeholders involved, and establish the position that the team needs to keep sprinting.

Ok,

Scrum is for the ideal situation. But this situation is not ideal.
So it cannot be handeld with Scrum. Usually adapting Scrum
is a very bad idea ...

So I change to say it is some kind of "fire in the house-situation".
A situation that should not be there, but cannot be avoided in practice.

(Fire is not an ideal situation, and hopefully people go out of the building).

Regards,
Sandra