• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Kanban for Launchpad

Overview

We are trying Kanban to coordinate our development process. The goals of switching to Kanban for Launchpad development are:

1. Provide slack by balancing demand against throughput

   • By slack we mean non-fully utilized resources allowing opportunities for continuous process improvements and also give the room to react without overload to unplanned events.

2. Deliver a predictable cycle time by controlling the quantity of work-in-progress.
3. Provide a simple prioritization mechanism enabling self-direction.
4. Make it possible to reserve capacity for technical debt reduction and general polish.

The two most important characteristics of a Kanban system are:

1. Vizualize the development workflow
2. Limit work-in-progress.

Organization

Each Launchpad team has a http://leankitkanban.com board set-up for them. This will be the control center of the development activies.

• Bugs

• Code

• Foundations

• Registry

• Soyuz

• Translations

Development Workflow

The board shows all the work-in-progress and its state. All boards are similar but have different work-in-progress limits based on the team size and capacity.

Analysis & Design

This station is used to track and limit the number of work at the pre-coding stage. The end goal of that station is to get the feature to a ready-to-code stage. It has two subprocesses:

1. LaunchpadEnhancementProposalProcess

2. UserInterfaceDesign

The WIP limit on this station has been initially set as the number of Feature lane available to the team.

Development

That's the station where the coding and development activities occur. It is subdivided into a number of sublanes.

1. One or more feature lane.

   The number of feature lanes has been determined based on team size / 2. These lanes are used for longer term work that will take more than one branch to complete. Here are it's subdivisions:

   Task

   This column contains the bug or feature that is used for the lane. It also acts as the backlog of the tasks (branches) that are needed to complete that feature.

   Coding

   Used for representing when a developer is working on a branch.

   Review

   Used for when a branch is in review.

   Completed

   Used to hold the merged branches. All branches related to the master feature should be in this holding area, until it is completed, at which point the branch cards should be moved to

   the Archive and the feature or bug should be moved to the QA Ready lane.

   The initial WIP on the Coding and Review lane has been set to 2. The Tasks and Completed lanes don't have any WIP limit.

2. A 'Bugs' lane

   This lane is use for defects (OOPS), technical debt cleanup and other general minor enhancement (bugs). Items in this lane should be able to

   be completed using one branch. It has the same Coding / Review subdivisions than the feature lane. Its initial WIP limit is equal to the number of developers.

QA

In this station, the development work is validated on production data. Remember that QA is done on bugs or feature, not branches.

Its initial WIP limit is equal to the number of developers.

Release

That's the station to hold stuff that is completed (available to users on edge - or ready to be part of the next release on staging) If the changes, needs to be cherry-picked, the 'Ready for CP' lane can be used. Once the item has been deployed, it can then be moved to 'Done'. An arbitrary WIP of 2 has been set on the Ready for CP lane.

WIP & Ready Lanes

Most of the lanes are further subdivided in a WIP and a Ready column. The WIP column holds the card when the developer is working on the task. Once the work related to column is complete, it's moved to the Ready column. So that it can be pulled in the next one when things start. The Ready columns are used as hands-off buffer when the item will switch owners across functional boundaries (for example, if the engineer doing the UI mock-ups isn't the one who will implement the feature). It's also used to compute the effectiveness of our process (that's the ratio between when things are actually being worked on vs the time things spend waiting for some-one to be available to work on them).

Backlog

The backlog is structure into different areas and also has limits on it. Usually a lane to hold upcoming feature work and another for defects, tech-debt and general enhancements. New work should be pulled from these when capacity is available.

It is the responsibility of the team leads in conjunction with the product strategist to fill the backlog.

Archive

The lane in this pane holds the completed items. There is a special lane called Trash or Rubbish that is used to collect items which were started but then got cancelled.

Work Item Types

There are three main type of work items.

Feature work

These are the green cards and represent high-impact user visible work.

• 

Defects

These are the red cards. They are used for OOPSes and other major bug that prevent users from accomplishing their intended task. Don't use it for minor usability improvement or other of the many "improvement bug" that we have.

• 

Improvement

These are the blue cards. They are used for tech-debt items or other general improvement category.

• 

The yellow cards are used when one of the items in the Feature lanes need to be subdivided.

Priority Mapping

We use only two priority icons for cards.

• Critical -- Critical defects should have the Critical marker set. It's ok to override WIP limits when a critical item passes through.

  High -- Items that have a due date (because of a serious cost of delay) should have the High priority. That's only to make it obvious that the item has a due date, because leankitkanban does't make it obvious otherwise. All due date needs a justification. Good reasons for having a due date are that there is a contractual obgligation or other externally imposed deadlines (for example, it needs to be done to a particular date because of a Ubuntu release.)

All other items should have the Normal priority.

Prioritisation

When choosing a next task, developpers should aim at moving things as fast as possible to the righ-hand side of the board, without violating the WIP limits.

When selecting the next task to work on, here is the prioritisation criteria:

1. Critical items should be worked on first. It is ok to override WIP limits for these items.
2. Priority should then be given to Due-date items that are coming up. Due-date items that are late should be considered as 'Critical'.
3. It's best if one started item can be moved to completion without interruption.

What if the WIP are reached?

Standup