From “Good.” to “Not Good.” — Every Team Knows This Sprint

Not long ago, I asked one of the teams I was working with to describe the sprint in one word.

"Good!" someone said.

"OK, how about two words?"

"Not good." said someone else. Beyond the laugh it provoked, after digging into the problem together with the team, we arrived at a conclusion. And I suspect you've felt this at some point too. The sprint planning ends well. The team is aligned, the scope is clear, the mood is optimistic. Two weeks later, the retrospective feels like a therapy session. Tasks were completed, velocity looks fine on paper, but something went wrong and nobody can quite explain what.

I've seen this pattern in two distinct forms. Both feel the same from the inside. Both have completely different causes. The first is when the team never understood what season they were in. A product team started a sprint focused on delivery. New features, clear acceptance criteria, a roadmap that made sense. What nobody had named explicitly was that the platform underneath those features was unstable. Every day of the sprint, small fires appeared. Investigations, workarounds, production issues that didn't make it onto the sprint board but consumed the team's actual time and energy.

The planning had been optimistic because everyone looked at the backlog. Nobody looked at the foundation. The retrospective was frustrating because the team felt behind, but couldn't point to a single moment where things went wrong. Everything went wrong, quietly, in the space between what was planned and what the season actually required.

The second is when the season changes mid-sprint, and the team doesn't notice. A different team was three days into a well-planned sprint when a major client raised a critical issue. Not a bug, not a feature request — a fundamental question about the direction of the product. The kind of question that, if left unanswered, made the sprint's entire scope irrelevant.

But the information that reached the team was incomplete. What they heard was fragmented, sometimes contradictory, and filtered through several layers of management before it arrived. Nobody had a clear picture of how serious the situation was or what it meant for the work in progress.

So the team kept going. The stand-ups kept running. The tasks kept moving across the board. Not out of negligence — out of genuine confusion about what was actually happening and what, if anything, should change. At the retrospective, they had delivered most of what they planned. And very little of it mattered, because the context had shifted on day three and the team had never received the clarity they needed to reorient.

The season had changed. The team had kept moving through the fog, hoping the picture would eventually clear. Two different causes. Same outcome. A planning that ended in optimism. A retrospective that ended in frustration. And in both cases, a gap between what the scoreboard showed and what the team actually experienced.

The sprint board tracks tasks. It doesn't track seasons. It doesn't tell you when the foundation needs attention before new features are added. It doesn't tell you when incomplete or contradictory information has made the current scope irrelevant. It doesn't tell you when the rules of the game have quietly changed.

That awareness has to come from somewhere above the board. Next time your sprint ends with a retrospective that feels heavier than it should, ask one question before you analyze the tasks: Did the season change during this sprint — and did we have the clarity to notice

That question won't appear on the board. But the answer will explain almost everything. What does your team do when the season shifts mid-sprint — especially when the information is unclear or incomplete?