In any software project, there always seems to be That Task. The one that Steve has been working on since January. That Task has been in twelve consecutive sprints, handed between three developers (because Katie went on holiday, then Dave was seconded to another team to help their overrunning project), and survived two department restructures, with no end in sight.
Thanks to a complex web of project interdependencies, That Task is now responsible for blocking four teams (across two departments), delaying six new features, and causing Harry from Sales to miss his revenue target for the quarter.
Here are five things that might be wrong with That Task, how to avoid those things happening, and what to do if they happen anyway.
1. Too big
The Problem
A task with twice the scope should take twice as long, right? No. A task with twice the scope takes quadruple the time. This happens for a few reasons.
- The larger the task, the lower the feeling of urgency. It’s going to take four weeks to finish this – so why does an extra day matter?
- The longer a task is in progress, the more likely it is to get handed over to a different developer. People become ill, go on holiday, get pulled onto other projects, etc. Handovers take up time.
- Bigger merge requests are more challenging to code review and more likely to run into conflicts and related issues.
- The more time passes, the greater the risk of drifting from the requirements or rabbit-holing (more on that later).
How to avoid it happening
Start by setting a target for how quickly you want most tasks to be completed. I use one week. If you’re doing Scrum, you can use the length of your sprint.
Set up a regular forum where you can review the upcoming tasks with your devs. My team has a dedicated Story Prep Meeting once a week. If you have a sprint planning meeting, that’s probably the right place. At the meeting, ask the team to estimate how long the task would take them.
There are various fun ways to gather estimates. You want it to be a) quick and b) avoid people seeing each other’s estimates before they give theirs. In my team, everyone holds up their hand at the same time, with one finger raised for up to three days work, two fingers for up to a week and three fingers for more than that.
Look out for estimates which are higher than the target you set. Discuss concerns and consider splitting the scope into smaller tasks.
How to fix it when it happens anyway
It’s never too late to re-scope a task. If it becomes apparent that an inflight task is too big, find a sensible place to split it.
2. Instructions unclear
The Problem
The dev isn’t sure what they’re supposed to be doing, how to do it, or how to tell when they’re finished.
How to avoid it happening
Make sure every task has clear, unambiguous acceptance criteria. Read lots of blog posts on how to do this. The user story template “As a user, I want…” is pretty popular.
Next, make sure there’s enough information available for someone to stand a chance of actually meeting those acceptance criteria. In that meeting, you use it to review upcoming tasks and ask if everyone is confident they can start the task they were assigned. Look out for nervous/baffled faces.
How to fix it when it happens anyway
Keep an eye out for tasks taking longer than expected and check in with the dev. Make sure they have all the information they need and that their understanding of the acceptance criteria aligns with yours.
3. Skills gap
The Problem
The scope is reasonable, the acceptance criteria are clear and there’s plenty of information available to help get the job done, but the dev still seems to be struggling. Maybe the codebase or technology is unfamiliar, or the problem has challenging subtleties. Either way, there’s a fine line between a valuable learning opportunity and a dev pointlessly beating their head against a wall.
How to avoid it happening
When the task is being reviewed, look for nervous faces and wildly-varying estimates. This can be a great opportunity for pair programming. If there’s at least one person in the team who is confident about the task, ask them to spread the knowledge by working on the task with someone else. Even if this is unfamiliar territory for everyone, two heads are better than one.
How to fix it when it happens anyway
Consider adding a pair-programming buddy. Bringing the new person up to speed can be a helpful process for the original owner of the task (much like “rubber-ducking”).
If the dev has already spent a lot of time banging their head against a wall, consider reducing the scope. Think of it as time off for good behavior.
4. Can of worms
The Problem
The task was booby-trapped. It looked straightforward from the outside, but as soon as the dev started work, they discovered they’d opened a can of worms.
Maybe a tiny ambiguity in the requirements exploded into a major design decision needing buy-in from four teams across three continents. Maybe the existing code is such a hot mess that changes are impossible without refactoring most of the project. Or maybe you’ve accidentally set an NP-hard problem.
How to avoid it happening
The best protection against cans of worms is to spot them well in advance. This is easier said than done, but there are various red flags to watch out for:
- There’s an unusually long list of stakeholders.
- Implementation decisions will have legal, compliance, or financial implications.
- It involves changes to legacy code or a project that hasn’t been touched in a long time.
- Previous similar tasks took forever.
- One of your devs has spent their Friday afternoons for the last six months chipping away at a branch to refactor that project.
- Someone at the Story Prep Meeting said, “How hard can it be?”
If you feel uneasy, apply scrutiny until you find the worm can or you convince yourself there isn’t one.
How to fix it when it happens anyway
It depends on what the particular problem is. But to stop it totally derailing your project, you’ll usually want to do one of two things:
Option A: Aggressively throw focus on it. Find the people with the right expertise and/or decision-making power and get their eyes on the issue. Five minutes on a conference call with the three people who really count can avoid weeks of negotiation over email. An hour with your senior devs gathered around a whiteboard can save a month of running in circles.
Option B: Kill it. Just because it’s on the project plan, doesn’t mean it’s still worth doing. Now that you have better information, how important is it really to have the calendar start the week on a Sunday? Is it worth four weeks of dev time and delaying the launch? Ask your Product Manager.
5. Rabbit-hole
The Problem
Working on this task has caused the developer to stumble across one or more tangentially-related issues. The area of code they’re working in may be in desperate need of refactoring, missing unit tests, or actually buggy. Like a good Scout they have dived in to solve the problems… and haven’t emerged in weeks. Meanwhile, the actual scope isn’t getting done.
How to avoid it happening
Most rabbit holes represent the technical debt of some kind. Good developers want technical debt to be addressed and are a lot more likely to go down a rabbit hole if they believe there’s no other way that the refactor will ever happen. Make the time available to make steady progress against technical debt, whether that’s allocating a set number of tasks per month/sprint, or allocating a particular day/week to just technical debt.
Raise awareness of rabbit-holing and try to call out tasks with a special risk of it.
How to fix it when it happens anyway
Ask the dev to document the issue they’ve identified, then focus back on the actual scope. Schedule that work to happen at a more appropriate time (and before the heat death of the universe).
Summing Up
By far the best antidote is to keep an eye on inflight work. Daily standups can be a good opportunity to spot floundering tasks. Keep goals in mind, but try to be empathetic as well. People don’t generally appreciate being told their task is taking too long. This is a good place to practice those “strong interpersonal skills” your CV says you have.
If all else fails, tell your stakeholders the task is late because the office dog ate the merge request.
It might work.
