My workflow

Principles and policies I use to organize my tasks. It also includes my own way to handle a kanban board which uses an interesting approach, the metadata.

If you are a SCRUM master or have some knowledge about Project Management you may found this article naive. It is just my personal approach to this topic. Anyway, any feedback is welcome.


Let’s start with some principles I came up with.


A quote from Leonardo:

Simplicity is the ultimate sophistication.

Self improvement

A set of management policies is successful if it evolves itself effectively.


Policies definitions should be placed into the system they are describing.

In software development, few years ago it was used to put tests in a tests/ folder. Recently the best practice is to place tests near the related code. For instance, if code is located in file Foo.js, then tests are placed in file Foo_test.js. This has several advantages, in particular it makes easier to access test code.

This concept is sometimes also named co-location.

I copied this idea and applied to Project Management: defining policies about a board using cards, makes it easier to read and update them.

It happened so many times that I start working on a project, there is some documentation but many of the links are broken.

Usually the Backlog (see below) is not a board column. Some SCRUM masters even may hide the backlog to developers and make it accessible only to the Product owner. This could have some pros but I think that the Proximity principle helps a lot. I have seen many projects with a huge and outdated backlog, full of duplicates.

An article that also inspired me and influenced a lot, regarding this principle is Readme Driven Development by GitHub founder Tom Preston-Werner. The START HERE card on top of the Metadata column described below, could by also named README; or on the other hand, the Metadata column could be considered as the equivalent of a file in a git repository.

Kanban board

Kanban is a method for optimizing the flow of business value through a process that uses a visual, work-in-progress limited & pull system.

Kanban allows the Team working on that workflow to reach a sustainable pace that it could be guarantee indefinitely.

You can use any tool that implement the Getting things Done method board. For example Jyra, GitHub projects or Trello.

See this is an example on Trello: it implements the board described below.

Metadata column

Following the principles above, my idea is to create a Metadata column that contains all the information needed to manage the board.

Metadata should contain at least one card for each of these topics:

Follows an example of cards you can start with.


This is the first card of a board.

A board is a set of columns. A column is a stack of cards. A card contains information.

The cards below contain information about this board and the process to manage it.


A card has a titleand a description.

A card can have one or more labelsto categorize it.

A card can contain a story.

A story is a short, simple description of a feature.

Card content can be written with markdown.


Read columns from right to left, from top to bottom.

Card vertical order matters: it is an information about the card.

List of columns

  1. Metadata: information about policies and guidelines of this board. Cards in this column can be moved only vertically. Cards in other columns can be moved vertically and from left to right.
  2. Backlog: stories are created and refined here. The more it is refined the more it is moved on top.
  3. To do: contains stories ready to be processed. Stories with higher priority are on top.
  4. In progress: stories that are currently developed.
  5. Done: features that are deployed to users. To be observed and measured. Latest releases are on top.


This special card has all labels attached.

List of labels

  • Bug: describes a mistake or problem to be solved. Usually they have a higher priority.
  • Nice to have: a story that provides value but it is not critical. Usually they have a higher priority.


Card content in the Metadata column could be changed or updated. It will also reflect on the board items and content, of course.


There could be a different set of columns, according to the development stages. For example there could be a Ready to test and an In production column rather than a single Done column.

WiP limit

It is also used to set a limit to the number of cards in a column. For example you may use this definition of the In progress column.


There could be additional labels, for example:

There could be also a different set of labels if the team agrees on that, but I would recommend to keep Bug and Nice to have labels.

There could be a different set of columns.

Blocked stories

Another concept you may need is to highlight blocked stories. This can be done with a Blocked column which is usually placed before the Done column.

Notice that in the Columns card, the first statement is: read columns from right to left


Yes, from right to left: exactly like a manga! This is because you should first see which stories were done, then which are blocked and then the other cards. Avoid blocks in the flow is one of the main goals of management. It is also a good idea to set a WiP limit on the Blocked column.

But you could choose to achieve the same goal in a different way. For example there could be a blocked label and cards that are In progress but blocked could be placed on top. This is a method I never seen in any project but it is more coherent with the principle used by many SCRUM masters:

Cards should be moved only from one column to a column to the right.

Again, I discovered this policy after few months I was use using SCRUM. It was not written and implicitly assumed by the SCRUM master. This is way the Metadata column is important. And by the way, that day the SCRUM master was in vacation and the Product owner moved a card from left to right telling us that it was an exception and should not be done. LOL!

Metadata cards

There could be other cards in the Metadata column, for example:


An epici s a card with a check-list. Every item of the list references a card.

Epic life-cycle

  1. Add an item for every task to be done.
  2. Do not move the epic to the In progress column.
  3. Create a card for every item in the check-list.
  4. Replace the item text with a link to the card: the card title will be displayed.
  5. Once the related story is done, flag the related check-list item.
  6. If all items in the check-list are done, move the epic to done.

I am a big fan of Markdown, and also was humbled to meet in person one of its creators: Ingy döt Net. But many people do not know Markdown. You may want a add at the bottom of Metadata column a card like this:

Markdown example

# Card title

This is a paragraph.

## Section title

This is __bold__. This is *italic*.

- list element 1

- list element 2

- list element 3