Slicing for Organisational Agility - A #NoEstimates Method
•
23 likes•6,205 views
This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it. A Slicing Heuristic is essentially: An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability. The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle. It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require. Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Slicing for Organisational Agility - A #NoEstimates Method
Similar to Slicing for Organisational Agility - A #NoEstimates Method (20)
More from Killick Agile Consulting Services
More from Killick Agile Consulting Services (20)
Recently uploaded
Recently uploaded (20)
Slicing for Organisational Agility - A #NoEstimates Method
- 1. Neil Killick, Portfolio Manager neilkillick.com neil2killick@gmail.com @neil_killick Slicing for Organisational Agility using The Slicing Heuristic A #NoEstimates Method for Faster & More Predictable Delivery Copyright Neil Killick, 2015
- 2. Not another story slicing talk!
- 5. FAST Shinkansen trains can reach speeds of up to 320km/h PREDICTABLE 13 trains per hour between Tokyo & Osaka (train every 3-5 mins) In 2014, avg delay was 54 seconds, including uncontrollable causes such as natural disasters RELIABLE 5 billion passengers, 150 million per year
- 6. How did they do it? ❏ Built dedicated lines for high speed rail, so not slowed down by slower trains ❏ No road crossings ❏ Specially designed tracks
- 7. You can’t just make a train faster or more reliable. You must create a network for fast, reliable trains.
- 8. Agile is ordering tapas til you’re full, not ordering a 10-course meal.
- 9. Is Agile Estimation really helping us? ❏ Predictive ❏ Optimised for speed ❏ Points are abstract ❏ Focused on cost ❏ Developer-centric ❏ False sense of security
- 10. So, What is a Slicing Heuristic? ❏ An explicit policy that describes how to "slice" work to help us achieve: ❏ Faster time to market* ❏ Better predictability** ❏ How? ❏ Define work with a consistent & shared language ❏ Replace deterministic estimation rituals with: ❏ Slicing rituals ❏ Empirical measurement of actual cycle times for all work types
- 11. slicing …[creating] relatively thin, broad piece[s] cut from an object having some bulk or volume… [ref: yourdictionary.com] heuristic ...any approach to problem solving, learning, or discovery that employs a practical methodology not guaranteed to be optimal or perfect, but sufficient for the immediate goals. [ref: Wikipedia]
- 12. How To: 5-step cycle 1. Define & agree work types 2. Agree slicing policy for each work type 3. Slice work, Just-In-Time 4. Do work + measure cycle times 5. Inspect & adapt policies Initiative Capability Feature Story Build Slice Measure Learn
- 13. 1. Define & agree work types - An example ❏ Initiative - Strategic theme, likely to last several months or longer ❏ Capability - Desired customer outcome, likely to last several iterations ❏ Feature - Proposed solution to deliver a capability, likely to last a few weeks ❏ Story - User capability needed to make a feature, likely to last a few days
- 14. 2. Agree slicing policy for each work type ❏ Define when to stop slicing ❏ State desired cycle time & variation ❏ Make policies explicit & visible (HT Kanban Method) Initiative Capability Feature Story ❏ Max 3 Capabilities ❏ Cycle time < 6 months ❏ Std dev < 3 weeks ❏ Max 2 Features ❏ Cycle time < 2 months ❏ Std dev < 6 days ❏ Max 4 Stories ❏ Cycle time < 2 weeks ❏ Std dev < 3.5 days ❏ 1 Acceptance Test ❏ Cycle time < 3 days ❏ Std dev < 0.5 days
- 15. 3. Slice work Just-In-Time ❏ 1 card for each work item coming into the system ❏ Conversations between appropriate people at appropriate cadence for each work type ❏ Remove/de-prioritise options ❏ Organise remaining options into appropriate work types e.g. push things back upstream
- 16. Initiative Capability 1 Capability 2 Capability 3 Feature 1 Feature 2 Feature 1 Feature 2 Feature 1 Feature 2 Story 1 Story 2 Story 3 Story 4 Story 1 Story 2 Story 1 Story 3 Story 2 Story 2 Story 1 Story 1 Story 3 Story 2 Story 4 Story 1 Story 3 Story 2
- 17. To Do Doing Done = 1 elapsed day Easy to add a dot at daily standup, or just update the data daily in a spreadsheet Story 1 Story 2 Story 3 Story 4 Story 5 Elapsed days 2 3 1 1 2 Days Stories We need this data! 4. Do work + measure cycle times
- 18. 5. Inspect & adapt policies ❏ How long is it taking to deliver work? ❏ Analyse statistical patterns for work types ❏ Do we have desired speed to market? ❏ Do we have desired level of predictability?
- 19. What might happen? 1. Work takes longer than desired (high cycle time) 2. Work is unpredictable overall (high variation) 3. Work is unpredictable within a work type 4. New work types emerge ❏ e.g. MVP/MMF 5. Work type is retired ❏ e.g. move to FDD, no more stories
- 20. High Cycle Time We can try... ❏ Creating clearer story definition &/or acceptance criteria (Definitions of Ready & Done) ❏ Better acceptance tests upstream to clarify all user scenarios, e.g. 3 Amigos ❏ Slicing work more ruthlessly for simplicity and unambiguity ❏ Reducing WIP at one or more levels Leading to: ❏ Simpler stories, more options & lower risk ❏ Shorter feedback loops for faster learning & delivery of customer value ❏ Reduced delays such as hand-offs, story defects, other queues & dependencies on people outside of the team
- 21. Variable Cycle Time We can try... ❏ Being more consistent in the way work is defined & broken down ❏ Keeping WIP consistent ❏ Minimising distractions Leading to… ❏ Managers can use empirical data for more predictable delivery forecasting, rather than relying on crystal ball gazing by the team ❏ Reduced stress on the team ❏ Increased transparency & trust with stakeholders
- 22. Benefits ❏ Empirical ❏ Optimised for conversations ❏ Time is a universal unit ❏ Promotes collaboration “up the chain” ❏ Build the right thing (right solution for right problem) ❏ Control risk (cost/schedule) Initiative Capability Feature Story ❏ Max 3 Capabilities ❏ Cycle time < 6 months ❏ Std dev < 3 weeks ❏ Max 2 Features ❏ Cycle time < 2 months ❏ Std dev < 6 days ❏ Max 4 Stories ❏ Cycle time < 2 weeks ❏ Std dev < 3.5 days ❏ 1 Acceptance Test ❏ Cycle time < 3 days ❏ Std dev < 0.5 days
- 23. *Faster time to market ❏ Slicing makes work simple & unambiguous - naturally leads to “small” ❏ Slicing reduces risk ❏ Slicing exposes options that we can throw away or delay So, making slicing an explicit, measurable activity across our portfolio is likely to increase speed to market.
- 24. **Better predictability ❏ Work at all levels can be forecast using empirical data ❏ Makes portfolio views extremely useful ❏ Instantly know that e.g. a feature is 2-4 weeks ❏ Collaboration & quality of conversations are improved So, making slicing an explicit, measurable activity across our portfolio is likely to increase predictability.
- 25. All we need is a continuous improvement mindset. And a method.
- 26. Build Slice Measure Learn 1. Define & agree work types 2. Agree slicing policy for each work type 3. Slice work, Just-In-Time 4. Do work + measure cycle times 5. Inspect & adapt policies
- 27. DISCLAIMER This will only work if you try it.
- 28. Neil Killick, Portfolio Manager neilkillick.com neil2killick@gmail.com @neil_killick Copyright Neil Killick, 2015