Managers are frustrated by developer estimations. Why are the estimations always wrong? Why can't the team estimate better? What's the correct estimation approach to use?
Yes, with Continuous Delivery, we can have a relative stable Cost per Change (so estimations can be relative reliable)... but without Continuous Delivery the Cost per Change can grow exponentially (hence estimations are way off- could be 3x off, 10x off, etc...)
To restate Hendra's insight, the fallacy of estimates is that they attempt to size the effort required to complete a work item. The business should not care about this. What the business cares about is when a work item will be delivered. Cycle Time (gleaned from historical data) can predict when a single work item will be delivered. Thoughput (also gleaned from historical data) can predict when multiple work items will be delivered. Item Aging and WIP provide effective data points to enable the team to optimize its flow and make it more predictable.
As Hendra points out, Actionable Agile from Pro Kanban (requires license) will provide reports on these data. Mike Bowler's JiraMetrics (free) creates similar reports from data gleaned from a Jira project.
Cycle Time and Throughput do not tell us how to improve, but they indicate what should be improved. We want to make Cycle Time smaller, but more importantly, we want it to make it predictable. A Cycle Time scatterplot that shows items well above the 85% threshold reveals a problem in predictability. We may address this problem by prioritizing aging and/or blocked work items, by putting greater effort into right-sizing work items, or by adjusting our policies regarding WIP.
While Cycle Time and Throughput are historical metrics, WIP and Item Aging are snapshot metrics. Viewing these snapshots in conjunction the historical metrics, whether at a Daily Standup or in some other forum, will inform the team how to optimize its flow today.
EXAMPLE: The Cycle Time scatterplot reveals that 85% of work items are completed within 6 days. It also reveals that 3 work items in the past month took over 15 days to complete. Our Item Aging chart reveals that one item in progress has aged 12 days. The team may decide to swarm on this item until it is complete, and they may establish an experimental policy of prioritizing the most-aged items. They may also reduce the scope of the work item (heresy in Scrum) and decide to put more effort into right-sizing in the future.
With continuous delivery, implementing a minor feature doesn’t take 10x longer than estimated.
Yes, with Continuous Delivery, we can have a relative stable Cost per Change (so estimations can be relative reliable)... but without Continuous Delivery the Cost per Change can grow exponentially (hence estimations are way off- could be 3x off, 10x off, etc...)
To restate Hendra's insight, the fallacy of estimates is that they attempt to size the effort required to complete a work item. The business should not care about this. What the business cares about is when a work item will be delivered. Cycle Time (gleaned from historical data) can predict when a single work item will be delivered. Thoughput (also gleaned from historical data) can predict when multiple work items will be delivered. Item Aging and WIP provide effective data points to enable the team to optimize its flow and make it more predictable.
As Hendra points out, Actionable Agile from Pro Kanban (requires license) will provide reports on these data. Mike Bowler's JiraMetrics (free) creates similar reports from data gleaned from a Jira project.
Good points! Based on your work with teams, after you setup views of Cycle Time & Throughput, how did you use those metrics to help improve delivery?
Cycle Time and Throughput do not tell us how to improve, but they indicate what should be improved. We want to make Cycle Time smaller, but more importantly, we want it to make it predictable. A Cycle Time scatterplot that shows items well above the 85% threshold reveals a problem in predictability. We may address this problem by prioritizing aging and/or blocked work items, by putting greater effort into right-sizing work items, or by adjusting our policies regarding WIP.
While Cycle Time and Throughput are historical metrics, WIP and Item Aging are snapshot metrics. Viewing these snapshots in conjunction the historical metrics, whether at a Daily Standup or in some other forum, will inform the team how to optimize its flow today.
EXAMPLE: The Cycle Time scatterplot reveals that 85% of work items are completed within 6 days. It also reveals that 3 work items in the past month took over 15 days to complete. Our Item Aging chart reveals that one item in progress has aged 12 days. The team may decide to swarm on this item until it is complete, and they may establish an experimental policy of prioritizing the most-aged items. They may also reduce the scope of the work item (heresy in Scrum) and decide to put more effort into right-sizing in the future.
Very well explained!
For flow metrics,
1. Cycle time (single item forecasting)
2. Work item age
3. Work in progress
4. Throughput (using montecarlo simulation for multiple item forecasting)
The tools that we could use:
1. ActionableAgile Analytics
2. Flowpulse + Lighthouse by letpeoplework
3. FlowViz
ALSO: JiraMetrics (jirametrics.org) by Mike Bowler
Good to see this list!
Using flow metrics instead for forecasting.
Thanks! Could you elaborate further on flow metrics, and which tools you use?