Using Ossum Cards and Labels Effectively
Critical to the success of any software development project is the ability to parse the project into manageable deliverables and to manage those deliverables. One of the cornerstones of Agile is to break down work into manageable pieces and focus on delivering value in small increments. Kanban is one of the most popular software development methodologies for dividing deliverables into smaller units of work and assigning them to developers.
Whether you use this software development technique or some other method, a basic premise is that all members of the team should know:
- What they are working on
- The relationship between their work and the work of others
- The progress made on that work
Boards and Cards
The ossum planning board is a Kanban-style board organized with columns and cards. The figure below shows how ossum uses cards to organize work.
Each card on the board represents a piece of work on the Shipyard project. Organizing the cards into columns indicates the stage of work (Backlog, Development, Done, or Archive). The titles of these columns can be altered to suit whatever structure you choose for your project. You can also add additional columns to meet your organization's needs.
Each card represents a piece of work. Cards are formatted to include features such as:
The description is simply a description of the work to be done. Generally, this is a short, high-level explanation of the contents of the card displayed on the board. The owners are people who are assigned to do the work. Each card can be expanded to display more details of the work. You can add notes and attachments. You can also provide a checklist of steps to be completed. The status of the items on the checklist are summarized and displayed on the top level of the card.
Cards and Labels
Ossum’s use of labels is a powerful and flexible feature that allows you to tag, sort, and filter cards based on selected characteristics. Although ossum leaves the choice of labels to the user, some probably should be considered for any software project. These include:
These labels can be color-coded or use emojis for easy recognition on the board. Ossum provides a wide variety of colors for this purpose. You can use labels to indicate a category of work. For example, some work may be performed off-shore or by an outside consulting group. Ossum allows you to tag these with labels.
Even in relatively small projects, the number of cards expands rapidly, and the board can become cluttered. Ossum provides the ability to filter the cards by any number of labels.
For example, suppose you want to view only bugs. You could filter the board to view only the items with a "bug" label. You might want to drill down further to see only the critical bugs. And then only the critical bugs that are behind schedule. Once you set up your labels, you can easily filter on them.
One tip to point out is: avoid the temptation to use compound labels, such as "critical-bug". Although this may be expedient for a given situation, it leads to a combinatorial explosion of the number of labels required. It may limit filtering flexibility. Instead, use two labels like "bug" and "critical" to convey both type and importance.
Another example involves using labels along with the developers assigned to a card. You may want to see how many critical bugs were being worked on by Amy, and her team made up of Chris, Pat, and Jo. Ossum allows you to filter on "critical", "bug", Amy, and any member of her team. You can also see the other critical features assigned to this group to balance their workload.
To focus on a particular group of cards, you can employ the concept of the Epic. Epics provide another grouping mechanism for cards in ossum in addition to the sorting and filtering capabilities of labels. An Epic is a group of cards related to the same deliverable or strategic theme. They provide the user with the ability to combine cards and understand how they work together as a group. The ability to group cards into an Epic helps the user to focus on given features and functionality of the project.
For example, Epics may contain the cards related to an onboarding experience: importing work from an external service provider, set up an example planning board, provide documentation and getting started guides, and fixing issues prior to launch. All of these fall under the same Epic even though the work may be done by different teams.
Integrating labels and Epics into your workflow means you can quickly zero in on the crucial information about the status of a project. It can help a manager understand the overall status and work distribution. It can also help a developer understand who is responsible for a deliverable that is a prerequisite to a card for which they are responsible. This ability can help them determine work priority and limit downtime.