Good communication between product manager and team, between value appraisal and product development, leads to success. It helps you build the right thing at the right time. When the Product Owner and Development Team communicate well, the Product Owner can forecast feature delivery dates with a statistical likelihood. It promotes great architectures. The Development Team can build, but not over-build, a resilient architecture suitable for likely future needs.
I developed the Forecast Horizon metric to measure team communication. Forecast Horizon is the sum of work estimates from the top of the backlog through the first unestimated Product Backlog Item. Since many Product Owner put unestimated Backlog Items at the top of a Backlog, you may choose to skip unestimated backlog items that have been modified since the last Sprint Planning or Grooming meeting. Forecast Horizon can be expressed in team-time, by dividing by a recent average velocity and multiplying by sprint duration. In my work, I usually talk about Forecast Horizon in weeks.
A Forecast Horizon of zero is the worst. This means the topmost item in a team’s work backlog is unestimated. Why is this a problem?
- The developers doing the work have not estimated the top-most item, so the Product Manager can’t responsibly forecast when the next item will be delivered.
- The top-most Backlog Item has likely not been considered in forming the architecture.
- The team never thinks at a bigger scale than the next dinky piece of work.
I realized that a zero-horizon backlog means Product Owners had to have made their own work estimates to responsibly order the backlog, and this dis-empowers the team. Watching team-after-team slog through Product Owners saying, “Surprise, here’s your next Sprint, let’s estimate it,” They might as well hire developer body-shops. There was no creativity left in engineering; and, honestly, how can you hold development teams accountable for estimates in these situations?
Yet, Forecast Horizon is zero for many teams, particularly those teams who advocate “no estimates.” To operate with no estimates in the Product Backlog, there are two possible approaches:
- Don’t estimate user stories until the Sprint approaches, then only estimate stories the team feels it can complete. This eliminates the ability of the Product Owner to make thoughtful, profit-driven tradeoffs in ordering the Product Backlog.
- Split and refactor all user stories until they are approximately the same size. You can then assign “1” to all the stories and measure the Forecast Horizon as I described. In practical terms, this allows for forecasting one or two Sprints forward. However, when attempting to forecast further into the future, you end up with so many stories that no one can thoughtfully assess market value, risks or architectural implications at the larger scale that long-term planning demands. In other words, you can’t see the forest for the trees.
Because of the forest-tree paradox, No Estimates advocates set up developers to be robot workers who serve the Product Owner. Big thinking developers—including architects and product innovators—become slaves to a endless, micromanaged backlog of little stuff. I think the Product Owner could get a lot more value from the team, by encouraging their long-term thinking to be big.
In my experience, Forecast Horizons of 2–6 months are associated with higher value creation and better architectures. This sounds daunting for many teams, because they have dysfunctional Sprint Planning and Grooming meetings, where estimation is stupefying and slow.
Estimation can be interesting and fast, if the Product Owner and ScrumMaster work together. For near-term backlog items, you can use bulk estimation to rapidly estimate lots of similar sized stories (see Bulk Estimation). For long-term backlog items, just “go big.” Product Owners can work top-down to express their product goals from a 1-year vision, using story-splitting to first create multi-month Epics and then get acceptable Sprint Backlog Items. At each stage, including at the 1-year vision stage, I counsel Product Owners to get team estimates in “decimal Fibonacci” numbers (1, 2, 3, 5, 8, 10, 20, 30, 50, 80, 100, 200, etc.) from teams.
Forcing teams to estimate extremely large Backlog Items provides important value that few coaches or trainers appreciate:
- Teams engage very early in architectural discussions. Forcing a team to “estimate large” makes them consider architectural tradeoffs well before they are “baked in”, and discuss them with the Product Owner. Obviously, most architectural issues have impact on what the Product Owner might do in the future, so these discussions then create a virtuous cycle where the Product Owner can then explore market needs better to help guide the team’s architectural choices.
- The Product Owner can make significant, well-informed tradeoffs early, and then pursue deeper market or risk exploration with high-ranked Epics, using Lean Entrepreneurship methods or alternatives.
- The Product Owner can get estimates on alternative Product Backlog Items, which solve stakeholder problems in different ways, to make better decisions on a profitable solution.
The result is a fractally structured Product Backlog, with mostly small backlog items at the top, and larger Epics and Visions at the bottom. Is there an optimal number of PBIs in a Product Backlog for a project due at a particular time? You should be able to think about the implications of the whole thing, while being able to make tradeoffs in short and long time scales. Like other fractal structures, a fractal backlog grows by the log of the Forecast Horizon.
As an agile coach in large companies, I have found great value in measuring and increasing Forecast Horizon. Teams start operating better, address and eliminate dependencies much earlier, and innovate more deeply.
Can we help you improve your ability to forecast, make thoughtful product and architecture tradeoffs, or get your Product Owners and teams conversing on a deeper level? Contact us.
