Forecast and Planning in Scrum

• Metrics
  • "The most important metrics are: did we execute the way we said we would, and did we deliver the value to the business that we had promised?"
  • critical look at metrics and how easily they can be abused
  • We can trust that any measurements taken were accurate and extensive, but the data was informationally useless when applied in pursuit of this supposed science
  • abundance of metrics, irrespective of the precision, cannot cheat a fundamentally weak correlation between hypothesis and data
  • Measures like "story points" have become commoditized as a surrogate currency
  • The actual provision of value to stakeholders is ignored as a quantity too difficult to measure, and so cock-eyed metrics are appropriated in compensation
• Estimations
  • how much work a team believes it can take on
  • is their data which they may use for their own projective
  • One reasonable forecast might be how much work they think is likely to remain at a given point before one of those valuable increments is delivered to customers
  • The shorter the time-period under consideration, the smaller the leap-of-faith
• Myth: Story Points are Required in Scrum
  • *“work may be of varying size, or estimated effort”, it does not prescribe how this estimation should be done*
  • Scrum Guide does remind us to use an approach that respects the complexity of software development and to not let estimation replace the importance of empiricism itself
• PURPOSE
  • The primary purpose of estimates in Scrum is to give Development Teams a rough sense of the amount of work they can pull into a Sprint
  • conversation itself: ‘What is involved?’, ‘How should it work?’ and ‘What work is needed?
• 4 important insights concerning estimates
  • Accurate estimates are impossible
  • An estimate can’t be a guarantee
  • estimation is a form of waste
  • estimates are the result of a necessary conversation within the Development Team to arrive at a shared understanding
• release planning
  • decisions to cut quality need to be reflected in your company accounts and as such those decisions need to be made by your executive leadership and should not be made by Developers
• unpredictability
  • Manufacturing lives in the predictive world. Software lives in the empirical world
    • always doing new product design, therefore, we have no certainty…and this often results in chaos
  • All is not lost however as we can, by looking at our history of delivery for similar things, make a pretty good forecast…
  • expend effort to make that forecast as accurate as possible while accepting that more time spent planning does not necessarily affect the accuracy of that forecast
  • Graph Diminish return:
    • Estimate Accuracy / Estimation effort
  • In order to increase the accuracy of our forecasts, there are several simple activities that we can perform

Myths: There is No Planning in Scrum

• can lead to two negative consequences.
  • 1. The people in organizations responsible for budgets, product management, sales, and marketing may be unwilling to try Scrum.
  • 2. Scrum Teams may not be effective in their use of Scrum
• The reality is we plan A LOT in Scrum, we just plan differently to optimize effectiveness
• emphasize the activity of planning over the plan itself
  • Is collaborative
    • in all the events
  • the people doing the work they own the plan
    • The Development Team owns the Sprint Backlog
  • is part of every Event
    • inspecting and adapting
  • the way planning is done reduces waste:
    • minimize time spent analyzing things that may never happen
    • minimize time spent analyzing to an impossible level of accuracy
    • incorporate meaningful feedback every time we plan
• still recognize the inherent unpredictability in complex software development

Forecast Product

• shows how much work is likely to remain over time, and projected dates for its likely completion
• a Product Burndown attempts a forecast over perhaps the entire corpus of work
• these estimates are not intended primarily for Development Team consumption, but rather for the benefit of senior stakeholders and other higher-ups who wish to be appraised concerning longer-term delivery outcomes
• Shouldn't those people care more about receiving value?