Introducing KAISER

KAISER is a new app concept I’m working on to help me manage my software projects. I’ve never had a particularly good time of it with traditional project management tools like JIRA in the past. I’ve always tended to opt for simpler apps like Trello and GitHub Issues. While I do love both tools, when it comes to planning and organisation of medium-to-large software projects specifically, I keep feeling like there is something missing.

So I decided to make my own. It looks like this:

And here’s a little GIF showing it in action:

On the surface, it’s very similar to Trello. What you see above is a board, same as Trello. The little white boxes are Cards and they live in Columns, same as Trello. But there are some fundamental differences too, specifically:

• You can have multiple rows in KAISER, called “lines”. Each line represents a component of your project.
• Each line has a fixed set of columns representing workflow (Todo, Doing, Blocked, Review, Test Ready, Testing and Done). You can’t move the columns around and you can’t add new ones. This is intentional.
• You can open a card to see more detail just like in Trello. The difference is that all cards in KAISER always include two fixed checklists — one for development todos and one for bugs that crop up during testing. Back on the board, the cards show the totals for both lists in little badges and these can be used as progress indicators to show the status of each card’s development and testing.

The general idea is to show as much information about the project as possible. From one quick glance at the screenshot above, I can learn a surprising amount about the project — maybe not the specifics, but I can certainly get a good idea of the bigger picture.

Here’s the screenshot again, a bit bigger this time:

So, let’s assume I have never seen this board before. From a quick glance, I can find out the following information about this mysterious project called Kaiser:

• I know there are four main parts to the app — the Board Page, the Card Page, the Activity Sidebar and the Filter Sidebar.
• I know the Card Page is considered complete because the title includes “(10/10)” and it’s green — a subtle but helpful visual hint that draws my attention to it.
• I know there has been a lot of work on the Board Page because 13 of its 17 cards are done already.
• I know there is a bug in the Board Page because the card in the Todo column has a brown bug icon next to the title.
• I know that a user called John is currently testing two cards for the Board Page.
• The Board Page has a card called “Set Board Title Button” which is currently in progress, but I know all development is complete because of the green badge which tells me there are two finished todo items. I can see there is one outstanding bug which means there was probably an issue during testing, and the assigned developer (Paul) is working on fixing it now. I can open the card and examine its details to confirm this, but often just getting the general idea of what’s going on is enough.
• I know that two sidebar components are planned, but development has not started on them yet.
• I know there is a problem with the Activity Sidebar component as there is a card in the Blocked column. It’s not easy to see in this example, because the column is collapsed but if you look carefully, the counter shows there is one card in the Blocked column.

Information overload

Having access to this much information at a glance is very useful when you need a big picture view of the project. But sometimes you just want to focus on one or two things, right? Developers like me, for example — and probably testers too — are usually focused on a specific component or even a specific card. Because of this, KAISER provides various ways to hide information you don’t care about right now. For example, if I am working on a specific component, I’ll just collapse all the other lines and the board will look like this:

For me personally, this is my default set-up. I switch between lines often, but I always have the one I’m currently working on expanded, and get rid of the ones I don’t care about right now. But if this were a bigger project with Product Owners, Scrum Masters and managers involved, I suspect they would prefer to see the bigger picture view by default.

Another way to reduce the level of detail is to collapse individual columns within a line. As you may have already noticed, the Blocked and Review columns are collapsed by default in KAISER but you are free to collapse any columns you don’t use regularly. For example, as I am the only developer on this project right now, I often just skip testing when I am messing around with UI ideas, so I sometimes have the board set-up like this:

Finally, if you just want a general overview of the project without any detail you can collapse all lines and turn on the Line Summaries, which gives you a view like this:

Here, the board displays summary information alongside each line representing the card counts for each column. For non-empty columns, the count shows up white to highlight the areas where there is activity. Also notice the Blocked column is red in order to draw attention to anything that is blocking progress on the project. Very useful!

Card Details

When you click on a card, it opens up to show you more details about the card, including comments, who is assigned, etc:

Notice there are two checklists, Todos and Bugs. The Todos is where developers breakdown the card into individual mini-tasks that all need to be finished before the card itself can be considered complete. The Bugs list is primarily for reporting issues during testing but of course, bugs can crop up during development too. Notice how each todo/bug can be individually assigned as well.

It’s useful to keep the two types of mini tasks separate because — as we’ve already seen — the totals are shown as card badges on the board to provide a quick indication of development/testing progress.

KAISER is opinionated about workflow

When you start a project with KAISER, you begin with an empty board. You then create a Line for each main component of your project, then try to break down each component into cards as best you can. But it can be tricky to know exactly what a card should represent. if you make it too high-level (like “Implement Board” for example) then it’s too vague to be useful. On the other hand, if you make it too detailed/specific then it might alienate some members of the team.

With KAISER, I like to try and remember the following guideline when creating cards to help me get the granularity right:

A card should describe something that could potentially be demoed to the customer.

So rather than naming a card with something like “Implement server-side message broadcast for propagating card changes” which — besides being way too technical — would not be easy to demo to the customer, something like this would be much better:

When card properties (such as title) changes, it should also change in other running instances of the app.

Of course, this might not sound much better for anyone unfamiliar with the project! The point is — it describes something tangible that can be tested and demoed, and anyone familiar with the project will understand the basic idea behind it from the title alone.

Once you’ve figured out what cards should represent, you need to know where to create them. In KAISER all cards are stored in columns and there is a fixed set of columns for each line. Each line represents a main component in your app. When you create a line in KAISER it will always have the following columns:

• Todo
• Doing
• Blocked
• Review
• Test Ready
• Testing
• Done

All cards generally start out their existence in the Todo column, and developers move them to Doing when they start working on them. If there is a problem that affects progress, the card is moved into Blocked so everyone is aware that the schedule/deadline may be affected. During development, the Todos will gradually be ticked off and anyone viewing the board will be able to note the progress by checking the card badges when looking at the board. Once all todos are complete, the card can be moved into the Review column, then once everyone is happy with the changes, it is moved into the Test Ready column.

At this point, whoever is responsible for testing will be notified the card will be assigned to an available tester. The tester then moves the card into the Testing column and if there are any issues during testing, they will be added the the Bugs checklist. Once testing is finished, if the card does contain some bugs, it will be moved back into the Todo column. At this point, everyone on the team can see from glancing at the card badges that this card is development-complete but has failed testing.

The developer moves the card back into the Doing column, fixes the bugs, then goes through the test workflow again but this time there are no bugs so the card can finally be placed into the Done column. Yey!

Throughout all of this, KAISER is recording each change in the activity log, so there is an audit trail of how many times it failed testing, how many test issues there were, who worked on it and for how long, etc.

Priority is Visual

By default, columns are rather short in KAISER, meaning only the top three or four cards are visible at a glance without scrolling. Of course, if you are focusing on one single line you can expand it for convenience to make the column much taller, but in general, when you are viewing the entire board at a glance, you will see a reduced view of each column, like this:

This is a good thing! By limiting the amount of available space, it forces you to think about priority differently. Often, I find myself moving cards that I didn’t think were high-priority to the top because I want other members to see them first as soon as they open the board. I’m prioritising without even realising it.

I think that’s everything covered

KAISER is just a concept at the moment. I’ve put together a basic prototype to try it out these ideas. You can try it if you like here:

KAISER

It’s very basic right now and it only works locally (all data is persisted to local storage) but it’s enough to give you an idea of how the real app could work.

If you like the idea/concept, or have any general feedback, please add a comment below or you can contact me directly at paul.drummond@iode.co.uk.

Thanks for reading! :-)