TRACKING THROUGH
KANBAN
Shuchi Singla, AKT, SPC4
Introduction
Shuchi Singla, AKT, SPC4
Founder, BaffleSol Technologies
https://in.linkedin.com/in/shuchisingla
shuchi.singla@bafflesol.com
Lets hear from you
• What is a Kanban System?
• How to set up a Kanban System?
3
Time-boxed iterative development has
challenges
Common problems include:
• Short time-boxes give more frequent opportunity to measure progress and inspect
software but force development items to be smaller
• Smaller development items are often too small to be valuable and difficult to
identify
• Quality of requirements suffers as analysts rush to prepare for upcoming cycles
• Quality of current development suffers when busy analysts are unable to inspect
software or answer questions during development
• Quality often suffers as testers race to complete work late in the development
time-box
4
Kanban is About Flow and Sustainable Pace
Define a work process flow
Look at the typical flow for features, stories, or work packages and describe
typical process steps
This simple process flow has the steps:
1.elaboration & acceptance criteria
2.development
3.test
4.deployment
6
Lay out a visual Kanban board
Place a goals column on the left, then a waiting queue, the
process steps, and a final “done” column to the right
Place an expedite track above the main
left to right queue
Place “done and waiting” queues between
each work queue
(in this example they’re placed below)
7
Decide on limits for items in queue and work in
progress
A good limit is a factor of the number of people in a role that can work on an
item in a given process step. Start with number of people * 2
This board uses painters tape to indicate
available “slots” for work in progress
8
Place prioritized goals on the left column of the
board
A good goal describes the outcome we hope to achieve after software ships.
Goals help keep focus on the larger outcome.
Having goals visible:
•promotes focus
•helps us prioritize
•helps us manage feature scope &
requirements
9
Start the board by placing stories or features in
queue
Mark on the story or feature card the date it entered the queue. This begins our
measurement of cycle time.
Product owners manage the waiting
queue
10
Move features through the process flow as work
is completed
As the story enters the first process step, mark that date on the card. This is the
start date. As it’s finished, mark that date on the card. This is the finish date.
11
Use the dates on the cards to calculate cycle time
Use average cycle time to set wait times from different points on the board. Pay
attention to flow and bottlenecks: relieving bottlenecks as quickly as possible.
Cycle time = finish date – start date
The average cycle time from the date the
item enters the board is the wait time
from this point in the queue
12
Little’s law
Wq is the average time in the queue for a standard job
Lq is the average number of things in the queue to be processed
The denominator (Lambda) is the average processing rate for
jobs in the queue
http://scalingsoftwareagility.wordpress.com/2009/12/14
Little’s law for a sub system
http://scalingsoftwareagility.wordpress.com/2009/12/14
Backlog = 100 stories
Iteration length = 2 weeks
Velocity = 8 stories per sprint
= 12.5 iterations
or
27 weeks
Cumulative Flow Diagram
What to do if things go wrong?
 Make everyone look at Kanban Boards and
radiators
 Teach everyone to read and analyze
 Sit with team and analyze problem areas
 Endure the pain until you see things getting better.
After that everyone will be on board
Contact me – shuchi.singla@bafflesol.com
Thanks!!

Tracking through kanban

  • 1.
  • 2.
    Introduction Shuchi Singla, AKT,SPC4 Founder, BaffleSol Technologies https://in.linkedin.com/in/shuchisingla shuchi.singla@bafflesol.com
  • 3.
    Lets hear fromyou • What is a Kanban System? • How to set up a Kanban System? 3
  • 4.
    Time-boxed iterative developmenthas challenges Common problems include: • Short time-boxes give more frequent opportunity to measure progress and inspect software but force development items to be smaller • Smaller development items are often too small to be valuable and difficult to identify • Quality of requirements suffers as analysts rush to prepare for upcoming cycles • Quality of current development suffers when busy analysts are unable to inspect software or answer questions during development • Quality often suffers as testers race to complete work late in the development time-box 4
  • 5.
    Kanban is AboutFlow and Sustainable Pace
  • 6.
    Define a workprocess flow Look at the typical flow for features, stories, or work packages and describe typical process steps This simple process flow has the steps: 1.elaboration & acceptance criteria 2.development 3.test 4.deployment 6
  • 7.
    Lay out avisual Kanban board Place a goals column on the left, then a waiting queue, the process steps, and a final “done” column to the right Place an expedite track above the main left to right queue Place “done and waiting” queues between each work queue (in this example they’re placed below) 7
  • 8.
    Decide on limitsfor items in queue and work in progress A good limit is a factor of the number of people in a role that can work on an item in a given process step. Start with number of people * 2 This board uses painters tape to indicate available “slots” for work in progress 8
  • 9.
    Place prioritized goalson the left column of the board A good goal describes the outcome we hope to achieve after software ships. Goals help keep focus on the larger outcome. Having goals visible: •promotes focus •helps us prioritize •helps us manage feature scope & requirements 9
  • 10.
    Start the boardby placing stories or features in queue Mark on the story or feature card the date it entered the queue. This begins our measurement of cycle time. Product owners manage the waiting queue 10
  • 11.
    Move features throughthe process flow as work is completed As the story enters the first process step, mark that date on the card. This is the start date. As it’s finished, mark that date on the card. This is the finish date. 11
  • 12.
    Use the dateson the cards to calculate cycle time Use average cycle time to set wait times from different points on the board. Pay attention to flow and bottlenecks: relieving bottlenecks as quickly as possible. Cycle time = finish date – start date The average cycle time from the date the item enters the board is the wait time from this point in the queue 12
  • 13.
    Little’s law Wq isthe average time in the queue for a standard job Lq is the average number of things in the queue to be processed The denominator (Lambda) is the average processing rate for jobs in the queue http://scalingsoftwareagility.wordpress.com/2009/12/14
  • 14.
    Little’s law fora sub system http://scalingsoftwareagility.wordpress.com/2009/12/14 Backlog = 100 stories Iteration length = 2 weeks Velocity = 8 stories per sprint = 12.5 iterations or 27 weeks
  • 15.
  • 16.
    What to doif things go wrong?  Make everyone look at Kanban Boards and radiators  Teach everyone to read and analyze  Sit with team and analyze problem areas  Endure the pain until you see things getting better. After that everyone will be on board
  • 17.
    Contact me –shuchi.singla@bafflesol.com Thanks!!

Editor's Notes

  • #14 13
  • #15 14
  • #16 Cumulative flow Diagram shows how work “accumulates in flow” with time. It shows the relative amount of work for each stage of project over the time. Large gaps and flat horizontal lines indicate impediments to flow or lack of flow, which usually occur due to irrelevant work in progress limits. In the example above, on the 8th June 2015, there were 22 items in Done, 3 items in Ready To Merge, 2 items in Test, 3 items in Code Review and 3 items in In Development. Similarly on 15th June 2015, there were 30 items Done, 5 items in Ready To Merge, and only 1 item in Test. Which means there is some impediment at Test level, which is drying up work at Ready to Merge state. Check if the work in progress area grows or rather stays constant over time. If it is constant or decreasing, you are most likely doing good, and if it is growing then you need to dig deeper. If work conditions (team size, project type, company environment) have not changed, but work in progress is growing, you may have an issue to deal with. Wide means too much wip or high wait time