10 Different Kanban Boards and Their Context - Mskarin

1

10 kanban boards and their context

Hi!

I’ve visualized a set of kanban boards from operations, development and sales to trigger ideas. But don’t forget, a kanban board is a tool to help you think for yourself, in your context. So remember to apply the work in progress limits, policies and cadencies that is right for you.

”Never copy, only improve”

- Mattias Skarin

Dude, what’s kanban? www.limitedwipsociety.orgwww.crisp.se/kanban

v. 1.4 - 28 Jan 2013

http://www.limitedwipsociety.org/

http://www.crisp.se/kanban

2

DEVELOPMENT

Single & Multiple teams

3Mattias Skarin, 2011

Scrum team applying WIP limits

Why? To trigger a shift from a burndown like this..

Context

Scrum team

To something more like:

To do In Work Done

orem ipsum dolor sit amet, co nse

ctetur

[3]

orem ipsum dolor

sit amet, co nse ctetur

orem ipsum dolor sit amet, co nse

ctetur

Work in progress limit

Sun

Rob

Jane


Development teamusing defined process

Context

Development teamcombined with specialists

New In Dev User Test Deploy Done

[3] [3] [5]

• Has a testcase• Tag!• In CI

• In stage • Buildfile updated

• User happy!

Visible policies

WIP limit

Pro:• Polices are clear• WIP in each step• Ready buffer’s from which next stepcan pull work

Cons:• New column can get messy ifno person maintains it

In progr. Done In progr. Done Queue In progr

Ready buffer

Stakeholders:- Product owner / Project manager

Test design

[1]

• Risks identified• 1 Happy path test case

In progr. Done

A buffer is a trade-off between cycle time

and variance absorbtion


Development teamwith multiple clients

Context

Custom solutions dev team with project manager

New Estimate Done

Prod issue

[2]

Pro:• Projects and features visible• WIP in each step• Estimations can be regular /or ”on need”triggered event

Cons:• Tempting to default features to ”time constrained” (even though therereally isn’t any costly delay consequence)

In progr. Done

Testdesign

Active projects

Package

Stakeholders:- Customer A- Customer B- Other teams - Platform architects

New In Work

Code Test

[3] [3] [6]

Time constrained feature

Ordinary feature

Bug

Classes of services in use: To risk balance your portfolio, limit the amount of each category allowedon the board at any time

Fixing tech debt


Full value chain, from marketing to production

Context

3 teams specialized by architecture

Product ideas

PrioCustomerusage

Pro:• Full value chain collaboration – frommarketing to deploy• Business priorities clear from start to end• Marketing feedback at the end

Cons:• Tempting to start on ”your” stories

Solution design

Team A

Stakeholders:- 3 Business units- Release managers- Development teams

Team B

Business unit A

Business unit B

Business unit C

Color scheme

Fixing tech debt

System test

Test Readyto

deploy

Popular!

Oh crap!

Team C

Ready totest

In Development

Anyone

With sometraining

As aSpecialist

Readyfor dev

Split

To prevent stories fromidling because of skillmismatch, teams pull storiesin if they are doable by anyoneor with some training

Making it easy for businessunits to track ”their” demand


Development teamwith completion prediction

Context

Development team

New In Work Devcomplete

Pro:• Completion date visible• Learning of prediction towards cycle time

Cons:

Stakeholders:- Product owner / Project manager

Selected

Selected Dev ready

Mon Tue Wed Thu Fri

Feature

Tasks

When developer starts a taskit is placed on the day they think itwill finish. Each day, this prediction is updated.

If estimated size > 5d task is broken down further

@ Chris Matts


Multi tier kanban withswimlanes

Context

x Development teamsAnalysts, Testers

Newrequests

De-compose

Done

Pro:• Add limits all stages of the design cycle• Synchronises flow of cooperative workby specialists and generalists

Cons:• You may need a big enough area infront of the board to gather around

Stakeholders:- Business units- CTO- Architects

Active Analyze Dev Verify

Acctest

Dev in progress [3]

Features in progress [5]

Requests in progress [9]


Mattias Skarin 9

New Dev Test Done

[8] [5]

In progr Done

Analysis

[1]

80%

50%

40%

Context

Tracking of progress in overall solution, multi team scenario

Progress by architecture


11

OPERATIONS


System administration

Context

System administrator teamsupporting development and production

Prod

Done

In work

Breakdown

New

Release DevSupport

Project A Project B

Pro:• Course grained prio visible• WIP balanced across work types• Visible learnings opportunities forteam members in maintainance and project work

Cons:• Newly arrived reguests can get messy ifno person maintains it

[8]Stakeholders:- Production site- Development teams- Internal projects- Testers

Flow

Prio


Operations – onlineplatform maintenance

Context

Incidents

Next

In work Done!

Improvements(ours)

Projects

Stakeholders:- Production website- Real time data providers- 8 devteams

Flow

Pro:• Defined process• Root cause investigation own lane• We split projects into smaller parts

Cons:• WIP limits can be difficult to review

Sysadmins with specializations Support

Work in progress [10] Park Tell

Incidents – fix root cause

Split In work Done

If third partyaction is required to

finish

Show & tell ordocument

Specialization 1

Specialization 2


Operations - business process maintenance

Context

Course grained

Prio

Production problem

Plannedbusiness

need

(Low impact)

Find cause Fix causeNew Done!

In work [3]

Unplanned

Platformimprovements

New

Routine

New Committed [1]

Committed [1]

In work[2]

In work[1]

Test[2]

Test[2]

(High impact)

Due 1 weekDue 1 monthDue 2 months

Stakeholders:- Production site- Business functions- Business planning dept.- Development team

Flow

Pro:• Time and scope visibility


System maintenance team


Release managers

Context

Stakeholders:- Development teams- 3rd party software providers- Business functions

Pro:• Release overview, this and future

Cons:•

Improvement

Release

Incidents

Release management andsystem maintenance

DoneIn queue In work

Prio Content

Patch

Problem

Request

1.3.1

1.3.2

1.3.3

Prepare Test To Prod Follow up


First line support

Context

Prio

Solving

Done!

Stakeholders:- Customer developers- Customer users- Sales- Architects

Pro:• Time and scope visibility


Need feedback from client

Awaiting confirmation

On hold – get contract! Call up client

Need help from specialist

Improvements

Signal to pull specialist skill in(architects)

Signal to get or confirm client support contract (sales)

Signal to call clientup for confirmation (manager)

Own platform bugs

Customer bugs

Questions

Flow


Second line support

Context

Done

Stakeholders:- First line support- Development teams- Operations managers

Pro:• Wip limits on follow up work• Focus on one root cause at a time,stay with it until fixed

Cons:• Not all incidents can go on the board- requires size limitation or similar fortasks on the board to avoid overadministration

Painkiller[1]

Backlog

Address root cause, (one at a time)

Backlog New Investigate[3]

Follow up[6]

Done

In work [1]

High prio

”The rest”

Overflow

{ 0 }

No of new incidents not addressed(yesterday)

Wip Overflow section– Policy: Notify source

”We haven’t dropped it,But won’t be doing anythingabout this for a while. Youare best off giving it a goyourself.”


Operations with support

Context

Incidents

Support

Fix causeNew Done!

In work [15]

ProjectsNew

Incidentproject

New

Stakeholders:- Production site- Customers- Business functions- Development teams

Pro:• Defined incident process

Cons:• Too detalied board?

Investigate causeTemp fix

New

Cold case

In Work

New Split

Improvements

Park ConfirmPrio

19

MARKETING & SALES


Sales team- respond to RFP

Context

New

Stakeholders:- Sales- Tech leads- CEO

Pro:• Visibility to sales people, oftenmultitasking


QACreate RFPEstablishteam

In Progr. Done

#1

#2

#3

[1] [3]

Also works as ”ready” buffer for Create RFP

Done


Sales team- from lead to purchase

Context

JohnStakeholders:- Sales- Tech leads- CEO

Pro:• Can help focusing sales effortwhile opportunity window permits• Goal should be to eliminate all waittime on our side

Cons:• Many opportunities to manage• Physical board requires co-location

Won(verbal ok)

ProposalWriten

Lead Purchase orderreceived

UnderNegotiation

Alice

Tintin

Hot

Cold

Hot

Cold

Hot

Cold

”Key stuff is to make sure won tranforms fast into purchase order received”- CEO

Sales team


Marketing team

ContextIdea board / todo

Stakeholders:- CEO- Sales

Pro:• Ideas repriotitization and agingvisible• Visual progress of combinedwork

Cons:• Over administration?

Hot (dogs)Ice (popcicles)

In progress @ Third party UnderValidation

(well) Done

Web

Communication

Events

ReleasesSmall marketing teamPR, web, graphics, blog

Marketing kanban

Classes of services

23

MANAGEMENT


Goal breakdown- from abstract to concrete

Context

Pro:• Enables breakdown of abstractvisions to more concrete goals

Cons:• It works best if done collaboratively.

Enable team membersto write down their point of view silenlyon post it first, then together completeeach step

Howto validate

Vision DoneWhere do wewant to be in

Management team

Defined- what couldthis mean for us? 1m 6m 1y

25

http://blog.crisp.se/mattiasskarin

Now, go practice!

http://blog.crisp.se/mattiasskarin

Documents

10 Different Kanban Boards and Their Context - Mskarin