I’ve coached many people over the years, and I keep seeing the same pattern. You walk past the physical or virtual Scrum board, and your eyes catch on a particular card. It has a vague title like “Do it.” It’s been sitting in the “Doing” column for what feels like forever. The developer assigned to it looks stressed, progress is invisible, and no one really knows when—or if—it will ever move to “Done.”
The “Do It” task is the work item that gets slapped onto the board when a team is focused on a technical instruction instead of a human problem. It’s a failure of curiosity about the why behind the work. And it’s killing your sprints.
The Anatomy of a “Do It” Task
A “do it” task is really just a placeholder for work that nobody fully understands yet. Often, it focuses on technical implementation over solving a real-world problem for an actual person.
Teams accept these tasks when they don’t know the right questions to ask. Or more importantly, when they don’t know what they don’t know about the work. It’s a symptom of forgetting a core Agile principle: a user story is a placeholder for a conversation, not a set of requirements.
When that conversation doesn’t happen—or when it’s insufficient—you end up with a “do it” task. A vague instruction with no shared understanding of the problem you’re trying to solve for the accountant, the engineer, or the salesperson at the other end of the screen.
Why “Do It” is a Red Flag
I can predict what happens when a team accepts one of these tasks onto their board. The consequences are as predictable as they are damaging:
Stagnation. These items linger for weeks, stuck in the “Doing” column. They become bottlenecks, blocking the flow of work and making sprint goals unattainable.
Estimation failures. “Do it” tasks are a primary cause of massive estimation failures. A task that a team vaguely estimates at 10 hours will predictably expand to 32 hours or more once the hidden complexity finally surfaces.
Unmanaged risk. The “do it” label masks ambiguity. By accepting it, the team is blindly accepting unknown technical and business risks. Any sprint commitment becomes a gamble.
A “Do It” task isn’t just a bottleneck. It represents a breakdown in the collaborative mindset that Agile is supposed to foster.
The AI Parallel: Garbage In, Garbage Out
Here’s something I’ve been noticing lately: the way we work with AI is teaching us something important about how we work with each other.
If you give an AI a vague, poorly defined prompt, it will try to fill in the gaps. It will make stuff up, generate a poor result, and leave you wondering what went wrong.
A developer is no different. When you hand them a task that just says “do it,” you force them to work without clarity. They have to make assumptions about user needs, technical constraints, and business goals. The result is almost always a poor or incorrect implementation that requires significant rework.
The principle is simple and universal: garbage in, garbage out. A poor prompt yields a poor result, whether you’re working with a large language model or a human developer.
Learning to write a clear prompt for an AI is excellent practice for defining a clear task for a human teammate. Both require you to master the art of clarity and intent.
From Fog to Clarity: A Practical Strategy
Eliminating “do it” tasks requires a shift from passive acceptance to proactive clarification. Here’s a four-step strategy I’ve seen distinguish exceptional teams from mediocre ones.
Step 1: Speak Up
This is the most crucial step, and it’s not just a good idea—it’s a developer’s duty to the project and the business.
This is the moment, right here in sprint planning, where I see teams either save their sprint or doom it to failure. When a work item is poorly defined, it’s a team responsibility to pause and have a conversation. Blindly accepting a “do it” is a recipe for failure.
Step 2: Create an Exploratory Task
When you don’t know what you don’t know, the solution isn’t to guess—it’s to investigate and figure out the “best next question.”
Create a new, separate task on the board specifically for exploration. The goal of this task is to “turn the bottle around” to see what you’re dealing with.
This exploratory task is not about completing the feature. It’s about identifying the unknowns. It’s a time-boxed effort to research, ask questions, and figure out what you don’t know. This simple act transforms a vague “do it” task into a concrete plan for discovery.
Step 3: Negotiate with the Product Owner
Once the exploratory task is complete, the development team must circle back with the Product Owner. This is a critical moment for collaboration and negotiation.
The team should present their findings and ask clarifying questions:
- “Now that we know this, are we ready to commit to the full story?”
- “Do we need to remove this story from the sprint to redefine it based on these findings?”
This conversation ensures that the team commits to work only when it’s understood and achievable, protecting the sprint and aligning everyone on the path forward.
Step 4: Reinforce the Purpose of a User Story
This entire process reinforces a fundamental Agile principle: A user story is a placeholder for a conversation, not a final specification or a place to dump requirements.
When teams treat stories as the start of a dialogue rather than a finished order, the “do it” task can’t survive. This collaborative mindset is the ultimate antidote.
From Ambiguity to Leadership
“Do it” tasks aren’t just minor annoyances. They’re symptoms of unaddressed ambiguity that lead to predictable failure, wasted effort, and frustrated teams. They represent a departure from the collaborative spirit of Agile development.
I’ve learned to treat a vague task the same way I’d treat a junior developer—or an AI. You wouldn’t expect them to succeed without clear instructions, context, and a conversation.
By refusing to accept “Do It” tasks, you’re not being difficult. You’re leading, clarifying, and building the foundation for predictable success.
