Workflow

Workflow

Within Kanbanara, a project?s workflow is completely dynamic. It can range from something as simple as “To Do”, “Doing” and “Done” upto a workflow consisting of 12 steps, each step consisting of a main column, a counterpart column and a buffer column.

A step can be thought of as a combination of upto three state columns, Main and Counterpart holding cards waiting to be processed and the Buffer, holding processed cards waiting to be moved onto the next step. A step can be given a name such as “Backlog”, “Specify”, “Implement” or “Validate”. Each state column within the step can be given a name as well as whether it is owner-, reviewer- or quality assurance-centric. A state column?s centric setting will dictate how cards are handled when they reach the review/QA stage(s).

Metastates

Kanbanara posseses 23 built-in metastates - untriaged, triaged, backlog, defined, analysis, analysispeerreview, analysed, design, designpeerreview, designed, development, developmentpeerreview, developed, unittesting, unittestingaccepted, integrationtesting, integrationtestingaccepted, systemtesting, systemtestingaccepted, acceptancetesting, acceptancetestingaccepted, completed and closed. Any custom state you define and use in your workflow must be mapped onto the most appropriate metastate.

States

At Kanbanara?s heart is its kanban board. The states in your workflow can be altered at any time to suit your particular needs, even after your kanban board is fully populated with cards.

By default, the cards on your kanban board will be in one of the states defined in your workflow at any given time, the default being the ‘backlog’ metastate for a new card and the ‘defined’ metstate for a reopened one:

Allows a subset of consecutive states to be shown allowing you, for example, to hide Backlog and Closed as required.

Even though you have the full width of the screen at your disposal, the filter bar additionally allows you to select a range of states to be displayed, allowing you, for example, to hide Backlog and Closed as required, thus giving more room to those columns containing cards you are actually interested in.

When a card is in a Review/QA state, its owner will only get a placeholder card to indicate another is reviewing it. Reviewer role comes to the fore only in a Review column. Quality Analyst role comes to the fore only in a Quality Assurance (QA) column.

User can set a time period for the number of cards in closed state they want displayed.

If a card has both an owner and a co-owner, both a reviewer and a co-reviewer or both a quality analyst and a co-quality analyst, then setting the state must be done by both team members before the card can be automatically moved to the next state. Should a card have been moved to the next state by one team member only, the card may then appear in the column?s waiting section depending on whose kanban board you are currently viewing.

Default Steps and Columns

By Default, the workflow in Kanbanara consists of eleven steps - Planning, Backlog, Specify, Design, Implement, Validatation - Unit, Validatation - Integration, Validatation - System, Validatation - Acceptance, Completed and Closed.

Planning Step

The Planning step consists of a main column, Untriaged, and a counterpart column, Triaged.

Backlog Step

The Backlog step consists of a main column, Backlog, and a buffer column, Defined.

In the Backlog column are displayed those cards in your backlog. Normally, such cards have yet to be assigned a release or iteration. On the kanban board, such cards in the backlog state may appear in one of two locations - Either in the Pyramid section (if already put in order via the Backlog Pyramid) or in one of the Priority section as per cards in other states.

In the Defined column are displayed any cards duly defined to be worked on next, normally for a particular release (and iteration) and are awaiting their move into the Analysis state when Work-In-Progress limits allow. In Scrum terms, you can think of this column as the Sprint Backlog. Defined is a buffer state.

Specify Step

The Specify step consists of a main column, Analysis, a counterpart column, Analysis Peer Review, and a buffer column, Analysed.

In the Analysis column are displayed any cards currently being analysed.

In the Analysed column are displayed any cards that have been analysed and are awaiting their move into the Development state when Work-In-Progress limits allow. This state is the second half of the specify step. Analysed is a buffer state.

Design Step

The Design step consists of a main column, Design, a counterpart column, Design Peer Review, and a buffer column, Designed.

Implement Step

The Implement step consists of a main column, Development, a counterpart column, Development Peer Review, and a buffer column, Developed.

Validate - Unit Step

The Validate - Unit step consists of a main column, Unit Testing, and a buffer column, Unit Testing Accepted.

When assigning a reviewer to a card, the reviewer?s names are placed in order of least busy to most busy, with a card count after their name, thereby allowing the least busy team member to be more likely chosen. When a card reaches the Testing state, the owner and reviewer effectively switch roles, with the reviewer requested to work on the card and the owner a passive observer. As a reviewer, you can see what work is heading your way as such cards appear greyed out in the states preceding Testing. This state is the first half of the validate step.

Validate - Integration Step

The Validate - Integration step consists of a main column, Integration Testing, and a buffer column, Integration Testing Accepted.

Validate - System Step

The Validate - System step consists of a main column, System Testing, and a buffer column, System Testing Accepted.

Validate - Acceptance Step

The Validate - Acceptance step consists of a main column, Acceptance Testing, and a buffer column, Acceptance Testing Accepted.

Completion Step

The Completion step consists of a main column, Completed and a counterpart column, Closed.

As all cards will eventually end up in the closed state one way or another, unless of course deleted, the number of cards displayed can be restricted to those cards closed in the last five years right down to those closed within the last hour.

Why No ‘Blocked’ State?

Kanbanara has no need for a ‘Blocked’ state as a card can be blocked either by its children or via the setting of a blocked attribute on a card itself. Any cards thus blocked automatically appear in a special blocked section in the appropriate column on the kanban board, thereby allowing you, for example, to have a card in both ‘Development’ and ‘Blocked’ at the same time.