There are a lot of reasons for spillover in my experience. They’re all interrelated.

First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results. They may love the glory of leading or assisting a team of software engineers to build great products, but I’ve seen maybe 1 or 2 who are actually qualified to be the agile/process guy/gal. Additionally, they’re frequently counter-incentivized to be meeting jockeys, PowerPoint creators, and “culture people” who simply do not do the job as it’s meant to be done.

As soon as ^^ happens, sprints are destined to fail, because the work of sizing tickets falls squarely onto engineers who would probably rather be writing code than talking about it, so they make informal agreements about value of a story point being a day’s work or not blocking tickets that don’t have defined success criteria, or what have you. As such, tickets are not properly vetted and grow to be massive, amorphous chunks of work that either allow devs to hide from the (painful/annoying) process of Scrum and just do their thing.

The last (and worst) of the reasons spillover happens is that people are burnt out, unmotivated, or unrewarded by the process. If the “customer” (also a massive rats nest of a concept in Agile) isn’t at the demo and actively interested in the product being developed, any amount of “points” will feel arbitrary and useless. There’s no faster way to lose interest in Scrum than canceling a demo and having your developers lose faith that completing that ticket actually matters to someone.

> First and foremost is that most product/project managers, engineering managers, “scrum masters”, etc. do not truly love doing the work of backlog refinement, ticket management, writing acceptance criteria, or other forms of planning that entail actionable results.

In my experience this rings true. Whenever I see a ticket with no description or acceptance criteria, a ticket that's blocked by another ticket in the middle of the backlog, or a ticket that's being repeatedly rewritten mid sprint to include work that's already in the To Do column or at the top of the backlog, I feel like walking up to the Scrum Master and going "What would you say... you do here?".

Bring this stuff up at retro and blame gets redirected and watered down. The action becomes "we as a team" need to get better at doing the Scrum Master's job.

But like you say, they're very fond of big picture stuff like PowerPoints and meetings about doing agile better.

Yeah. “We succeed and fail together” - unfortunately, unless this is true from a management and reward perspective, it can never be true at a team level. Additionally anything raised in a retro that contradicts a management edict will never see the light of day.

If your PM is appraised by Power Point quality or number of sprint points while engineers are managed by some other criteria, success and failure become asymmetrical and incentives clash.

Or spillover happens because the map isn't the terrain and no plan survives contact with the first brittle edge condition in the existing codebase.

Sure. To me that sounds related to the “lack of backlog refinement” and “no AC” parts of this. If there’s no text on a ticket, there’s not even a map! Good luck with the territory, in that case.

That isn't really backlog refinement though. That is when you start actually doing the task and you realize that plan A and plan B of how to implement the fix or whatever can't work, and fixing it will necessarily be much more time intensive and some sort of plan C or plan D. Often this happens when you go to start changing code and you see how badly the tests blow up on you or something like that.

Whichever the reason: you don't use negative language. You didn't fail the sprint, you didn't have bad developers; you sit down and discuss what you can do better next time, for example: reduce your commitment, spend more time refining and preparing a story before estimating it, take up courses / do knowledge sharing, etc.

You never use language like "the sprint failed" or "what went wrong", you say "we underestimated", "there were unforseen circumstances", or "what can we do better".

I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset. "We failed" is giving up, "what can we improve" is taking ownership and action.

> I'm sure there's cynics in here that will have a benny about "soft language" and "the tofu-eating wokerati are at it again" or something, but it's not so much about language but mindset.

I think it's less about the language and more about being forward looking. You can't change what happened in the sprint, but you can do the next sprint better.

It's also about clear separation between identifying issues vs assigning blame. The latter doesn't help anyone, because blame is almost always backward-looking.