A simple Kanban board has 3 columns: To do, In progress, Done. Tasks in To Do haven’t been picked up yet; In progress shows tasks that are being worked on; Done contains the tasks that have been completed.

If you’re not careful, the “in progress” column can get overwhelming. Here are a few things to watch out for, and some tips to help keep things moving.

1. Set a WIP limit

A WIP (work in progress) limit is a way of setting a maximum number of items that you want to be in progress at the same time. How this is handled varies depending on the tool. Jira displays a red highlight if you go over the WIP limit, but it doesn’t stop you from doing it. Unfortunately, I haven’t found a way to do this in Asana.

The WIP limit is a number, which is often the same as the number of people in the team – sometimes team size plus 1. You can only do one thing at a time, right?

If the In progress column is already full, you could finish the task you’re working on, or help someone else finish theirs.

You don’t get the value from a task until it’s Done, so why not focus on completing things before pulling more into In progress?

2. Identifying blocked tasks

Sometimes a task is picked up that lacks info or starts to become more challenging than expected. If you’ve ever been asked “Any blockers?” then this is the kind of thing I’m talking about.

It’s important to identify blocked tasks on the board. I don’t recommend immediately throwing them back to “To do”, or worse still, a dedicated “Blocked” column. It makes it too easy for them to be forgotten about. Instead, you could use a custom field, you could prefix the title with “BLOCKED”, or you could add a flag to the task (Jira does this nicely).

While it’s not good to hang around waiting for answers when you could be working on something else, switching to another task too quickly could mean you end up having 2 things in progress. When the blocked task becomes unblocked, you’ll need to context-switch and go back to it. So, make sure you mark the task as blocked, and try to unblock it before jumping to another task.

3. Prioritise the things that are closest to being done

Once code has been written and is awaiting review, it’s closer to being done than a brand new task of the same size and complexity.

It might be tempting to get going on the next task, but leaving a lot of things awaiting code review means you’re not seeing the value from the code that’s already been written.

If you keep seeing tasks awaiting code review, or there’s another reason why things are consistently getting “stuck” in the in progress column, there’s another thing you can do.

4. Splitting up the in progress column

Purists will argue that you shouldn’t split up the in progress column. But when it’s getting full and some tasks are sitting there for ages with no movement, it can be helpful to isolate some of the most common sticking points into the own columns.

One way could be to split the column as follows – the four columns in the middle are all a stage within “in progress”:

• (To do)
• Development
• Code review
• Test
• Ready to deploy
• (Done)

The main benefit is you can see much more clearly if a lot of tasks are stacking up in one of these sub-statuses. And if you combine this with a WIP limit, you can steer a team away from picking up a new task as soon as they submit one for code review. The focus becomes more about getting a task fully done and to the end of the process – instead of focusing purely on writing code.

Perhaps you don’t need that level of granularity. However, I’ve seen some teams benefit greatly from this structure – or something similar. You can always adjust it – maybe try adding one more column and see how it goes.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

Software estimates are hard. Even with deep knowledge of the technologies being used, not to mention the system you’re working on, we’ve all run into issues we didn’t see coming. And when it’s plain sailing, what if you get interrupted – or asked to do something else before you’re ready?

In looking to understand more about why estimation is hard, I came across an article that’s well worth a few minutes of your time – “Why are software estimates so hard?” (codebots.com)

A couple of takeaways from that post. Firstly, humans can be overoptimistic. Secondly, while too much pressure can affect quality, a lack of any time pressure can do the same. I find this very interesting. With no pressure at all, there’s no urgency to finish the task at hand.

With that in mind, I’d like to talk a bit about setting due dates for tasks.

From waterfall to Agile

Setting dates reminds me of the days of waterfall project management. Microsoft Project plans with tasks leading into other tasks. Everything was mapped out as a dependency, with tasks linked to other tasks. A lot of a Project Manager’s day seemed to be spent fiddling with dates. The requirements were given a block of time at the start. Design was given a block after that. Then development. Then testing. All as big blocks, and never overlapping. Things overran, and testing got squeezed. Then the whole project goes live in one big chunk. No wonder so many IT projects of this nature overrun or go wrong when they go live.

In Agile, there’s a much more fluid way of working. We maintain an ordered backlog of digestible chunks of functionality (stories). When the team is ready to pick up a new task, the topmost item from the backlog gets marked as “in progress”. When it’s done, it moves to “Done”. Rinse and repeat. We’re free of the shackles of Gantt charts and looming deadlines. We’re no longer doing all of the development as a massive chunk, and then throwing the entire project to the testers. We’re able to discuss things when picking up a story, instead of being told that the spec is signed off and can’t be changed. And we’re no longer deploying an entire project in one go. (Well, most of the time.)

However, when a stakeholder wants something that’s important to them but you’ve got a bunch of other super high priority tasks in the way, the stakeholder may end up waiting a while for their request to be worked on.

Inevitably, you’re going to be asked a deceptively tough question: when will this get done?

And when your backlog is feel a little… well, backlogged… it can be difficult to see when a specific request will land.

Getting estimates in place

The first step is keeping an ordered backlog. Not the whole thing, mind you. I aim to keep the top 10-20 items in order – especially if they’re medium or large in size. This means you’re not needing to think about where potentially 100+ items fit into an arbitrary plan.

When things are near the top of the backlog, this is the time to talk to the team about details. Help the team understand what each task is about. If you can’t explain it yourself, bring someone in who can. Make sure the task has a clear description – and add to it as needed.

When the team understands the task at hand and has started thinking about how to do it, the team should be able to estimate the task. Whether you use story points or t-shirt sizes, getting a size relative to the other items in the backlog can be highly valuable.

But we’ve still got that question to answer. When will this be done?

Setting a due date

Let’s be clear here. I do not advocate setting a date for every task. I don’t see much point in setting dates for small tasks or most things that will comfortably fit inside a week.

But I do see some benefit in agreeing a target date for high priority tasks where there’s a degree of uncertainty, or where the work is big, complex, or risky. The key here is collaboration with the team – agreeing a sensible date with them – and not imposing one (unless there’s a legal deadline, for instance).

Dates come with a strong caveat. They are not guarantees, and should not be widely shared. The team should not be held to account if they miss a date by a day or two. If this is done, the team will lose trust in the person holding them to account, and future estimates will be inflated to compensate. If this then leads to estimates being reduced to reach a “true estimate”, trust will erode further.

Don’t fall into this trap. Instead, dates should be used as a gauge to determine if a task is on track, at risk, or off track.

For example, let’s say the team has estimated a task as a Large. They will be able to start the work on Monday 1st February. A sensible target date is suggested as Friday 12th February. Daily standups (or whatever method you use for keeping in touch) can talk as normal about how things are going. As the target date approaches, how confident does the team feel about delivering the task?

Without any form of date, large tasks can roll on and on for some time. Having some kind of milestone, or checkpoint, gives you something to aim for.

Why not just use Scrum?

This crossed my mind as I was writing the last couple of paragraphs. You could add some structure by working in a 2 week sprint. Then you always have a recurring date you’re aiming for.

I think Scrum can work well for teams who are new to Agile, who lack structure and want some, and for some types of projects. For mature teams, or where there is a high degree of variance in the type and length of work, Kanban might be better.

Scrum might work – but I don’t think it’s the only solution.

In summary

Setting dates for software development tasks needs to be done with careful consideration. Estimation is hard, and dates should not be taken as a guarantee. Holding a team accountable for a wrong estimate can lead to a loss of trust.

Instead, use dates in collaboration with a team to help them determine whether a task is on track, at risk, or off track – and work with them to find ways to help out when things do go off track.

Because sometimes – they will.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

A team’s Agile board contains all of their work. It should be possible to look at the board to get a sense of what’s happening, such as the status of tasks, who’s working on what, and what’s been completed so far.

If the board is the master source for keeping track of how things are going, then everyone in the team needs to agree to keep it updated. The most basic steps are:

• When a task is started, the person working on it self-assigns the task and moves it to “In progress”.
• When a task is finished, the person marks the task as completed and/or moves it to “Done”.

How to do these will vary depending on the tool you use, but the basic approach should be the same. You’re making it possible to distinguish between tasks that are not started, tasks that are being worked on, and tasks that are done.

This clarity is important for a number of reasons:

• It stops two people picking up the same task.
• It helps when there are dependencies, as you can see when a dependency becomes unblocked.
• It can help to surface work “not on the board”. If there no tasks assigned to a team member but they’re still working on something, that might be a sign that there’s a ticket you need to add to your board.
• It allows the team to see at a glance how much they currently have in progress at a time. When there’s a lot of work in progress, sometimes it might be better to help someone finish an existing task than bring another new task into the mix.
• It allows a Product Manager, Scrum Master, or Team Lead to assess whether something is “stuck” in the process, i.e. it’s been in progress for a lot longer than planned.

Getting more detail on work in progress

Being able to see what’s in progress is very useful. However, “in progress” isn’t always enough information on its own. While many teams are happy with a simple Kanban workflow (To do – In progress – Done), when working on larger tasks and larger teams, you may find yourself wanting more detail.

Posting notable updates on the ticket as a comment makes it easy to get more detail on how a task is progressing, beyond “it’s still in progress”.

Comments help the team in many ways:

• Comments can be a great “single source of truth” for a task, so you don’t have to remember every update from the daily standup, or find every relevant comment on Slack.
• Did a conversation turn into “let’s have a call”? Make sure to record the outcome of that call in a comment.
• If someone is off sick or goes on holiday, being able to refer to their last update on a task is extremely helpful. It can also be a good way to remembering what happened before the weekend.
• If a task is blocked, you can add a comment to say why it’s blocked, and point the team to it. Once the task is unblocked, you can add a further comment to say when/how it was unblocked. Don’t leave the team to guess why something’s blocked.
• If a task is taking longer than expected, that can also be called out in the comments. Perhaps there’s an unexpected issue, or the task is much bigger or much more complex than initially thought. Or maybe there’s another task that needs completing first. All of this can be written in the comments.

In short – you should be able to glance at the board and see what status any task is in. And if you go into the comments section, you should be able to find out the latest status on a task that’s in progress. Having conversations to find this out is fine – but it’s better to minimise the amount of times you need to say the same thing. Save yourself some time – make the ticket the single source of truth, and make the board reflect reality.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021