Estimation is dead - long live sizing, by John Coleman 24Nov22.pdfOrderly Disruption
Estimation is dead - long live sizing, by John Coleman 24 Nov 22 to Agile Azerbaijan in person and Pozitive Technologies online
As per https://www.infoq.com/articles/sizing-forecasting-scrum/
Estimation is dead - Tbilisi, by John Coleman 26 April 2024 final.pdfOrderly Disruption
In this Agile International Summit opening keynote talk in Tbilisi, Gerogia, John Coleman explored relative sizing (story points, t-shirt size, time reference), right sizing, and dynamic design to cost. It's an of the InfoQ paper "sizing and forecasting in Scrum" except this talk was not focused on only Scrum.
Scrum uses relative estimation and velocity to aid in planning and making trade-off decisions. Relative estimation involves comparing the effort of new requirements to previously estimated ones, which humans are better at than absolute estimates. Velocity is the amount of work completed in an iteration, measured in story points or hours, and varies over time so is useful for longer-term planning. There are two types of Scrum planning: fixed-date planning estimates how much can be completed by a date based on velocity, while fixed-scope planning estimates the timeframe to complete all backlog items based on velocity. Both use velocity as a range rather than a precise prediction.
This presentation includes an overview of the various estimation techniques used in Agile projects. I've also put in a slide for explaining the importance of business value for Agile requirements. A simple mechanism on capacity planning before weaving it all together to come up with a reasonably foolproof plan.
Given at Axial HQ for the New York chapter of Venwise, this talk details how Axial approaches building products predictably through a combination of focus, objectives, prioritization and forecasting. We call it stack.
Check out more of what we're building over at: axialcorps.com
The document discusses different approaches to estimation in waterfall and Scrum methodologies. In Scrum, teams estimate their own work in story points, which are relative units based on size and complexity. Story points help drive cross-functional behavior and do not decay over time. Ideal days estimates involve determining how long a task would take with ideal conditions and no interruptions. Planning poker uses story point cards to facilitate discussion and reach consensus on estimates. Release planning in Scrum involves estimating velocity over sprints to determine how many product backlog items can be completed.
Data skills for Agile Teams- Killing story pointsyasinnathani
This document discusses alternatives to using story points for estimating work in Agile software development. It argues that story points are not the best way to estimate because they only account for the active work time and not queue times, which can account for up to 90% of the total time. It recommends taking a probabilistic approach and tracking flow metrics like cycle time, work in progress (WIP), and aging WIP to better understand flow and give probabilistic estimates rather than deterministic ones. Getting work into the right size and shape before pulling it in is also important to improve flow.
This document discusses the NoEstimates approach to software development. It begins by defining estimates and explaining that NoEstimates is about minimizing estimates rather than eliminating them entirely. The main goals of NoEstimates are to evaluate progress in a concrete way and force teams to slice work into smaller stories. Key benefits include being faster, easier iteration planning, and minimal time spent estimating. Progress is measured by the number of "Running Tested Stories" completed. The document also covers challenges, case studies, and debates around using NoEstimates versus more traditional estimating approaches.
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdfOrderly Disruption
Estimation is dead - long live sizing, by John Coleman 24 Nov 22 to Agile Azerbaijan in person and Pozitive Technologies online
As per https://www.infoq.com/articles/sizing-forecasting-scrum/
Estimation is dead - Tbilisi, by John Coleman 26 April 2024 final.pdfOrderly Disruption
In this Agile International Summit opening keynote talk in Tbilisi, Gerogia, John Coleman explored relative sizing (story points, t-shirt size, time reference), right sizing, and dynamic design to cost. It's an of the InfoQ paper "sizing and forecasting in Scrum" except this talk was not focused on only Scrum.
Scrum uses relative estimation and velocity to aid in planning and making trade-off decisions. Relative estimation involves comparing the effort of new requirements to previously estimated ones, which humans are better at than absolute estimates. Velocity is the amount of work completed in an iteration, measured in story points or hours, and varies over time so is useful for longer-term planning. There are two types of Scrum planning: fixed-date planning estimates how much can be completed by a date based on velocity, while fixed-scope planning estimates the timeframe to complete all backlog items based on velocity. Both use velocity as a range rather than a precise prediction.
This presentation includes an overview of the various estimation techniques used in Agile projects. I've also put in a slide for explaining the importance of business value for Agile requirements. A simple mechanism on capacity planning before weaving it all together to come up with a reasonably foolproof plan.
Given at Axial HQ for the New York chapter of Venwise, this talk details how Axial approaches building products predictably through a combination of focus, objectives, prioritization and forecasting. We call it stack.
Check out more of what we're building over at: axialcorps.com
The document discusses different approaches to estimation in waterfall and Scrum methodologies. In Scrum, teams estimate their own work in story points, which are relative units based on size and complexity. Story points help drive cross-functional behavior and do not decay over time. Ideal days estimates involve determining how long a task would take with ideal conditions and no interruptions. Planning poker uses story point cards to facilitate discussion and reach consensus on estimates. Release planning in Scrum involves estimating velocity over sprints to determine how many product backlog items can be completed.
Data skills for Agile Teams- Killing story pointsyasinnathani
This document discusses alternatives to using story points for estimating work in Agile software development. It argues that story points are not the best way to estimate because they only account for the active work time and not queue times, which can account for up to 90% of the total time. It recommends taking a probabilistic approach and tracking flow metrics like cycle time, work in progress (WIP), and aging WIP to better understand flow and give probabilistic estimates rather than deterministic ones. Getting work into the right size and shape before pulling it in is also important to improve flow.
This document discusses the NoEstimates approach to software development. It begins by defining estimates and explaining that NoEstimates is about minimizing estimates rather than eliminating them entirely. The main goals of NoEstimates are to evaluate progress in a concrete way and force teams to slice work into smaller stories. Key benefits include being faster, easier iteration planning, and minimal time spent estimating. Progress is measured by the number of "Running Tested Stories" completed. The document also covers challenges, case studies, and debates around using NoEstimates versus more traditional estimating approaches.
Measure what matters for your agile projectMunish Malik
While working with Agile projects, we simply can't get away from tracking and showcasing the progress of the project. A typical Agile project would be working with estimates, story points, velocities, burn-up or burn-down charts.
I have witnessed numerous sprint reviews and showcases where the business is only waiting to see those few slides of the presentation where there is the "actual" red worm, running against the "planned" green worm, trying to catch-up. If the red worm is ahead, I have seen a smile on the faces of the stakeholders. If it matches the green one, there is a sigh of relief. And as a development team you should just pray that the poor red guy is not falling behind the green one, lest it might lead to a lot of questions starting with why, how, what etc.
There have also been times where there have been some unfortunate heated discussions that last forever on why did the team end up not claiming a few points that they had committed. What gets lost is what the team accomplished in the sprint that adds good value to the product. There have also been times where the estimates are being questioned by the product owner or account managers. If you are working in a distributed setup where the product owner is working out of a different country, the problem is even bigger.
Let us think about a scenario where the project gets completed on time, budget and scope. Majority (or all) of estimates were correct. However, when the product went live to the market it failed big time. What is the use of building such a product?
Are we focusing too much on numbers and points and overlooking the other important aspects of Agile software development such as producing software that delights the customers and looking for ways on how we can measure that? Are we measuring if we are creating a solid, robust and a scalable platform that is ready for future developments and enhancements? Are we measuring the outcomes of the time we are spending in the shoes of the people who will actually use the software?
The objective of this presentation is to promote the thinking of measuring what matters for your project. To measure the goals that your software development wants to achieve. I don't plan to showcase an exhaustive list of measurements that can solve all your problems, however, I instead want to highlight some samples that I have used in my projects with the help of my team, that helped us to measure things that add value to the business and development v/S simply creating burn down charts.
Majorly, I want to encourage thinking out of the box to identify what measurements will really matter for your projects. Perhaps from the eyes of the users and business and see what things if measured will add a lot more value than simply estimates, and will help in creating a valuable product that will truly delight the business and the users of the product.
Xanpan is a hybrid agile methodology that combines elements of Kanban and Extreme Programming (XP). It is described as team-centric and emphasizes continuous flow, small batch sizes, visualizing work, and quality. Some key practices include using XP technical practices like test-driven development, breaking stories into tasks, estimating in story points, applying work-in-progress limits, and having regular iteration cycles with deadlines. The methodology aims to take the best of Kanban and XP while allowing teams flexibility in customizing their process.
The document describes a method called "Planning Poker" for quickly estimating project tasks through group discussion and iterative voting. A facilitator leads a team in estimating how many chickens are needed for a dinner party for 20 people. Through three rounds of voting and discussion to clarify assumptions, the team converges on an estimate of 13 chickens. Planning Poker aims to leverage collective expertise while avoiding biases from individual experts.
The document provides an overview of agile requirements discovery and backlog grooming using a slingboard. It discusses how a slingboard can be used to visualize workflows and collaborate more effectively by making responsibilities and status transparent. The document covers sections on collaborating with a slingboard, backlog grooming in Scrum, and backlog grooming specifically with a slingboard. Key aspects covered include ranking and sizing user stories, illustrating stories with storyboards, splitting large stories, and signaling status updates on a slingboard.
Agile estimation involves estimating at multiple levels:
1) Product roadmap uses high-level estimates like 12 months to sequence features by business value and cost.
2) Release planning estimates in story points to prioritize features for the next 4 iterations based on team velocity.
3) Iteration planning breaks down epics and estimates user stories in story points or t-shirt sizes for the current sprint.
Relative estimation methods like planning poker and fibonacci sequence are preferred over absolute estimates due to uncertainty in large projects. Regular refinement of estimates is important in agile.
This document discusses concepts related to estimation and velocity in Scrum projects. It describes how to estimate product backlog items using story points or ideal days with relative sizing. Velocity is defined as the amount of work completed each sprint by totaling the sizes of completed backlog items. A team's velocity range is used for planning and process improvement. Planning poker is presented as a consensus-based technique for sizing items through discussion.
This document discusses effort estimation techniques for projects. It describes estimating as forming a judgment about the work required, and mentions common techniques like decomposition, expert judgment, analogy, and planning poker. It also covers risk identification and adding buffers to estimates and schedules to account for risks and uncertainties. Key points emphasized are estimating in hours or days, adding 25% to total costs for buffers, and that more estimation perspectives improve the accuracy and consensus of estimates.
Minimum Viable Agile is a search for Agile practices and ceremonies, informed by Lean and Agile theory, that produces the maximum amount of customer value, with the least amount of effort.
(Or Just Enough practices and ceremonies to be effective).
Pmi agile planning, inspection and adaptionscrumtodd
This document summarizes an upcoming workshop on Agile Planning, Inspection & Adaption. It will include sections on approaches and value of agile, agile planning, inspecting progress, and adapting processes. The workshop will be led by two experienced agile coaches and include a Q&A session. Attendees will learn how to plan iteratively, inspect progress through metrics and retrospectives, and adapt processes to improve.
Framework Thinking - 7 Frameworks To Skyrocket Your CareerSean Johnson
Discover how to leverage frameworks to become more effective and gain influence in your organization.
Learn more about Framework thinking here: http://www.sean-johnson.com/framework-thinking
Story points vs hours choose wisely; turn the bane of project estimation into...Katy Slemon
The document discusses the traditional method of estimating projects in hours versus the agile estimation method of using story points. It provides details on both methods, including perceived advantages of story points like being more flexible and collaborative. However, it also notes disadvantages like the potential to misunderstand or misuse story points. The company described, Bacancy Technology, prefers to use hours rather than story points for estimation since it is more straightforward and prevents confusion.
Measuring for team effectiveness (with Reecetech)Mark Barber
The document discusses measuring team effectiveness through metrics. It provides examples of good and bad metrics, focusing on metrics that measure building the right thing, building the thing right, and building the thing in a sustainable way. Good metrics are developed by the team to improve performance and focus on important areas for improvement. The document also discusses measuring cycle time, engagement, production incidents, and other metrics to understand progress, eliminate waste, and ensure team health and quality.
You’re an expert developer, peacefully composing code into a profoundly elegant masterpiece, when suddenly your boss rushes in with the Next Big Idea that will Revolutionize The Way People Use The Internet. He’s on his way to pitch to a VC, and stops by to describe the Idea in excited terms. After a 30 second elevator pitch, he pops the question: “So, Peter, how long do you think it will take to build this thing-a-ma-bob?”
What do you say?
These eight Protips will cover your back, save your job, and keep your boss’s shirt.
Tapping Your Inner CEO: Management Tips to Stay on Budget and DeadlineKim Schroeder
This document discusses business principles and best practices for managing digitization projects and staying on budget. It emphasizes the importance of understanding costs, tracking staff time, evaluating workflows, and incorporating feedback to improve efficiency. Business tools like budgets, time tracking, and data analysis can help archives complete projects on time and on budget while maintaining quality. Regular evaluation of metrics helps identify issues early and make adjustments to workflows before projects fall behind schedule or go over budget.
General introduction to agile practices like Scrum and Kanban. Also covers what situations Agile is best at, what situations Agile doesn't help with, and what an Agile team should look like. This deck is a general intro to Agile for OpenSource Connections clients.
This document provides an agenda and overview for an Agile and Scrum workshop. The workshop covers Agile development principles and how they differ from traditional waterfall approaches. It then discusses Scrum basics, including Scrum roles, events, and tools. The workshop aims to explain Agile and Scrum concepts, make the sessions interactive, and allow for an open discussion in the final session.
The document provides tips and best practices for project management of websites built with Drupal. It discusses the importance of planning, communication with clients, using an appropriate development process (agile vs waterfall), estimating timelines, scheduling tasks, prioritizing design, managing client expectations, and Drupal-specific considerations.
MORE –
Managerial and Organizational Resilience
Evolution SUCCESS –
Savvy United Culture and Climate Envelope with Succession Superpowers
ACTION –
Act, Clarify, Try-out, Iterate, Orient, Now
Bar-stool pitch
Executives... What got you here won't get you there.
Avoid:
–Focusing too much on quarterly results and targets
–Not caring how employees deliver results
–Not truly empowering teams to solve impediments
–Employees not feeling inspired and hence not exciting customers in the right way.
Prepare your successors. Attain MORE SUCCESS through ambidextrous ACTION
Measure what matters for your agile projectMunish Malik
While working with Agile projects, we simply can't get away from tracking and showcasing the progress of the project. A typical Agile project would be working with estimates, story points, velocities, burn-up or burn-down charts.
I have witnessed numerous sprint reviews and showcases where the business is only waiting to see those few slides of the presentation where there is the "actual" red worm, running against the "planned" green worm, trying to catch-up. If the red worm is ahead, I have seen a smile on the faces of the stakeholders. If it matches the green one, there is a sigh of relief. And as a development team you should just pray that the poor red guy is not falling behind the green one, lest it might lead to a lot of questions starting with why, how, what etc.
There have also been times where there have been some unfortunate heated discussions that last forever on why did the team end up not claiming a few points that they had committed. What gets lost is what the team accomplished in the sprint that adds good value to the product. There have also been times where the estimates are being questioned by the product owner or account managers. If you are working in a distributed setup where the product owner is working out of a different country, the problem is even bigger.
Let us think about a scenario where the project gets completed on time, budget and scope. Majority (or all) of estimates were correct. However, when the product went live to the market it failed big time. What is the use of building such a product?
Are we focusing too much on numbers and points and overlooking the other important aspects of Agile software development such as producing software that delights the customers and looking for ways on how we can measure that? Are we measuring if we are creating a solid, robust and a scalable platform that is ready for future developments and enhancements? Are we measuring the outcomes of the time we are spending in the shoes of the people who will actually use the software?
The objective of this presentation is to promote the thinking of measuring what matters for your project. To measure the goals that your software development wants to achieve. I don't plan to showcase an exhaustive list of measurements that can solve all your problems, however, I instead want to highlight some samples that I have used in my projects with the help of my team, that helped us to measure things that add value to the business and development v/S simply creating burn down charts.
Majorly, I want to encourage thinking out of the box to identify what measurements will really matter for your projects. Perhaps from the eyes of the users and business and see what things if measured will add a lot more value than simply estimates, and will help in creating a valuable product that will truly delight the business and the users of the product.
Xanpan is a hybrid agile methodology that combines elements of Kanban and Extreme Programming (XP). It is described as team-centric and emphasizes continuous flow, small batch sizes, visualizing work, and quality. Some key practices include using XP technical practices like test-driven development, breaking stories into tasks, estimating in story points, applying work-in-progress limits, and having regular iteration cycles with deadlines. The methodology aims to take the best of Kanban and XP while allowing teams flexibility in customizing their process.
The document describes a method called "Planning Poker" for quickly estimating project tasks through group discussion and iterative voting. A facilitator leads a team in estimating how many chickens are needed for a dinner party for 20 people. Through three rounds of voting and discussion to clarify assumptions, the team converges on an estimate of 13 chickens. Planning Poker aims to leverage collective expertise while avoiding biases from individual experts.
The document provides an overview of agile requirements discovery and backlog grooming using a slingboard. It discusses how a slingboard can be used to visualize workflows and collaborate more effectively by making responsibilities and status transparent. The document covers sections on collaborating with a slingboard, backlog grooming in Scrum, and backlog grooming specifically with a slingboard. Key aspects covered include ranking and sizing user stories, illustrating stories with storyboards, splitting large stories, and signaling status updates on a slingboard.
Agile estimation involves estimating at multiple levels:
1) Product roadmap uses high-level estimates like 12 months to sequence features by business value and cost.
2) Release planning estimates in story points to prioritize features for the next 4 iterations based on team velocity.
3) Iteration planning breaks down epics and estimates user stories in story points or t-shirt sizes for the current sprint.
Relative estimation methods like planning poker and fibonacci sequence are preferred over absolute estimates due to uncertainty in large projects. Regular refinement of estimates is important in agile.
This document discusses concepts related to estimation and velocity in Scrum projects. It describes how to estimate product backlog items using story points or ideal days with relative sizing. Velocity is defined as the amount of work completed each sprint by totaling the sizes of completed backlog items. A team's velocity range is used for planning and process improvement. Planning poker is presented as a consensus-based technique for sizing items through discussion.
This document discusses effort estimation techniques for projects. It describes estimating as forming a judgment about the work required, and mentions common techniques like decomposition, expert judgment, analogy, and planning poker. It also covers risk identification and adding buffers to estimates and schedules to account for risks and uncertainties. Key points emphasized are estimating in hours or days, adding 25% to total costs for buffers, and that more estimation perspectives improve the accuracy and consensus of estimates.
Minimum Viable Agile is a search for Agile practices and ceremonies, informed by Lean and Agile theory, that produces the maximum amount of customer value, with the least amount of effort.
(Or Just Enough practices and ceremonies to be effective).
Pmi agile planning, inspection and adaptionscrumtodd
This document summarizes an upcoming workshop on Agile Planning, Inspection & Adaption. It will include sections on approaches and value of agile, agile planning, inspecting progress, and adapting processes. The workshop will be led by two experienced agile coaches and include a Q&A session. Attendees will learn how to plan iteratively, inspect progress through metrics and retrospectives, and adapt processes to improve.
Framework Thinking - 7 Frameworks To Skyrocket Your CareerSean Johnson
Discover how to leverage frameworks to become more effective and gain influence in your organization.
Learn more about Framework thinking here: http://www.sean-johnson.com/framework-thinking
Story points vs hours choose wisely; turn the bane of project estimation into...Katy Slemon
The document discusses the traditional method of estimating projects in hours versus the agile estimation method of using story points. It provides details on both methods, including perceived advantages of story points like being more flexible and collaborative. However, it also notes disadvantages like the potential to misunderstand or misuse story points. The company described, Bacancy Technology, prefers to use hours rather than story points for estimation since it is more straightforward and prevents confusion.
Measuring for team effectiveness (with Reecetech)Mark Barber
The document discusses measuring team effectiveness through metrics. It provides examples of good and bad metrics, focusing on metrics that measure building the right thing, building the thing right, and building the thing in a sustainable way. Good metrics are developed by the team to improve performance and focus on important areas for improvement. The document also discusses measuring cycle time, engagement, production incidents, and other metrics to understand progress, eliminate waste, and ensure team health and quality.
You’re an expert developer, peacefully composing code into a profoundly elegant masterpiece, when suddenly your boss rushes in with the Next Big Idea that will Revolutionize The Way People Use The Internet. He’s on his way to pitch to a VC, and stops by to describe the Idea in excited terms. After a 30 second elevator pitch, he pops the question: “So, Peter, how long do you think it will take to build this thing-a-ma-bob?”
What do you say?
These eight Protips will cover your back, save your job, and keep your boss’s shirt.
Tapping Your Inner CEO: Management Tips to Stay on Budget and DeadlineKim Schroeder
This document discusses business principles and best practices for managing digitization projects and staying on budget. It emphasizes the importance of understanding costs, tracking staff time, evaluating workflows, and incorporating feedback to improve efficiency. Business tools like budgets, time tracking, and data analysis can help archives complete projects on time and on budget while maintaining quality. Regular evaluation of metrics helps identify issues early and make adjustments to workflows before projects fall behind schedule or go over budget.
General introduction to agile practices like Scrum and Kanban. Also covers what situations Agile is best at, what situations Agile doesn't help with, and what an Agile team should look like. This deck is a general intro to Agile for OpenSource Connections clients.
This document provides an agenda and overview for an Agile and Scrum workshop. The workshop covers Agile development principles and how they differ from traditional waterfall approaches. It then discusses Scrum basics, including Scrum roles, events, and tools. The workshop aims to explain Agile and Scrum concepts, make the sessions interactive, and allow for an open discussion in the final session.
The document provides tips and best practices for project management of websites built with Drupal. It discusses the importance of planning, communication with clients, using an appropriate development process (agile vs waterfall), estimating timelines, scheduling tasks, prioritizing design, managing client expectations, and Drupal-specific considerations.
MORE –
Managerial and Organizational Resilience
Evolution SUCCESS –
Savvy United Culture and Climate Envelope with Succession Superpowers
ACTION –
Act, Clarify, Try-out, Iterate, Orient, Now
Bar-stool pitch
Executives... What got you here won't get you there.
Avoid:
–Focusing too much on quarterly results and targets
–Not caring how employees deliver results
–Not truly empowering teams to solve impediments
–Employees not feeling inspired and hence not exciting customers in the right way.
Prepare your successors. Attain MORE SUCCESS through ambidextrous ACTION
Summary
As an executive, board member, or entrepreneur, learn about a management innovation you can begin working on tomorrow.
Try better and more timely decision-making, with happy employees serving happy customers, good psychological flow, and an optimized flow of potential and actual value.
Consider multi-year operational performance over share price; share price focus alone drives cost-cutting to the extent employees incur "moral injury," increase long-term costs, and worsen customer, consumer, or user long-term experience.
Description
It's notable how little management innovation occurs. It has dramatic effects when it happens, e.g., RenDanHeyi in Haier, Beyond Budgeting in Handelsbanken, and Cynefin® in government and industry alike. Estuarine Mapping is also making waves. But there is a new upstart.
This is not for you if you are only interested in quick fixes, looking good, or doing the bare minimum to satisfy shareholder, legal, moral, or psychological needs. As W. Edwards Deming often said, "Survival is optional."
This is for those who want long-term and short-term success, those who wish to leave a legacy of prestige and successful successors, and those who want to lead the way to being led by others.
Try better and more timely decision-making, with happy employees serving happy customers, good psychological flow, and an optimized flow of potential and actual value.
Consider multi-year operational performance over share price; share price focus alone drives cost-cutting to the extent employees incur "moral injury," increase long-term costs, and worsen customer, consumer, or user long-term experience.
Revolutions don't need a majority to get started. As Leandro Herrero once said, "Revolutionaries don't wait for everyone to be aligned." So why are you waiting?
As an executive, as a board member, and as an entrepreneur. Do you want to leave a mark or not? How do you want to be remembered? What can you do tomorrow? What's stopping you?
Speaker profile
John Coleman
Executive guide, product leader
Trainer for Agile Kata, Kanban, Kanplexity, LeSS, Scrum
Flight Levels Coach, co-author of Kanban Guide
Podcast host - Xagility, Agility Island
"Chef"
Kanplexity Talk at Scrum Day London 24th June 2023
Kanplexity combines Kanban, using Cynefin as a leadership and comlexity compass, and agile interacitons that help teams and crews deal with complexity (and chaos).
Why you might need an agility island as per https://www.infoq.com/articles/need-island-agility/
Did you ever feel like sometimes agile is so hard that you might need to start a new company?
Did you ever feel that maybe not the entire organization needs to be agile?
In this talk, we explore Michael Sahota's culture bubble, Heidi Helfand's isolation pattern, and LeSS's parallel organization
And we go further - how about we build an island of agility with its own ethos, leadership style, measurements systems
And how about we go even further and build an archipelago of agility, leaving the mainland to do what it does best, milking the cow we already have
Kanplexity is a complexity expansion pack for Kanban, a jumping-off point for Cynefin using Kanban.
Kanplexity has a team/crew, a guide, a direction of travel, and interactions. Kanplexity has an orientation reference for Cynefin domains. Kanplexity uses Cynefin as a compass.
Kanplexity has recommendations for multi-team/crew patterns, and it provides support for projects.
Kanplexity - a jumping-off point for Cynefin using KanbanOrderly Disruption
John Coleman is a top agile leader who coaches various agile frameworks including Kanban, Scrum, and LeSS. He created Kanplexity and Xagility to help teams and organizations deal with complexity. Kanplexity advocates defining workflows, focusing on flow metrics, having a guide to facilitate discovery and decision making using the Cynefin framework, and establishing a direction of travel rather than fixed goals. It promotes flexibility, rhythm, expanding optimization upstream and downstream, and minding the flow of value.
Scrum with Kanban Regional Scrum Gathering Taipei 4th November 2022.pdfOrderly Disruption
Add rocket fuel and connectedness to your Scrum Teams with the Kanban Guide for Scrum Teams.
Scrum with Kanban is authentic about both Scrum and Kanban.
Learn about:
-Definition of Workflow
-Flow metrics
-Kanban practices
-Flow-based Scrum events
-Expand Kanban board upstream, downstream, at various levels of granularity (work, co-ordination, strategy)
-Discover to not deliver
-Scrum Master has additional skills
-Manage expectations about uncertainty before dates
-Use Monte Carlo probabilistic forecasting, saying "I'll have a better forecast next week"
Lean Agile London - Hit Delete - unlocking organizational agility by unlockin...Orderly Disruption
Hit Delete talk by John Coleman of Orderly Disruption at Lean Agile London - unlock authentic sustainable organizational agility one behavior deletion at a time. Check out John's Xagility and Agility Island podcasts https://linktr.ee/johncolemanxagility #notlinear #lifeisnotsosimple #lifeiseasytotalk #lifeishardtodo
The document discusses combining Scrum and Kanban practices to manage workflow. The key practices are:
1) Visualizing workflow using a Kanban board to see work status and optimize flow.
2) Limiting work in progress to focus effort and allow for slack time.
3) Actively managing work items to continually address complexity.
4) Inspecting and adapting the workflow definition and service level expectations based on data.
Flow-based Scrum events like planning, daily stand-ups, and retrospectives are also discussed.
The document introduces Kanplexity, which is Kanban for managing complexity. It uses rhythmic cycles, replenishment, reviews, and retrospectives to guide teams/crews and their work. The approach uses sprints within an authentic Kanban system for non-technical contexts. Teams check-in frequently to ensure their approach remains valid and many use patterns like Nexus, LESS and flight levels.
The document discusses the need for "deletions" or reductions of certain behaviors to achieve authentic sustainable organizational agility. Some behaviors that need deleting include: decisions made with perfect information, fixed price and scope commitments, lack of work prioritization, complacency about improvement, and delayed meetings. Without reducing these behaviors, teams will lack motivation for agility approaches. The document provides suggestions for areas executives could focus on deleting like recruitment/promotion practices, listening skills, empowering non-experts, and improving understanding of complexity.
The document discusses communities and the value of community. It uses the metaphor of a cake to represent how communities are made up of different layers that must fit together. It also discusses the concept of "slice of cake teams" which are self-organizing teams that can deliver value incrementally on a regular basis, like slices of cake.
1) The guide contains the minimum set of rules for Kanban - the Flow Strategy (KFS) to provide a unifying reference for the community while accommodating a wide range of challenges.
2) Followers can layer additional practices on top of the basic structure provided they adhere to the minimum requirements.
3) To apply Kanban, teams must actively manage work in progress, use workflow policies to support flow, avoid local optimization, and have transparency, visualization, learning, and flow to optimize value.
This document introduces Kanban - the Flow Strategy (KFS), a minimalist flow strategy approach. It provides 5 reasons why one should "swipe right" and adopt KFS, including that it is simple, defines value types, supports deep complexity through an addendum, doesn't require adopting other approaches like Theory of Constraints, and is still evolving based on feedback. Key aspects of KFS that are defined include workflow, practices, measures, cycle time, flow, backlog, boards, work items, work in progress limits, and value. It is presented as having clarity, simplicity, breadth and depth, while being extensible through addendums. Adoption of KFS is portrayed as supporting executive, organizational and non
2019 Agile Cincinnati talk. 5 non-linear steps on the journey to 21st-century executive leadership. Context is king, building relationships and understanding executive needs are crucial. How wise is it to talk about stuff executives aren't ready for yet? What can you talk about then?
The document discusses organizational agility and defines it as the ability to drive disruption through effectiveness, quality, learning, and efficiency using small cross-functional teams. It describes agility as fostering psychological safety, engagement, respect, and transparency. The document suggests agility is a required 21st century skill and advocates for executive leadership that supports organizational direction through agility. It provides links to surveys about insights related to agility.
Exec leadership for agility may 2018 cincinnati, indianapolis, amsterdamOrderly Disruption
This document provides information about John Coleman and his work helping organizations become more agile through executive leadership training and coaching. He trains and coaches executives, managers, and teams in agile strategies. Some of the topics he covers in full and short workshops include Scrum, Kanban, systems thinking, large scale agility, and implementing beyond budgeting. He also discusses frameworks for developing autonomy and alignment in organizations. Upcoming events involving John Coleman are mentioned at the end.
Understanding User Needs and Satisfying ThemAggregage
https://www.productmanagementtoday.com/frs/26903918/understanding-user-needs-and-satisfying-them
We know we want to create products which our customers find to be valuable. Whether we label it as customer-centric or product-led depends on how long we've been doing product management. There are three challenges we face when doing this. The obvious challenge is figuring out what our users need; the non-obvious challenges are in creating a shared understanding of those needs and in sensing if what we're doing is meeting those needs.
In this webinar, we won't focus on the research methods for discovering user-needs. We will focus on synthesis of the needs we discover, communication and alignment tools, and how we operationalize addressing those needs.
Industry expert Scott Sehlhorst will:
• Introduce a taxonomy for user goals with real world examples
• Present the Onion Diagram, a tool for contextualizing task-level goals
• Illustrate how customer journey maps capture activity-level and task-level goals
• Demonstrate the best approach to selection and prioritization of user-goals to address
• Highlight the crucial benchmarks, observable changes, in ensuring fulfillment of customer needs
Brian Fitzsimmons on the Business Strategy and Content Flywheel of Barstool S...Neil Horowitz
On episode 272 of the Digital and Social Media Sports Podcast, Neil chatted with Brian Fitzsimmons, Director of Licensing and Business Development for Barstool Sports.
What follows is a collection of snippets from the podcast. To hear the full interview and more, check out the podcast on all podcast platforms and at www.dsmsports.net
Part 2 Deep Dive: Navigating the 2024 Slowdownjeffkluth1
Introduction
The global retail industry has weathered numerous storms, with the financial crisis of 2008 serving as a poignant reminder of the sector's resilience and adaptability. However, as we navigate the complex landscape of 2024, retailers face a unique set of challenges that demand innovative strategies and a fundamental shift in mindset. This white paper contrasts the impact of the 2008 recession on the retail sector with the current headwinds retailers are grappling with, while offering a comprehensive roadmap for success in this new paradigm.
Top mailing list providers in the USA.pptxJeremyPeirce1
Discover the top mailing list providers in the USA, offering targeted lists, segmentation, and analytics to optimize your marketing campaigns and drive engagement.
Digital Marketing with a Focus on Sustainabilitysssourabhsharma
Digital Marketing best practices including influencer marketing, content creators, and omnichannel marketing for Sustainable Brands at the Sustainable Cosmetics Summit 2024 in New York
Navigating the world of forex trading can be challenging, especially for beginners. To help you make an informed decision, we have comprehensively compared the best forex brokers in India for 2024. This article, reviewed by Top Forex Brokers Review, will cover featured award winners, the best forex brokers, featured offers, the best copy trading platforms, the best forex brokers for beginners, the best MetaTrader brokers, and recently updated reviews. We will focus on FP Markets, Black Bull, EightCap, IC Markets, and Octa.
Discover timeless style with the 2022 Vintage Roman Numerals Men's Ring. Crafted from premium stainless steel, this 6mm wide ring embodies elegance and durability. Perfect as a gift, it seamlessly blends classic Roman numeral detailing with modern sophistication, making it an ideal accessory for any occasion.
https://rb.gy/usj1a2
❼❷⓿❺❻❷❽❷❼❽ Dpboss Matka Result Satta Matka Guessing Satta Fix jodi Kalyan Final ank Satta Matka Dpbos Final ank Satta Matta Matka 143 Kalyan Matka Guessing Final Matka Final ank Today Matka 420 Satta Batta Satta 143 Kalyan Chart Main Bazar Chart vip Matka Guessing Dpboss 143 Guessing Kalyan night
Industrial Tech SW: Category Renewal and CreationChristian Dahlen
Every industrial revolution has created a new set of categories and a new set of players.
Multiple new technologies have emerged, but Samsara and C3.ai are only two companies which have gone public so far.
Manufacturing startups constitute the largest pipeline share of unicorns and IPO candidates in the SF Bay Area, and software startups dominate in Germany.
Event Report - SAP Sapphire 2024 Orlando - lots of innovation and old challengesHolger Mueller
Holger Mueller of Constellation Research shares his key takeaways from SAP's Sapphire confernece, held in Orlando, June 3rd till 5th 2024, in the Orange Convention Center.
How to Implement a Real Estate CRM SoftwareSalesTown
To implement a CRM for real estate, set clear goals, choose a CRM with key real estate features, and customize it to your needs. Migrate your data, train your team, and use automation to save time. Monitor performance, ensure data security, and use the CRM to enhance marketing. Regularly check its effectiveness to improve your business.
Taurus Zodiac Sign: Unveiling the Traits, Dates, and Horoscope Insights of th...my Pandit
Dive into the steadfast world of the Taurus Zodiac Sign. Discover the grounded, stable, and logical nature of Taurus individuals, and explore their key personality traits, important dates, and horoscope insights. Learn how the determination and patience of the Taurus sign make them the rock-steady achievers and anchors of the zodiac.
Taurus Zodiac Sign: Unveiling the Traits, Dates, and Horoscope Insights of th...
Estimation is dead - long live sizing, by John Coleman 13June2023.pdf
1. Estimation is dead
- long live sizing
John Coleman
@JohnColemanIRL
https://linktr.ee/johncolemanxagility
https://www.infoq.com/articles/sizing-
forecasting-scrum/
2. How many minutes did
it take me to paint this
trellis?
• Front and back
• One generous coat of paint
• Get every little groove and corner painted without
having paint all over the floor
• Must pass independent inspection
3. Estimate is no
longer in the
Scrum guide
Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to
improve the product. It is the single source of work undertaken by the
Scrum Team.
Product Backlog items that can be Done by the Scrum Team within
one Sprint are deemed ready for selection in a Sprint Planning event.
They usually acquire this degree of transparency after refining
activities.
Product Backlog refinement is the act of breaking down and further
defining Product Backlog items into smaller more precise items. This
is an ongoing activity to add details, such as a description, order, and
size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the
sizing. The Product Owner may influence the Developers by helping
them understand and select trade-offs.
4. Forecast in the Scrum guide
The Sprint
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not
replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened
may be used for forward-looking decision making.
Sprint Planning
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past
performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
6. Sizing caveats
People who do the work do the sizing, no one else!
Complex work is uncomparable - when dealing with complexity, know that these
techniques are almost always inaccurate
If we don’t ”clean up up the kitchen” as a habit, the accumulation of mess will
lead work will take longer than before
The most popular sizing techniques are either based on data or educated
guesses
8. Flow metrics -
Kanban Guide for
Scrum Teams
Throughput: The number of product backlog items finished
per unit of time
Cycle Time: End-date minus Start-date +1
Work Item Age: The elapsed calendar time between when
a work item started and the current time; this applies only
to items still in progress
Work in Progress (WIP): The number of work items started
but not finished
15. Relative
estimation
1 of 2
Time reference - Comparing current work
items to the time it took to complete historical
reference items
Assigning numeric values - Examples include
using story points based on the Fibonacci
sequence and often carried out collaboratively
with playing cards (planning poker)
T-shirt sizing - Assigning s, s/m, m, m/l, xl, xxl,
xxxl, xxxxl to Product Backlog Items instead of
numeric value
Wall estimation - Assigning numeric values by
collaboratively placing and moving cards on a
wall, also referred to as magic estimation or
silent estimation
16. Relative
estimation
2 of 2
It comes in different flavors
If you estimate, the best thing that can happen is the
estimates are correct
Estimates are prone to the "flaw of averages" (Sam
Savage). Is 50:50 an excellent way to set expectations?
The average of independent blind assessments can be
near enough to the truth (credit to Dave Snowden) -
how often estimates blind in Scrum Teams though
If you don't estimate at all, you don't waste time;
hopefully, you will discover/deliver outcomes sooner
17. Rightsizing
How much time could you save caring more about whether
the team can complete an item within the Sprint and less
about making that item infinitely smaller?
Think of the reduced cognitive load on the Product Owner
resulting from fewer PBIs
Counting the number of (valuable right-sized) PBIs delivered
to Done per Sprint is valuable for Sprint Planning and
forecasting goals
If throughput is sporadic or irregular, we have more significant
problems than forecasting; we have a "plumbing problem"
Using average throughput also pursues the "flaw of averages;"
Monte Carlo probabilistic forecasting is preferable
18. One interpretation of
#NoEstimates
STRIVE FOR AN EVEN
DISTRIBUTION OF
"BALLPARK" ITEM SIZES
THROUGHOUT A
BACKLOG
COUNT RUNNING TESTED
STORIES OR RUNNING
TESTED FEATURES TO
DEMONSTRATE
PROGRESS IN OUTPUT
TERMS
FOCUS ON SIMPLIFYING
THE WHAT FOR THE WHY -
A FOCUS ON DESIRED
OUTCOMES
RIGHT-SIZING - IDENTIFY
SMALL ENOUGH ITEMS
FOR INTAKE
SLICING INTO 24-HOUR
TIMEBOXING OF ITEMS
ENCOURAGES THE
CREATION OF
EXPERIMENTS THAT
VALIDATE
ASSUMPTIONS/HYPOTHE
SES TOWARDS A GOAL,
DISCOVER TO DELIVER
USE ROLLING-WAVE
FORECASTS TO
COMMUNICATE
UNCERTAINTY
19. One
interpretation
of
#NoEstimates
• Counting the number of (valuable right-
sized) PBIs delivered to Done per Sprint is
valuable for Sprint Planning and
forecasting goals
• "Rolling Wave Forecast” based on
throughput with variance limits is
preferable
20. Time reference
Potential downsides
Requires suitable reference items from the
past
Prone to abuse be people with a focus on
people utilization
Unsuitable for probabilistic forecasting
Potential upsides
Speaks in the customers language
Easy to pick reference items from the past
Waiting time is included in our memory of
how long it takes
Simple to do
21. Story points
Potential upsides
Useful to avoid bringing “elephants” into WIP
Could be used to limit work in progress
Easy to pick reference items from the past
Simple to do
Developers like the conversation it triggers
Often paired with t-shirt sizing or wall
estimation
Could be combined with probabilistic
forecasting, but should it?
Potential downsides
Creator regrets story points
Only for the team
Story point inflation
BS story points
Often paired with planning poker (time
consuming)
22. T-shirt sizes
Potential upsides
Useful to avoid bringing “elephants” into
Work In Progress
Could be used to limit work in progress
Easy to pick reference items from the past
Developers like the conversation it triggers
Simple to do
Requires very little detail
Potential downsides
Converted to numbers quite often, numbers
that get used to forecast when work might
be done
23. Wall / table estimation
Potential upsides
Useful to avoid bringing “elephants” into Work In
Progress
Could be used to limit work in progress
Easy to pick reference items from the past
Developers like the conversation it triggers
Simple and quick to do; requires very little detail
Guesstimate for potential value sized as well as
effort typically, priming ordering for value divided
by size
Potential downsides
Converted to numbers quite often, numbers
that get used to forecast when work might
be done
Often one and done – should be revisited
regularly
24. Guesstimating / counting the number/
range of items to deliver a goal
Potential upsides
Suitable for recurring probabilistic
forecasting or rolling-wave forecasting,
giving dates and uncertainty
Developers can “ballpark” the range
Useful for sizing a chunk of Product
Backlog, e.g, “elephant” sized items in the
Product Backlog
Can be used across teams
Potential downsides
People prefer relative sizing, and almost
“cannot let go”
Misunderstood that all items need to be of
equal size
For non-software different product backlog
item render it like comparing apples with
oranges
Prone to the use of averages
25. Rightsizing
Potential upsides
Simple
Less “analysis paralysis”
Supports recurring probabilistic forecasting
Potential downsides
Items right-sized just in time or in product
backlog refinement
Misunderstood that all right sized items
must be of equal size
Disconnect in Kanban community about
use of item split rate to support
probabilistic forecasting
If most days a team has no throughput,
probabilistic forecasting will have low
quality
26. #NoEstimates
Potential upsides
Split items as necessary, potentially into
discovery items
Small batch is the goal
Forecasting using data – “running tested
stories”
Accepts uncertainty and imperfect information
Useful for recurring forecasts
Low time investment
Seeks a mixture of item sizes
Potential downsides
In the wrong hands, splitting items into
nonvaluable items
People prefer to be wrong than uncertain
28. “John, that’s
about ten
minutes of work,
but things are so
crap around
here, make that
three days”
Estimated effort has little to do with how
long something takes
29. Variable quality with sizing an item
Factors for how long things take
The batch size – the level of effort actually needed
Waiting
time
…
Sizing for the level of effort considers
Complexity of the work
Riskiness of the work
Whether we did something similar before
Perception of skill levels required to complete the
work and availability of those skills
Availability of tools and skills using those tools
If you’re good, dependencies
33. Waiting time
Reduced by
Working on smaller batches
Working together
Leaving slack so people can help each other
A better understanding of how the work works
Active management of work in progress
Flow review & improvement rigor
Starting work mostly when we have
• capacity to start
• alignment with our dependency partners
• alignment upstream and downstream
Increased by
High utilization of people
Pushing work into the system before capacity
allows for anyone who does work on the item,
including final review
Lower quality of in progress queue management,
e.g., re-prioritizing in-progress items based on
potential value
Lower quality of dependency management /
elimination
Contradictory management of the level of
constrained-resource or shared-resource queues
34.
35. If your forecasts are routinely
correct, you're a freak of nature
Forecasting is rarely perfect due to the following:
•Waiting time due to dependencies is a huge factor in how long work takes and is affected by many
unpredictable events.
•Even in straightforward work environments, people overestimate how efficiently their day will go.
•Often, people doing complex work in the pursuit of speed leave work behind them that is untidy and
potentially embarrassing (accidental complication).
•Complex work involves many unknown variables.
•Lack of focus
•Changing priorities
37. Monte Carlo simulations
model a future based on
data and assumptions
Forecasting, at its essence, is
about risk management
It answers the question - How
much risk is contained in our
current plans?
Lower quality forecasts also
mean inadequate risk
management
38. Estimation
qService Level Expectation based on an educated guess, e.g., 85% of right sized items are done
in 18 days or less
qIndividual item sizing – useful if you only need to focus on one next unstarted item
qGuesstimate Probabilistic item forecast - guesstimating a range of a number of valuable items
to deliver a goal, with 90% confidence min/max
qProbabilistic guesstimate story point forecast - guesstimating a range of a number of story
points to deliver a goal, with 90% confidence min/max
qStory point range - guesstimating a range of a number of story points to deliver a goal and using
probabilistic forecasting with 90% confidence min/max
Options for managing expectations
39. qService Level Expectation based on cycle time data, e.g., 85% of right sized items are done in 18 days or less
qIndividual item age – useful if you only need to focus on one next started item but unfinished item
qData Probabilistic item forecast - 90% guesstimating a range of a number of valuable items to deliver a goal, based on throughput data of valuable
items
qRolling wave forecast - Throughput data range - 90% guesstimating a range of a number of items to deliver a goal and using throughput data
qThroughput data average - Best guess of number of valuable items divided by average throughput data (number of items done) per
day/week/sprint/month…
qProbabilistic story point forecast - 90% guesstimating a range of a range story points to deliver a goal and using probabilistic forecasting based on
story points data
qStory point data average - Best guess of number of story points divided by average number of points really done per day/week/sprint/month…
qCounting subtasks - Best guess of number of non-valuable items divided by average throughput (number of non-valuable items done) per
day/week/sprint/month…
Options for managing expectations
Forecasting
40. Estimation
qService Level Expectation based on an educated guess, e.g., 85% of right sized
items are done in 18 days or less
qIndividual item sizing – useful if you only need to focus on one next unstarted item
qGuesstimate Probabilistic item forecast - 90% guesstimating a range of a number
of valuable items to deliver a goal, based on guesstimate min/max range of valuable
items
qProbabilistic guesstimate story point forecast - 90% guesstimating a range of a
number of story points to deliver a goal, based on guesstimate min/max range
qStory point range - 90% guesstimating a range of a number of story points to deliver a
goal and using probabilistic forecasting based on guesstimate min/max range
Forecasting
qService Level Expectation based on cycle time data, e.g., 85% of right sized items
are done in 18 days or less
qIndividual item age – useful if you only need to focus on one next started item but
unfinished item
qData Probabilistic item forecast - 90% guesstimating a range of a number of
valuable items to deliver a goal, based on throughput data of valuable items
qRolling wave forecast - Throughput data range - 90% guesstimating a range of a
number of items to deliver a goal and using throughput data
qThroughput data average - Best guess of number of valuable items divided by
average throughput data (number of items done) per day/week/sprint/month…
qProbabilistic story point forecast - 90% guesstimating a range of a range story
points to deliver a goal and using probabilistic forecasting based on story points data
qStory point data average - Best guess of number of story points divided by average
number of points really done per day/week/sprint/month…
qCounting subtasks - Best guess of number of non-valuable items divided by average
throughput (number of non-valuable items done) per day/week/sprint/month…
Options for managing expectations
41. Better options
Manage expectations about uncertainty not
dates
qWe're using an empirical approach
operating one Sprint at a time
qThe Sprint Goal is not even a guarantee
qThe real answer is we don't know, but let's
start and learn quickly"
qYou might not even use Now?, Next ??,
Later ???
Being agile - don't manage expectations at all,
let people go see
qDiscover and deliver capabilities
qReview outcomes with the customers and
end-users
qLearn what can be learned
qAct on what we have discovered
42. Sizing is
devalued by
•Not having caveats associated with the start date,
e.g., nine weeks from the date we start
•Not recognizing the amount of work in progress and
the progress (or not) of that work
•The severity of impediments
•Not ordering items higher up the Product Backlog
according to delivery risk
•A sub-optimal approach to handling dependencies
•Confusing outputs with outcomes; a customer/end-
user outcome is a change in customer/end-user
behavior
•Not engaging in discovery activities when the risk of
not harvesting potential value is high, compounded by
assuming that every item moves from discovery to
delivery
•Delusions of accuracy and pursuing more accuracy
43. Key take aways Avoid story points, counting non-valuable product backlog
items, counting unDone work as Done, use of averages
Avoid
Consider historical reference items but beware
of accidental complication
Consider
Try probabilistic forecasting based on counting valuable
product backlog items to Done
Try
Try #NoEstimates and “rolling wave forecasts” of valuable
product backlog items to Done
Try
For complex work, promote managing expectations about
uncertainty over managing expectations about dates
Promote
47. About me
agility chef, executive agility
guide, product manager
#2 Agile Thinkers 360, Top
50 Agile Leaders
Leadershum
Flight Levels Coach,
ProKanban Professional
Kanban Trainer, Scrum.org
Professional Scrum Trainer,
LeSS Friendly Scrum
Trainer
author of Kanplexity™,
underpinned by Cynefin®
creator of Xagility™ co-author of Kanban Guide
Host of Xagility™ & Agility
Island podcasts
Organizer for Meetup LeSS
Baku Meetup group which
was active during covid - an
official scrum.org
community and an official
LeSS meetup
48. Ideal time
Potential upsides
Time is what the customer wants
Simple to do
Potential downsides
When was you last ideal day?
Does not include waiting time, the 90+%
contributor of how long work takes
Doesn’t help infer when the work might be
done
Supports a people utilization mindset
49. Cost estimation
Potential upsides
Time is what the customer wants
Simple to do
Estimating the number of sprints could be
useful for commercial bids for example
Potential downsides
Less useful for actionable Product Backlog
Items that would go into a sprint
50. Three point (min, mid, max)
Potential upsides
Reveals some of the uncertainty
Room for optimists and pessimists
Does not use averages
Can be used for number of items, number of
story points, ideal time, reference items
Waiting time is included in our memory of how
long it takes
Simple to do
Can be converted to story points
Potential downsides
Average performance often used against
mix/max sizes for forecasting afterwards
Only for the team
Prone to inflation
Can be converted to story pointsJ
51. Get stronger flow...
without adding more people
Better to have slack than overwhelm, so
people have time to help each other
Split items into smaller but still valuable
items when needed
Show empathy within the workflow, but
also upstream and downstream
Look after aging
• unblock, focus, finish / cancel
• do ensemble work
Don’t forget to feed the system
Lower aging =>
Lower cycle times =>
after a time-lag ...
More stable throughput… then
higher throughput
Prioritize within throughput, adjust
for noise
52. Other sizing
sub-optimal
trends
•Size per skill - typically caused by focus on resource
efficiency over flow efficiency
•Size inflation. In extreme cases, I refer to this it’s as
bingo
•Not taking quality seriously- typically caused by
pressure for more "velocity"
•Not taking the customer seriously
•Size normalization across teams
•Counting complete but fake product backlog items,
items that don't deliver value, as throughput
•Not focusing, not finishing
•Delusions of predictability for work that is
uncomparable with work from the past
•Lack of discovery to find the items we maybe should
not build; if we run low-cost experiments, we might fall
upon better ideas
53. Community
opinions on
Monte Carlo
simulations
Communities are not aligned on this approach.
One project is only executed once
While probabilities may help inform decisions,
the problem is that they don't make the
decision any easier
Estimation is often used as a proxy for a
decision (should we do this project or not?)
The reasons for using estimates differ from
probabilistic forecasting.
I have seen many probabilistic forecasts based
on guesstimates and a lack of history, yet they
were not far off in the end
54. Often there is
another question
behind the
question “when
will it be done”,
such as:
•How can I transfer worry to someone else?
•What progress is being made?
•What risks remain?
•When will we get some return on this investment?
•What trade-offs can we tolerate regarding which work
can discover/deliver the potential value, e.g., the 80:20
rule?
•What trade-offs can we tolerate in terms of reducing
some or all of effectiveness, efficiency, and
predictability, e.g., running some experiments?
•What progress trade-offs can we tolerate in terms of
required "dead work" to avoid execution bias, such as
laboratory setup?
•How much investment will go into acquiring skills,
e.g., education or apprenticeship?
55. A meta-question
of "what does
winning the game
mean?" is well
worth considering.
Is the team being given a game it can win?
And if the team can win, what are the odds?
Probabilistic forecasts can help, e.g., Monte-
Carlo simulations
Despite the hazards, people fear that
stakeholders will make up arbitrarily fixed
undoable dates in a vacuum
Sometimes teams want to attain a ballpark
date range to get ahead of stakeholder
expectations
Interestingly, most of us can accept a weather
forecast that gets updated regularly based on
the latest information