Sprint planning dies in 48 hours

[#1]

4 hours of sprint planning. Dead in 48 hours. Every single sprint.

This keeps coming up in engineering communities, and the responses are almost always the same: "your sprint isn't locked anyway, why pretend it is?"

And they're not wrong.

In most orgs, sprint protection is theoretical. Stakeholders pull priorities mid-sprint constantly. The team pushes back, loses, and absorbs the cost quietly.

Some teams move to Kanban, stop planning what you can't protect. But that trade-off has its own costs: Without sprint boundaries, everything becomes equally urgent.

There's no forcing function to slow down incoming requests. The work that needs sustained focus rarely gets it.

So neither framework solves the actual problem.

When a priority gets pulled in mid-sprint, the conversation almost never includes what got deprioritized or why the assumptions changed. That reasoning disappears.

The team gets better at absorbing disruption instead of understanding it. And it all repeats next sprint.

What most teams are missing isn't a better framework. It's a record of why things changed, and whether they should have.

[Van Rees_ David]

Why would anything new be automatically as urgent as everything else? If things are that chaotic, leaders likely need a discussion around basic delivery principles.

There's a lot to infer from this post, including ineffective PO's and SM's, ineffective leadership, ineffective governance and oversite.  Delivery leaders should be supporting the team with business or tech leaders who create anti-patterns by trying to insert work mid-sprint if the PO or SM aren't allowed to stand up for the team.

Leader interference is also an impediment that can be raised back to them. 

Metrics showing impact of disrupted work should be shown back to leaders.  Time to market will be impacted.  Cycle time of in progress work will definitely be impacted.

Likely work that skips refinement and pushes in has less quality than work that follows the process.  Work stopped mid-stream likely has less quality than work that finishes cleanly.  Showing quality impacts might help.

If all else fails, having a strong WIP limit for in progress work (ie: 1-2) and reinforcing all work goes through refinement first means work appearing late can go through the proper workflow without coming into play that day (unless it's a critical emergency like an outage) and maybe come next sprint or two or possibly later that sprint.

[Stephen_Lugton]

As far as possible we work on the principle that if a stakeholder wants to change priorities we have no problem with that, as long as they're aware that we will stop doing something but not add in alternative project work, with the caveat that related work that has already been refined and was the next item in the backlog for that project may be picked up if it will not cause too much disruption.

However, we also have a mechanism for support work to come in to a team's Sprint - 2 team members are allocated 50% of the time to pick up any operational support requests.  The rest of their time for that sprint is allocated to bug fixes.  In effect for these 2 team members we are using Scrumban.  This means we can easily pivot for regulatory / operational reasons without affecting our sprint goal, but if needed we are willing to get the entire team to drop whatever the sprint goal is if there is a major regulatory or operational issue that needs then and there resolution.

As part of our sprint review we discuss challenges, including changes in priorities, this gets reported up to our senior stakeholders who are known to raise this with the relevant PO / stakeholder and ask them to justify disrupting the team.

[Nigel Budd]

I've seen this situation a number of times in my career, and I'd put money on the fact that the stakeholders are also complaining that the developers never finish anything.  

If an organisation adopts Scrum, this approach should give a team 2-3 weeks of uninterupted time to work on what they have planned, it's the respect that the organsation should show to the team. 

Having this uninterrupted time, allows the team the ability to work optimally and gives them focus.

If priorities and the backlog are changing that fast, then Kanban might well be a better alternative, it provides a lot more flexibility, however it does sacrifice predictability, and if that is the organisation needs to be able to create roadmaps, and provide delivery dates, then that predictability might be something that is more important than flexibility.

I've always argued that you need to chose the right framework/approach for the organisations needs, both frameworks have strengths as well as weaknesses.