Which columns exist on your task board?

Question

Currently, we’re implementing new processes at our company essentially from scratch, but there are a lot of opinions on which columns should be on the task board. As the one responsible for this effort, I’m a bit stuck on which columns are absolutely essential and which could be added later if proven necessary. My goal is to keep things as simple as possible in the beginning.

We (PM team) started with:

| TODO | IN PROGRESS | IN TESTING (QA) | DONE |

But then the engineering leads insisted that a CODE REVIEW column must exist between IN PROGRESS and QA. That said, I think there’s merit to that argument , and I started to wonder what else we might’ve missed. I’d love to get more data on what other PMs use as columns on the task board.

Answer 1

This is a great question. Many teams start with something like what you have or ToDo | Doing | Done. This may be ok, but doesn't tell you much about how your work is flowing. If you want more visibility into your process, you may want more columns, but which ones?

Unfortunately, there is no "right" answer. As a PM team, the first thing you'll need to understand is that you can't standardize this. Different teams work different ways and need to see different things, so different boards will be... well, different.

To get a truly useful board, you want to start by facilitating a process mapping session with your team. Ask them to draw on a whiteboard how they get from "I have an idea about a feature" to "You can use this feature now". You can visualize it any way you want, but I find basic flowcharting is the most common. Next, ask them which steps are most valuable to pay attention to. These might be because they are major steps or because they are risky. There's no right answer and they can change their mind later. Those become your columns. Now, as work flows through the process, the board visualizes that flow.

In your question, you ask which columns are essential. Some starting column titled something like ToDo or Not Started and Done are the only essential ones. Everything else is based on the flow for your work.

Answer 2

Based in my experience, the shortest answer to start is the two basic (to do / done) plus one for each team.

A single team covering a task from start to end would have then the three main columns, i.e. to do / in progress / done.

In your scenario, is the same person doing the task and the code review?

• Yes: so why having different columns? Just to see the task progress? You should measure progress differently... maybe based on the remaining work (burndown chart, for instance)?
• No: so different columns to identify them, this way each team know when to pick more work.

Notice that you should refrain from adding more columns. At some point, someone will say "look, we need one column ready for code review and other in code review". Same may happen with testing. You may end up with a board with several states.

As Daniel mentioned, it'll all depend on what works for you and your team.

Answer 3

Daniel's answer says it all really, but some column headings I have seen are:

• Product Owner review
• In UAT
• Ready for retest
• Blocked

Answer 4

After multiple rounds with experimentation with different columns based on our process, we came to the conclusion that no amount of tinkering with the specific columns could beat proper communication with each other, so we cut it back down to only "Backlog", "In progress" and "Done".

Now we just learned to communicate so much as a team that everyone is pretty clear on the exact state of a ticket, and we track progress on the card directly.

(There's a simple process checklist on each digital card, but it's mostly to keep remote people up to date.)

Answer 5

Our product manager used to work with whiskey so it's themed like so:

Preparations | Fermenting | Distilling | Aging | Bottling

Answer 6

Some ideas from past experience:

1. A sub-columns for the individual teams so as to make the In progress column more meaningful. E.g:

^{| TODO |          IN PROGRESS       | IN TESTING (QA) | DONE |
|             | ProdOps | FrontEnd | BE |                              |             |}

---

2. Depending on your team structure, you may want to add a "In Debugging" column; other times you may want to move it back to In progress.

^{| TODO | IN PROGRESS | IN TESTING (QA) | DEBUGGING | DONE |}

---

3. A "Waiting for Approval" column; when a lot of pieces need to come together, it can be past QA (First Round) but not Done until related components are done, and QA approves the entire sub-system.

^{| TODO | IN PROGRESS | IN TESTING (QA) | WAITING FOR APPROVAL | DONE |}

Answer 7

Something to keep in mind:

Equally important and helpful as naming and using an assortment of columns is the entry and exit criteria for each column. For example our team has the following:

---

An item can enter the Sprint Backlog if...

1. it's Independent from other work items (not blocked)
2. it's Negotiable with product owner (business value has been evaluated/understood)
3. it's Valuable (it's been prioritized based on value delivered)
4. it's Estimated (the card has been broken down to <= 13 points of effort)
5. it's Small (can be forecasted to fit a sprint)
6. it's Testable (a test approach has been agreed upon)

---

An item can exit Development if it has...

1. Appropriate unit test coverage?
2. Appropriate automated acceptance test coverage?
3. Appropriate level of platform (Browser/mobile device) test coverage?
4. A successful build, deploy, and manual test coverage via release pipeline?
5. Appropriate localization/globalization?
6. Passing automation tests?
7. A test strategy that is completely documented?
8. Acceptable functionality based on acceptance criteria?
9. Browser compatibility with IE, Firefox, Chrome, and Edge?
10. Peer review from the team?

---

An item can exit Review if...

1. Product Owner has used the functionality in QA and has acknowledged acceptance criteria has been met.

---

Notice our team only really uses three columns, but denoting criteria for each really helps everyone understand what needs to happen in order for work to flow through the board and why it needs to happen. If you're using Scrum, think of this criteria as your definition of ready and definition of done. The above is simply an example and may not be 100% appropriate for you to use. Hopefully, though, it gives you some ideas and helps your team really understand what each column really symbolizes, however you choose to define them. If it's not working, you can always revaluate, add columns, remove columns, and collaboratively redefine their criteria to fit your team's needs.