Every task should deliver value. But until the task is Done, that value is only potential.
Think of a feature that is partly built and not finished, or awaiting code review, or that has merge conflicts.
At the sprint review, stakeholders ask about the feature.
“Well, it’s nearly done.”
For stakeholders – or indeed any user of your product – until it’s done, they won’t see any value from what you’ve been working on.
It’s either done or it isn’t.
Working across the board
In some teams, there’s a temptation to always start something new – and for developers to see “code complete” as “I’ve done my part”.
Instead, it’s important to look at the board as a whole.
The rightmost column of the board (before Done) shows the tasks that are closest to Done, and therefore require the least effort to get to Done.
The team should focus their efforts on the right side of the board, and then work across the other columns, moving left – before starting a new task.
That way, the tasks that have already had effort put into them can be completed, and the team avoids having a lot of half-finished work.
Splitting the “In progress” column
Let’s say you split your “In progress” column into the following statuses:
- Dev in progress
- Code review
- QA review
- Product review
- Ready to deploy
Then the last status is Done.
What happens after Dev in progress?
Say there are 2 tasks in each column and 5 more in the To Do list.
A developer has finished coding, and moves the task into “Code review”. What do they do next?
If their instinct is to immediately pick up a new task, the result is the team will have another task in progress.
Why have something else in progress when other tasks aren’t done?
Review time
Instead of picking up a new task, the person could ask for reviews. The reviews could take time to do, so the person might be at a loose end…
But this is also a perfect opportunity for the person to look for anything that needs their review.
After code review…
Going back to our statuses – when the task passes code review, it moves to QA review. What does the developer do?
In a truly cross-functional team, anyone can test the task – it doesn’t have to be a named QA. Though, it’s better to have someone else test your task than to do it yourself. Getting a second opinion can be valuable.
Moving things along
The point here is that you should want to move the task along. All that work that went into coding the task will be sitting there, wasted, if the task hasn’t been fully reviewed.
So give the QA – or the team – a heads up that the task is ready for review. Maybe let the product manager know too.
Once the task moves to Done, the value is in the bank. But before picking up another task, first look if there is anything else needing review.
Summary
If you’re always picking up new tasks, you’re always starting from zero – which means you’ll need more effort to get them to Done.
By looking at the rightmost column on the board before starting a new task, you’re seeing the tasks that have had the most effort put into them, and that should require the least effort to move to Done.
Photo by Nick Fewings on Unsplash