Continuing my mini-series on the Scrum Framework, I look at stopping a sprint. Should you ever stop a sprint? And if you do, under what circumstances?
Or listen at:
Published: Wed, 31 Mar 2021 16:00:59 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I'm continuing the mini-series on Scrum. In Episode 73, I provided you a primer to Scrum. In Episode 74, I talked about the various values. 75, some common problems. 76, the Definition of done. 77, conflict. 78, warning flags that appear during the use of Scrum. And 79, I talked about how it will highlight problems.
In this episode, I want to talk about when to stop a Sprint.
The Sprint is a time box in which the team work say. For example, if they are working in a two week sprint, everything happens within that two weeks. They do the planning, they do the work, they do the review and they do the retrospective and then they repeat every two weeks.
Generally speaking, you would expect the Sprint to continue based on the work that decided on in the original Sprint Planing.
If the team is working to a two week Sprint, the norm would be at the start of that two weeks, they have the Sprint Planning. They decide what work it is they're going to try and achieve during that two weeks. And then the rest of that two weeks is dedicated to producing that work, that agreed list, from the Sprint Backlog.
However, there are times we need to stop the Sprint. And this is the topic of this episode.
The Scrum Guide says:
"A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint."
We should consider stopping a Sprint as being a traumatic event. Stopping a Sprint means we stop all the work.
Everything in that Sprint effectively becomes discarded.
The Sprint would have to restart. We'd have to redo planning. We'd have to look at the commitment that we want to do within that sprint.
It should be considered an exceptionally rare event.
Now, there are correct times in which to stop the Sprint. As the guide says, if the entire goal suddenly becomes obsolete.
Say, for example, the team are working on a product and it's been cancelled. There's no point continuing developing that product if the organisation has decided to cancel.
Maybe, for example, the organisation has been bought by a third party who's decided they want to change direction.
Or maybe the organisation has felt the product doesn't fit the needs of the organisation and they've decided to cancel any further investment. And as such, it's been decided the contents of the Sprint - the items that are currently on the Sprint Backlog, the items that are currently being developed during that two weeks - actually provide no value.
And thus, if they provide no value, there probably is a good reason to consider stopping the Sprint.
And that's part of the facility of Agile - it's being able to adjust to changing conditions.
We may have started a Sprint two days ago. And we may have believed that the items that we were being asked to develop - to put into the Sprint Backlog for the next two weeks - were valuable to the organisation. But sometimes things do change.
Now they are rare, as I suggest, but if they change then adjustment is needed and it is correct to make that adjustment - in those rare circumstances.
We do have to obviously, however, be careful with such power - with great power comes great responsibility.
Just because we can adjust quickly, we still need to think about is it the right thing?
Simply changing direction on a whim is dangerous and obviously very costly.
Its the equivalent of doing doughnuts in the car park - yes, we can do it, and we can go round and round and round, but it isn't producing any value.
So for me, any time a Sprint is stopped, there are some warning flags.
How often is it happening?
If it's happening maybe more than once or twice a year - that really rare event - then I'd be questioning whether or not there's something wrong in our planning up front or whether our governance structure is correct in terms of the work that the team and the wider organisation is being asked to do.
Is the Product Owner being overruled on the items that they've been asked to put into the Sprint?
During the Sprint Planning, the Product Owner and the Development Team sit down and decide from the Product Backlog what items are going to produce the most value for the organisation during that two week Sprint.
If the product owner agrees with the team and the sprint starts, only to have maybe one to three days later an executive order from above to stop the sprint, to change what we're doing, that indicates that somewhere along the line, the Product Owner is not being given the authority and the responsibility to make the choices they need to.
And this comes back down to the Product Owner's role. The Product Owner's role should have that authority to make the decisions on behalf of the organisation. There shouldn't be anybody second guessing them.
There shouldn't be somebody's going: "oh no, I'd rather we did A rather than B" or "C rather than D".
It is the Product Owner's discretion.
Again, obviously, if there are external forces - such as the organisation being bought or a massive change of direction - obviously that's not something the product owner can influence.
But certainly, we should avoid a situation where the Product Owner and their role is being overruled on a consistent basis - because that really is a sign that something is very wrong in the organisation and the adoption of Scrum.
I'd also consider looking at how long your Sprint was.
If there's a call and a need to change direction mid Sprint, how long is your Sprint? If it's two weeks, most people, most organisations would be able to cope with: "Ok, we've got something urgent, but it can wait for two weeks".
Now, maybe you're not that sort of organisation - maybe an organisation that works much faster than that, in which case change the length of the Sprint.
I've seen organisations actually go as short as a single day Sprint.
I wouldn't recommend it for most organisations because of the overhead involved - but if you are an organisation that does change direction that rapidly - and it is correct for you to change direction that rapidly - then maybe shorten the Sprint down.
If you originally started Scrum with a very long sprint, say for example, 3 months, then that's definitely a sign that Sprint is too long anyway.
For me, a sprint should really be no longer than four weeks. And in most cases, two weeks is about right, maybe coming back down to one week if necessary.
But certainly if you're having to talk about or actively cancel Sprints on a regular basis, certainly look how long your Sprint cycle is.
As I've said, stopping a Sprint should be considered a traumatic event, not only do you get the loss of investment - that investment that you've put in so far getting to that point in the Sprint, the time and effort people are spent on planning and potentially developing work during that Sprint - you also suffer from a demotivation effect on the team.
The team have committed to producing a set amount of work. They've committed to producing what is in that Sprint Backlog. They are focussed on that.
If they are being stopped regularly so the Sprint can be cancelled, it becomes very difficult for the team to concentrate on what they're trying to do and they become demotivated.
Their work is meaningless if they're being asked to stop it on a regular basis.
If the team have to stop Sprints on a regular basis, that leads to that demotivated team. And it leads to a lack of forward momentum.
Ultimately, the team will not be delivering anything because they're constantly stopping. And because they've stopped, even if they've done good work up until that point, in effect needs to be lost because we've cancelled the Sprint. We're throwing away that work because there is no value to it. And obviously, this quickly leads to both the team feeling demotivated and unfulfilled in their work, as well as the organisation questioning the value of the team because nothing productive has been produced.
In this episode, I've talked about stopping a Sprint.
Yes, it can be stopped.
But you have to consider it being a traumatic event. You have to look for warning flags to see if there is something wrong in how the organisation is addressing Scrum, how the team works and what effect it is having if you are using it on a regular basis.
There is definitely something wrong if it goes beyond being anything other than a rare event.
Thank you very much for taking the time to listen to this episode. I look forward to speaking to you again next week.