4. 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
5. What is Kanban?
kan·ban [kɑhn-bɑhn]
看板 – Kanban literally means “visual card,” “signboard,” or “billboard”
Developed more than 20 years ago, by Mr. Taiichi Ohno, a vice
president of Toyota
A method of inventory control, originally developed in Japanese
automobile factories, that keeps inventories low by scheduling needed
goods and equipment to arrive a short time before a production run
begins
A visual signal that’s used to trigger an action
A simple-to-operate control system
Fits nicely into an Agile SDLC
6. Properties of Kanban
Visualize what you do today
Limit the amount of work in progress
Improve flow
Pull not push
Request In, Value Out
Minimal Marketable Feature
8. Setup Kanban Board
Need to identify Team Goals
Need to identify limit for On Deck
Need to identify limit for each phase
Move highest priority stories onto On Deck
Setup TFS for workflow
And Go!
9. Lead Time vs. Cycle Time
Lead Time
Starts when story goes On Deck
Ends when story is Released to Production
Cycle Time
Starts when story goes into Analysis
Ends when story moves into QA Done
Customized to our teams
11. Kanban Board
Analysis Phase
1. Cycle Time starts
2. Number of stories in this phase is
limited
3. Team member will pull from On Deck
when work is needed
12. Development Phase
Kanban Board 1. Number of stories in this phase is
limited
2.Team member will pull from Analysis
Done when work is needed
3.Development tasks with hours are
created
Analysis Phase
1. Cycle Time starts
2. Number of stories in this phase is
limited
3. Team member will pull from On Deck
when work is needed
13. Development Phase
Kanban Board 1. Number of stories in this phase is
limited
2.Team member will pull from Analysis
Done when work is needed
3.Development tasks with hours are
created
Analysis Phase
1. Cycle Time starts
2. Number of stories in this phase is
limited
3. Team member will pull from On Deck
when work is needed
QA Phase
1.Number of stories in this phase is limited
2.Team member will pull from Dev. Done
when work is needed
3.QA tasks with hours are created
4.Cycle time ends when story leaves QA
14. Development Phase
Kanban Board 1. Number of stories in this phase is
limited
2.Team member will pull from Analysis
Done when work is needed
3.Development tasks with hours are
created
Analysis Phase
1. Cycle Time starts
2. Number of stories in this phase is
limited
3. Team member will pull from On Deck
when work is needed
Ready to Deploy Phase
1.No limits
QA Phase 2.Team will decide when to release stories
1.Number of stories in this phase is limited in RTD
2.Team member will pull from Dev. Done 3.Proposed 2-week release schedule
when work is needed
3.QA tasks with hours are created
4.Cycle time ends when story leaves QA
15. Work In Progress (WIP)
& Limits
The limit should be large enough to keep the
team busy (i.e. there is always something in it
for the team to start work on), but small
enough to avoid premature prioritization (i.e.
having things sitting in the queue for too long
before they are begun).
WIP limits are designed to reduce multi-
tasking, maximize throughput, and enhance
teamwork.
16. Work In Progress (WIP)
& Limits
To improve cycle time there are two options:
reduce the number of things in process
improve the average completion rate
Byhaving fewer work items in progress, then
the team is able to focus more on the larger
goals, and less on individual tasks, thus
encouraging a swarming effect, and
enhancing teamwork
17. Work In Progress (WIP)
& Limits
Limiting WIP like this can seem unusual for teams, and there is
often a worry that team members will be idle because they have no
work to do, but are unable to pull any new work. The following
guidelines can be useful to help in this situation:
Can you help progress an existing story? Work on that.
Don’t have the right skills? Find the bottleneck and work to
release it.
Don’t have the right skills? Pull in work from the queue.
Can’t start anything in the queue? Is there any lower priority to
start investigating?
There is nothing lower priority? Find other interesting work.
18. Scrumban
Team will decide when to release stories in
RTD
Proposed 2-week release schedule
Conduct daily stand-ups
Retrospectives conducted on an as need
basis, minimum of one per month
19. Remains The Same
ProductBacklog
Business Prioritization of Product Backlog
Release Definition of Done
Demo
Retrospective
20. Daily Standup
Identifybottlenecks – Congestion or gaps?
Blocker not handled?
Working within process limits?
Are priorities clear?
Did yesterday? Plan for today?
Post-standup
Update charts
Remove done items
21. Backlog Grooming / Estimating
/ Planning
Planning, Grooming, and Estimating occur at
the same time
Planning occurs when On Deck phase has a
few stories left
The team will groom the new stories as
added to On Deck
Estimating will consist new size chart:
Small / Medium / Large (<4 week Cycle Time)
22. Bugs/Defects
Bugs found in Staging environment during
testing of a story in QA Phase
Work type item “Bug” will be created in TFS and
linked to a story
The Bug will go to ‘On Deck’ and Assigned To
story developer; story remains in QA phase
QA can continue testing or work on another story
Developer will pull Bug into Analysis or
Development phase when ready to take in work
23. Bugs/Defects (cont.)
The Bug will flow through the workflow similar to
a story
On Deck > Analysis > Analysis Done >
Development > Development Done > QA > QA
Done > Closed
Bug will not go to “Ready to Deploy” or
“Released”
Production Bugs
A story will be created and prioritized
24. Implementation
Team Foundation Server Process Template
Based on http://techdayskanban.codeplex.com/
by Adam Gilmore
User Story and Bug customizations with
workflow
Separate customizations for each Team
Project.
MVC3 KanBan Board website
Excel Reports
25. Other Guidance
VS ALM Rangers Practical KanBan
Guidance
http://vsarkanbanguide.codeplex.com/
A minimal marketable featur e is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity Types include: Competitive differentiation Revenue generation Cost saving Branding Enhanced loyalty