Skip to main content

Routines for working with Kanban

Example of a Kanban board that follows the routines described in this document: Riksarkivet – Ny webbplats → Backlog utveckling

Kanban board columns​

Inkorg (Inbox)​

Cards in the inbox are not yet ready for work. These are ideas, bugs, or other tasks that need to be processed and prioritized before work can begin.

Backlog​

Cards in the backlog have been prioritized but are not yet ready for work. These cards need to be prepared with the necessary information before work can begin.

Förbereder (Preparing)​

Cards in the Preparing column are being prepared for work. This includes adding necessary information, creating acceptance criteria, and defining scope.

Redo för arbete (Ready for work)​

Cards in the Ready for work column are ready to be picked up by a team member.

Whitespace jobbar (In progress)​

Cards in the In progress column are being worked on by a team member.

Whitespace testar (QA)​

Cards in the QA column are ready for or currently being tested by a team member.

Kund testar (UAT)​

Cards in the UAT column are ready for or currently being tested by the client.

Whitespace fixar (Fixing)​

Cards in the Fixing column have been returned to the team for further work.

Redo för deploy (Ready for deploy)​

Cards in the Ready for deploy column are ready to be deployed to production.

Klart (Done)​

Cards in the Done column have been deployed to production.

Kanban card lifecycle​

Prepare for work​

  1. The card is moved from the inbox to the Backlog and put in priority order by the client or by a team member in agreement with the client.
  2. One or more user stories are added to the card. They should be on this format "As a [role], I want [goal], so that [reason]".
  3. Acceptance criteria are added to the card as steps. They should be phrased as statements that will be true when the card is done, e.g. "The form is submitted when the user clicks the submit button".
  4. Links to Figma designs, screenshots, or other relevant information are added to the card.
  5. If preparatory development has been done on a Git branch, a draft PR is created and linked to the card.
  6. The card is moved from the backlog to the Preparing column.
  7. UX/UI designer is assigned to the card.
  8. The card description is reviewed by the UX/UI designer so that it coresponds with their intent.
  9. UX/UI designer comments on the card if there are any issues with the design or if there are any missing details.
  10. The card is moved from the Preparing column to the Ready for work column.

Work on the card​

  1. A team member (author) picks up the card from the Ready for work column by assigning themselves to the card and moving it to the In progress column.
  2. The author creates a new branch from the prod branch unless there is a draft PR that can be used. (see step 5 in Prepare for work)
  3. The author works on the card until it is ready for QA.
  4. When the card is ready for QA, the author creates a PR (or removes the draft status on the already created PR) and assigns reviewers if appropriate.
  5. The author merges the branch into the dev branch and makes sure the changes work as expected in the UAT environment.
  6. The author prepares a page in the UAT environment where the work can be tested and adds a link to that page to the PR.
  7. The card is moved from the In progress column to the QA column.
  8. The author removes themselves from the card.

Quality assurance​

In this step the card is tested by one or more other team members (reviewer) and by the UX/UI designer (if applicable).

  1. A team member (reviewer) picks up the card from the QA column by assigning themselves to the card.
  2. The reviewer tests the card according to the acceptance criteria locally and/or in the UAT environment.
  3. The reviewer makes a review on the PR.
  4. The UX/UI designer is assigned to the card and given instructions on what to test.
  5. If the PR is not approved or if the designer requests changes, the author of the PR makes the necessary changes and the reviewer and/or designer test the card again.
  6. When the PR is approved by reviewers and the UX/UI designer, the reviewer and designer remove themselves from the card. The card is then ready for testing by the client.

Client testing​

  1. The author moves the card from the QA column to the UAT column.
  2. The author adds test instructions to the card and alerts the client that the card is ready for testing.
  3. The client tests the card in the UAT environment and adds comments to the card if there are any issues.
  4. If there is more work to be done the card is moved to the Fixing column.
  5. The card stays in the Fixing column until the client has approved the changes.
  6. If the client requests changes that are outside the scope of the card, the team creates a new card in the Inbox column, or asks the client to do so.
  7. When the client has approved the changes, the card is moved from the Fixing column to the Ready for deploy column.

Deploy to production​

  1. The PR is rebased on the prod branch if necessary and then squash merged into the prod branch.
  2. The card is moved from the Ready for deploy column to the Done column.