The road to potential shippable increments
Upcoming SlideShare
Loading in...5

The road to potential shippable increments



One of the most common struggles of Scrum teams is finishing a sprint 100%. In their retrospectives, teams work out improvement actions to address this issue. These actions are often targeting better ...

One of the most common struggles of Scrum teams is finishing a sprint 100%. In their retrospectives, teams work out improvement actions to address this issue. These actions are often targeting better planning, better estimating or better preparation of user stories. However, as time proceeds, the next sprints are not completed 100% neither. Even when the Scrum master encourages the team to commit to less story points. They always seems to deliver 80% to 90% of the sprint backlog. Not only is this very demotivating, it also compromises shipping the next increment. In this session I will explain with a case study, why this struggle is not related to poor planning, estimating or preparation. I will share how this specific team used the improvement kata and Theory of Constraints to optimize their flow of work and ended up finishing their sprints successfully.



Total Views
Views on SlideShare
Embed Views



1 Embed 27 27


Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    The road to potential shippable increments The road to potential shippable increments Presentation Transcript

    • the ROAD to potential SHIPPABLEincrements April 25, 26 - Lyon h"p://  
    • Who am I? •  Nick Oostvogels •  Independent consultant •  PM, agile & Kanban coach •  Freelance blogger •  Conference organizer •  Father of 3
    • The story h"p://  
    • The story •  A typical Scrum team •  Dedicated team of 5 devs, 2 qa, 1 PO, 1 SM,1 analyst
    • The story •  Switched from waterfall 6 months ago •  Getting better •  Being coached
    • The story •  Developing a web application •  Highly visible project •  Have to start delivering
    • Retrospectives •  Taken seriously •  Improving continuously •  Open minded, willing to try new things
    • But still… Finishing a sprint 100% seemed impossible
    • Introducing… The 6 step program… … towards potential shippable increments h"p://  
    • 1st step Change focus by learning the improvement kata Goal: get more value out of the retrospectives
    • Kata : a pattern you practice to learn a skill andmindset. Improvement kata : a pattern for improving,adapting and innovating. It helps to improve continuously towardsa goal instead of random hunting forimprovements. h"p://  
    • Current condition Vision Target Condition PDCAPDCAPDCAImprovement kata
    • Customized for retrospectives 1.  Formalize the vision “What is important for us? How do we want todeliver software?
    • Current condition Vision Target Condition PDCAPDCAPDCA
    • Customized for retrospectives 2. Use the vision to agree on the targetcondition “What is the next step we can take to get closerto the vision?”
    • Customized for retrospectives 3. Use the vision as a cross-check Does this improvement suggestion help us toget closer to the vision?
    • Result •  Better focus •  Long term thinking •  Systems thinking •  The vision is used as a referee during discussions •  It may take several sprints to get to the next target condition h"p://  
    • 2nd step Focus on quality Goal:‘REALLY’ delivering features
    • What is quality? Zero bug policy! h"p://  
    • How? •  In sprint testing •  In sprint validation Definition of done: + no open bugs related to user stories of thesprint backlog Fix regression bugs before starting new work
    • Results •  Happier end users •  Easier demo’s •  Higher confidence towards deployment •  More accurate planning
    • 3rd step Focus on improving flow Goal: identify and understand bottlenecks
    • of constraints
    • Boyscouts example
    • •  Step 1 – Find bottlenecks through symptoms •  Step 2 - Plan actions to reduce or eliminatebottlenecks •  Step 3 – Subordonate everything else to theabove decision •  Step 4 – Evaluate the bottleneck •  Step 5 – go back to step1
    • Investigate & act Walk through the lifecycle of the user stories
    • h2p://  Investigate & act Use measurements
    • Investigate & act Discuss possible bottlenecks h2p://  
    • Investigate & act Plan actions to reduce or eliminate the bottleneck
    • Result •  Awareness •  Get used to hunt for bottlenecks
    • 4th step Make bottlenecks visible
    • Limit Work in Progress Active In Development (5) In Test (3) Resolved (2) Closed
    • Kanban board
    • Kanban rules Never break the WIP limits!
    • Being idle due to uneven flow distributiondrives people crazy! h"p://  
    • Kanban rules 1.  Check if the bug list is empty 2.  Check if you can help the next stage to pull afeature 3.  Check if you can help somebody with a featurein your stage 4.  Investigate the root cause 5.  Improve the application or your way of working 6.  Learn something new, related to the job What to do when the flow is stuck?
    • Remember:Kanban doesn’t focus onmaximizing utilization ofpeople
    • Result •  Focus on the entire chain •  WIP limits to manage flow and tacklebottlenecks
    • 5th step Anticipate bottlenecks early on
    • Understanding measurements
    • Distribution
    • SLA’s
    • Result •  Visualisation •  Better decision making •  No more tasks that disappear in the process
    • 6th step Use SLA’s for good sprint backlog composition
    • Sprint backlog Big user stories need to go first We can only do a few big ones Small user stories near the end Dependent user stories may not fit thesprint S  (0-­‐2  sp)  :  4  days    -­‐  7  days  M  (3-­‐5  sp)  :  4  days  -­‐  7  days  L  (8-­‐13  sp)  :  10  days  -­‐  14  days  
    • The Role of PO and SM Owner Explain priorities Actively participate Trust the team Put quality and flow first Scrum Master Guard the rules Give the team amandate Trust the team
    • Compare with 1 year earlier
    • Compare with 1 year earlier Planning is much more accurate despiteless upfront preparation •  Bugfree software •  Consistent delivery •  Definition of done •  Up to date product backlog
    • Compare with 1 year earlier Easier end-user testing and demos Better feedback
    • Compare with 1 year earlier Team spirit increased
    • Not pushing to go fasterbut improving end 2 end h2p://­‐roger/3854246685/  
    • Compare with 1 year earlier Focus on finishing instead of starting
    • Compare with 1 year earlier Ownership “Everybody cares”
    • Summary 1 Improvement Kata 6 Use SLA’s during planning 2 Focus on Quality 3 Improving flow 4 Make bottlenecks visible (WIP limits) 5 Anticipate bottlenecks (SLA’s)
    • Available on
    • Related books
    • Thanks! @NickOostvogels