Focus on Scrum

When we talk about Scrum, we talk about the roles, the events, the artifacts. The Daily Scrum, the Sprint Review, the Product Owner, the Definition of Done. These are the mechanics.

What we talk about less are the Scrum values: Courage, Focus, Commitment, Respect, and Openness. They’re listed in the Scrum Guide, but they don’t come with a meeting format or a checklist. They’re harder to measure, so they tend to get skipped.

Today I want to talk about Focus — because it’s the one I see teams lose most quietly, and most expensively.

What focus actually means

Focus in Scrum isn’t about putting your phone away. It’s not about deep work or time-blocking or muting notifications. Those are personal productivity habits — useful, but not what the Scrum Guide means.

In Scrum, focus means staying with the task in front of you until it’s done. One task. Finished. Then the next. It sounds obvious, but it’s surprisingly rare in practice.

A task that is 90% done delivers exactly 0% of its value. Users can’t use it. The team can’t ship it. The effort is real but the outcome isn’t. In Scrum, partially done work is waste — not progress.

This is why focus operates at the task level, not just the sprint level. Starting five tasks and finishing none is worse than finishing two and leaving three untouched. The two finished tasks have value. The five in-progress ones are just inventory.

The “while we’re at it” trap

Here’s the scenario every developer knows. You’re working on a feature, you open a file, and you notice something nearby that’s messy. A function that could be cleaner. A query that’s slower than it needs to be. A comment that’s been wrong for six months.

“While we’re at it” — and suddenly you’re refactoring code that has nothing to do with the Sprint Goal. The logic is reasonable: we’re already here, it’ll only take an hour, we’re all trying to improve the codebase. All true.

But an hour here, an hour there, and by Wednesday you’re behind on the thing you committed to. The Sprint ends with the goal partially met and a handful of unrelated improvements scattered across the codebase. The team delivered work — just not the work that mattered most.

Leaving the campsite cleaner than you found it is a good instinct. It becomes a problem when it pulls you away from the reason you came.

One task at a time

Scrum doesn’t prescribe how developers pick up tasks, but the principle is clear: work should flow, not accumulate. The healthiest teams pull one task, see it through to done, then pull the next. Work in progress is a cost, not a measure of effort.

This also means resisting the pull to start something new when you’re stuck. Being stuck on a task is uncomfortable. Opening a new ticket feels like momentum. But it isn’t — it’s just moving the discomfort forward while adding another unfinished thing to the pile. The better move is to ask for help, unblock the task, and finish it.

A Sprint full of tasks that are all 80% done is a Sprint that delivered nothing. A Sprint where the team finished fewer tasks completely is a Sprint that delivered something real.

The Scrum values aren’t decoration. They describe the conditions under which the framework actually works. Focus is what turns a Sprint into a commitment rather than a to-do list.

Next time you’re in a Sprint, try this: at the Daily Scrum, before listing what you did yesterday, ask yourself whether it moved the Sprint Goal forward. If the honest answer is no — that’s the conversation worth having.