For so many companies, inability to estimate, forecast, budget, and manage expectations of clients, users, and management is a big issue.
Below, are some of the most commonly heard concerns:
- 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.
- 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 should we provide 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
This will provide insight on 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.