The Sprint That Wouldn’t Move
In 2019, a mid-sized SaaS company’s product team was three weeks into a six-week sprint and had closed almost nothing. The list was long, detailed, and beautifully organized. Tasks were tagged by project, labeled by priority, and nested under tidy headings. The team’s project manager could tell you exactly what was on the board. She could not tell you why so little of it was getting done.
This wasn’t a motivation problem. The engineers were working. The designers were delivering. Stand-ups were happening. But the sprint board kept filling up faster than it emptied, and completed items felt like a coincidence rather than a result.
The manager eventually did something uncomfortable: she asked each team member to write down, independently, what they thought the top three priorities were for the week. Seven people. Seven different answers. Some overlapped. Most didn’t.
The to-do list had been organized for whoever wrote it, not for whoever had to execute it.
What Was Actually on the Board
When the team audited the sprint board together, a pattern emerged. Tasks were written in the language of intention, not action.
“User onboarding improvements” sat next to “Fix auth bug” sat next to “Q3 roadmap.” These aren’t tasks. They’re categories. Nobody can sit down on a Tuesday morning, look at “user onboarding improvements,” and know what to open first.
The board also had no sense of dependency or sequence. A front-end task was listed at the same level as the API work it depended on. Three tasks required a decision that hadn’t been made. Two tasks were waiting on a vendor response that no one had followed up on. Everything looked equally ready to start. Almost nothing actually was.
And the list kept growing. Every stand-up surfaced something new. Every Slack thread added a task. The board was optimized for capture, which is a different goal than completion. Your to-do list is probably doing the same thing at a smaller scale.
Why This Happens
Most task management tools are designed around the satisfying act of adding items. The input field is prominent. Capture is frictionless. This is a feature, not a bug, from the software’s perspective. The more you add, the more indispensable the tool becomes.
But the cognitive work of doing is different from the cognitive work of writing things down. When you write a task, you hold the full context in your head. You know what “user onboarding improvements” means because you just thought about it. When you come back to that task two days later, that context is gone. You’re left with a label.
The organizational systems most people use compound this. Grouping tasks by project feels logical when you’re building the list. But when you sit down to work, you don’t have a fixed number of hours per project. You have a fixed number of hours, period. What you actually need to know is: given my current energy, available time, and what’s blocking what, which single thing should I start right now?
A list organized by project cannot answer that question. It’s optimized for the writer’s perspective (“what do I need to do for this project?”) rather than the doer’s perspective (“what should I do next?”).
What the Team Changed
The product team made three structural changes to how they wrote and organized tasks.
First, they rewrote every task as a concrete action. “User onboarding improvements” became “Write three variations of the welcome email subject line for A/B test.” “Q3 roadmap” became “Draft the three capability bets for Q3 and share with the team by Thursday.” The rule was simple: a task had to describe a specific output, not a general area of effort.
Second, they separated the ready queue from the backlog. At the start of each week, the team spent 20 minutes identifying which tasks were actually startable, meaning no unresolved dependencies, no missing decisions, no waiting-on-others blockers. Those went into a “ready” column. Everything else stayed in the backlog. The ready column was short, intentionally. It created a realistic picture of what the week could actually contain.
Third, they stopped adding tasks to the sprint mid-week. New items went into a staging list. During Friday’s brief review, the team decided together what (if anything) warranted adding. This wasn’t about rigidity. It was about protecting the team’s ability to see an accurate picture of the week’s progress rather than a constantly-inflating list where everything was equally urgent.
The next sprint closed significantly more items. More importantly, the team stopped feeling like they were failing a list and started feeling like they were executing a plan.
What You Can Take from This
You probably don’t run a product team, but the same failure mode shows up in individual to-do lists constantly.
Look at your list right now. How many items on it could you start in the next ten minutes without needing to make a decision, find a resource, or wait on someone else? If the answer is fewer than half, your list isn’t a plan. It’s a parking lot.
The fix isn’t a new app. It’s a change in how you write tasks and how you review them.
When you add a task, ask yourself: “What would done look like, and what would I actually open or do first?” Write that. “Research competitors” is not a task. “Read the pricing pages of three competitors and note positioning differences” is a task.
When you review your list, sort by readiness, not by project or priority label. What can you actually start today? Put those items somewhere you can see them clearly. Everything else is just inventory.
Priority labels are particularly misleading. A “high priority” task you can’t start because you’re waiting on a reply is less useful to you right now than a “low priority” task you can complete in 20 minutes. Readiness is a filter that priority labels ignore entirely.
The team in this story didn’t need better software or a new methodology. They needed their system to answer the question they were actually asking: not “what needs to get done eventually?” but “what should I do right now?”
Your to-do list probably can’t answer that question. Rewrite it until it can.
