Issue Board Configuration
Welcome to Tanuki Tuesday, where I look at the features offered by GitLab. This week I'm looking at configuring issue boards. They work alongside project and group labels to allow the creation of a board which works for your workflow.
It sounds simple (I think it is) and sounds really dull (will be for most) but one of the best and most important parts of GitLab is that it doesn't force you to work a certain way. You can configure the issue board to work in a way which fits your way of working.
If you use a Scrum methodology, then create labels which correspond to the relevant stages of a sprint, and off you go. Use something different? Create the relevant labels and add them to the board. Drag and drop the columns to get them in the right order. Really straight forward on the surface.
But what if your development team work in a slightly different way to your QA team? What if QA don't care about what is currently "Work in Progress", but only get involved at the "Verify" stage? Well create a QA board. A project can have multiple boards, each with their own configuration. On the issue boards page, select the board name from next to the filter column, and click Create new board
, set a name, and off you go. Once the columns you need are added, it's ready for use by the rest of the team.
If you are working along the swimlane paradigm, where work should flow left to right, you may be better served to use scoped labels. If the columns are set to use the same scope, then an issue cannot be in the multiple columns. Moving it from one column to another will update the issue to have the label of the new column. If this is a scoped label, the label with the original scope will be removed and replaced with the new one. As I mention in the scoped labels post, I use "Status::" as the scope for my swimlanes. An issue cannot be in "Status::To Do" and "Status::In Progress" at the same time, so setting the swimlanes to use that scope to track progress.
After "Status::In Progress" there is a column for "Status::Testing::To Test". These issues then show up on the QA board, which has the following columns:
- "Status::Testing::To Test"
- "Status::Testing::Testing"
- "Status::Testing::Passed"
- "Status::Testing::Failed"
If an issue fails testing, it will appear in the corresponding column on the development board (which has the same lane). The development team know that issues which have failed testing should be looked at before new work. A developer will pick it up and move it back to "Status::In Progress", at which point it is removed from the view of the QA team. They only see what they need to be working on, and where in their process it is. If an issue passes testing then it is the same as "done" in a traditional Scrum environment, and ready to merge.
If that's not the way you work, then you can set up the lanes in a way which works for you, or play around with different configurations on different boards until you get to a flow which works for you (and your team if required).
Conclusion
Issue boards in GitLab look sparse when you visit them for the first time on a new project because of the flexibility GitLab offers when it comes to the way of working. It would be impossible to create a default board which worked for everyone, and the multitude of workflows which are out there. Sure, it could offer a board template on projects to set up a typical Scrum board, but that wouldn't be difficult or time consuming for a project owner or maintainer to set up. I would prefer that add value in other areas (mainly because I don't use Scrum).
To get the most out of your workflow on the boards, you really need to work with scoped labels, and have the columns correspond to a scope. Moving issues between columns will update the label, and remove confusion which will arise when an issue has labels which place it in two columns (unless that is intentional). Without scoped labels, you could have an issue which has both "To Do" and "Work In Progress" labels. How would you know which it is?
Not every label needs a column of its own on a board. Not all boards will need all columns (see my QA only board example). Use the multiple-boards ability to show only the information and issues you need within that given area. That certainly beats having a single board with a dozen or more lanes. If you want that level of chaos, use Trello and allow a free-for-all! (Sorry, Trello. I've seen some awful abuses of your product).
Issue boards are there to help you work smarter, not harder. Set them up to allow you to work your way, and efficiently. Don't let bureaucracy get in your way!