Table of Contents

• Why do you need good boards?
• The boards
  • 1. Development Board - Our main tool
  • 2. Triage Board (Found new issue?)
  • 3. Releases Board - Looking ahead
  • 4. Team board - See less, do more
  • 5. User board - Your “first thing in the morning”
  • 6. Planning Board - cooking the next step
• Summary
• Further reading

---

Why do you need good boards?

When starting a new product/project we usually begin with managing a small number of short lived issues (bugs and features) while using our favorite a task manager: JIRA, Gitlab, Github etc’, the flow usually goes like this:

Open -> To Do -> In Progress -> Done

The team finishes most of the tasks on board every week, new features are released to customers, life is sweet. And then..the product grows.

As it happens the number of issues grows along with the people working on it. It’s no longer 10 issues per week but more like 50 and 100, 200, or 500 more waiting in the backlog.

In this situtations one of the two can happen:

1. Issues fatigue - You stop opening new issues or start documenting them very poorly. Communication is becoming verbal (inside the room) or via slack, prioritization is according to who is shouting louder or uses better emojis.
2. Issues overflow - You open so many issues you stop keeping track of them. It’s not clear what needs to be done and selecting the next important ones is nearly impossible. Sometimes you find issues from half a year ago with the title “Screen crash when clicking”.

As communication goes down you also do and plan less and pay the price in lost time and energy for you and your team, luckily this can also be averted and solved before it causes too much damage.

Over the past years of consulting companies as well as managing on my own projects I’ve found six types of issue boards which helps dealing with both these problems, especially when the team grows but also right from the start.

Using some or all these boards will keep your team efficient and happy, allowing it to focus on the important things first and grow both in velocity and efficiency.

So here goes, the magic six:

The boards

1. Development Board - Our main tool

(Other names: “Iteration Board”, “Standup board”, “Cycle board”, “Current Version”)

This is the most common and primary board which you probably already know. It’s basically a KanBan board (drag issues from one column to another) which can have the following columns:

1. Open - all the issues
2. To Do - issues select to be done in the near future (for example: this week), sorted by prioritization from top to bottom
3. Doing - What is someone working on right now
4. Closed/Done - closed issues.

Nothing fancy, but you can pull some tricks with it:

1. If you can apply an iteration/milestone/version filter and limit the scope of the board it will reduce the amount of noise and can be used to on standup/weekly meetings.
2. Some more useful columns:
   1. In Review - issues needs to be reviewed
   2. Ready for merge - issues past code review, ready to merged to their target branch
   3. ** QA / Product Testing / Verification** - past merge, ready for product evaluation
   4. Blocked - issues stuck due to technical difficulties etc’
3. In some systems (for example Gitlab Premium) you can limit the number of issues allowed in every board, this is useful in order not to overblow the board and create a smooth pipeline.

2. Triage Board (Found new issue?)

When finding a new bug or ideas to new feature it’s easy to just open an issue and start working on it. Sounds great right? But if you add too many issues and just start just working on anything you see it’s very common to begin focusing on the wrong things:

Would you fix a wrong color in button before fixing a crash in production? guess not

This where triage board comes handy:

Triage is a medical termination where you evaluate and sort patients according to how severe their state in order to determine - who to treat first.

So this is how triaging works in dev:

1. Found new bug / have a new idea ? Great! open an issue and..do nothing.
2. No, really, do nothing. I know you want to.
3. Sometime (or few times a day/week) you’ll go through new issues on the “Open” column and prioritize them to the different columns of low pririoty, medium priority, high priority.
4. Found something you have to do? move it to the “Development” board above.

Some more points:

1. At first this is very counter intuitive - not doing nothing? but as the number issue grows you can see the value in focusing on the “Development board” instead of context switching to new issues all the time.
2. This board works closely with the development board and they complete each other by adding the most important things to do but.. according to what matters most.
3. Sorting the new issues can be done in more than one way:
   1. Priority - how important is the issue? (when should it be handled)
   2. Severity - how bad it affects the system? (mostly reverent to bugs)
4. There can be exceptions - when finding extremally critical bugs or features which much-have then it’s good to start them right away.

3. Releases Board - Looking ahead

Other names: “Versions board” ,“Roadmap board”

This board simply let’s you sort the issues by time. It can be done in several ways:

1. Sort by the next version: 1.0, 1.2, 1.3.1 etc’
2. Sort by iterations: Iteration 1, iteration 2, iteration 3, ..
3. Sort by months: January 2022, February 2022, …
4. Sort by quarters: Q1 2022, Q2 2022, …

Some tips:

1. You can have more than one release board at once, The more you know, the better you’ll understand if you need to sort by versions, months, weeks etc.
2. It’s good to add a “special” Backlog version which means “Not sure which version is it now”, then by going through it you can plan ahead from a pool of left issues.

4. Team board - See less, do more

This is actually the same “Development” board only with a different change..it holds a smaller version only for a single team. It’s the same board only with a **“issues type” **filter

For example: mark all “devops” issues with a devops issues, then if you want to look how the devops team current/next issues looks like apply the “label == devops” filter:

5. User board - Your “first thing in the morning”

Other names: “Personal Board”

Very similar to the previous board - this board is the same “Development” board only with a filter added to it: the assignee to the issues is - You.

The first thing I do every morning is check my user board, if you follow through and use the “Development” and “triage” boards you’ll always have tasks ready and prioritized from top to bottom:

Want to know what everyone else is doing in the iteration? go to (zoom out) “Development board”

6. Planning Board - cooking the next step

Other names: “Next cycle”, “Next Version”, “Product board”)

This board is in charge of the “Next version” or “Next cycle” and holds all the steps required to go from “New issue” to “Issue ready to be transferred to the team”, some good steps that usually done here:

1. Product Specification - Create a product document which describes what to do
2. Design - Add UI/UX mocks or ready design
3. Technical Design - Break the product requirement + design into smaller dev tasks
4. Ready for dev - The issue is ready, schedule it for the current/next iterations or assign it to a developer.

Summary

That’s it, I hope these boards will help you and your team to organize and scale easily.

Final points:

• You probably don’t need all the boards at first try some and grow according to your needs.
• Are they the perfect ones? nope, I’m sure there are much more variations, this were those which worked for me and my needs and grew over time.

Good luck!

Further reading

1. Gitlab’s product development flow
2. Gitlab Engineering handbook