06/09 – LESS TALKS: Never-ending saga with Estimation. Can LeSS help us debunk this?

 

Materials used

Additional assets recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

For so many companies, inability to estimate -> forecast –> budget –> manage expectations of clients/users/management is a big issue.
This is not surprising.Under assumption that everyone understands
Scrum and has first-hands experience with all of the below:

  • “Our teams cannot accurately estimate work”
  • “Our teams are not stable and not dedicated. Capacity is unpredictable”
  • “Not everyone is cross-functional and everyone does their own work. What is the point of estimating together?”
  • “Our teams get confused with historical Velocity-driven planning vs. Capacity-driven planning. When to use what and why?”
  • “Our teams have hard dependencies on other teams. Some resources are shared. What can we do?”
  • “Our estimation and metrics get so-so fudged, as they roll up through multiple organizational layers to the top”
  • “Our organization is fractal: one PO per one team, each team works in a silo. We cannot “standardize” estimation”

And most of the below:

  • -“Individual teams are more or less OK, with estimation, but how to we ‘normalize’ estimation across multiple teams?”
  • -“How do we ‘scale estimation’, so that our sr. management can get a sense of how much work we have?”
  • -“When is the best time to estimate? How provides estimates?”
  • -“How can we effectively estimate with many developers not be co-located?”
  • -“When and where is knowledge about the estimated work being used?”

Let’s talk about how most of these problems can be addressed in Large Scale Scrum.
Instead of implying that LeSS is a silver bullet or blanket solution to everything, lets focus on specific dynamics of LeSS, with respect to:

  • specifics of LeSS product group design
  • intimate synergy between teams
  • roles & responsibilities, artifacts & events

in order to understand WHY estimation and forecasting by LeSS product group (e.g. 50 developers) would be more reliable than the same, done by e.g. 50 developers of a traditionally-designed organization.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please help us fight spam. Lets make sure you are not a robot !!!