Now that we’ve covered the problem of estimating large agile projects, as well as some underlying considerations, I want to explore some scenarios and approaches that have been used in the community. First, a word about “large”. If we are talking about 3-5 teams, the problem of multi-team estimation tends to be quite manageable. The real pain comes in around 10 teams or so. However, for purposes of our discourse here, I am going to use a 4-team construct just to illustrate the considerations.
Context: We have four agile teams (Alpha, Beta, Gamma, Delta) all working on the same project. We’ve completed our latest major release, and now the Chief Product Owner (sometimes called a Product Manager or Program Manager) needs estimates on all the candidate initiatives (sometimes called projects or epics). We already have known, stable velocities for each of the teams, so we should be reasonable able to determine which initiatives will fit into the next quarterly release. Furthermore, the group has been a cross-functional committee called the Product Ownership Team, consisting of the Chief Product Owner , the four team-level Product Owners, and a couple architecture and operations tech leads.
BEFORE the Release Planning meeting: During the previous release, the PO team has been continuously grooming the backlog of upcoming epics continuously in preparation for the release planning event. During the regular team-level grooming meetings, each PO and tech lead has been soliciting team-level size estimates of the upcoming epics. For example, the Scrum Guide allows for up to 10% of the dev team’s work time be used for grooming activities in support of the Product Owner.
STARTING the Release Planning meeting: All 50 people in the program convene together in a large room. The Chief Product Owner give a quick overview of the upcoming strategic goals. Then, he reveals the aggregated estimates, based on rthe team-level input that has been solicited during the previous release:
- Social Media Initiative = 47 Alpha story points + 22 Beta story points + 10 Gamma story points + 112 Delta Story Points = 191
- Performance Improvement Initiative = 12 Alpha story points + 45 Beta story points + 0 Gamma story points + 33 Delta Story Points = 90
- Realtime Data Dashboard = 125 Alpha story points + 8 Beta story points + 40 Gamma story points + 51 Delta Story Points = 224
Total Work = 191 + 90 + 224 = 505 points
Then we look at Total Velocity = (41.4 for Alpha + 55.2 for Beta + 41.3 for Gamma + 38.2 for Delta) X three iterations = 528.3
The Product Owner is proud of his math and declares, “Since our proposed work fits within our average velocity, we should be able to get all this done over the next 3 months….right?”
ADJUSTING the Release Planning meeting: Immediately, a number of people raise a concern that our understanding of the story point scale has deteriorated over the last few months. The meeting facilitator proposes they hold a cross-team estimation workshop to reaffirm their program-wide story point scale. They quickly pick a few of the backlog items for which they have a common understanding of risk and complexity. Then, they use spend a some time performing a planning poker tournament or Affinity Estimation for large groups. Then, they update their “estimation wall of fame” with the backlog items they all agree represent the best definition of 5 points or 13 points or such.
CLOSING the Release Planning meeting: With the common inputs all resolved, the teams then have breakout sessions where they review the proposed work, and go deeper into their team-specific backlog items, explore acceptance criteria, risks, integration points. They work together to understand whether they can reasonably commit to achieving the Chief Product Owner’s goals for the release. If new information changes the risk or complexity of backlog items, they re-estimate them on the spot. If we discover the work is too big for the upcoming release, we remove some of the work to achieve a minimum marketable feature that fits within the strategic constraints set by the Product Owner. This is called flipping the iron triangle. In the end, the meeting should close with a program wide confidence that we will be able to meet the release-level goals, because we have used our estimates to measure the work, and adapted the backlog to fit within our constraints.
Simplifying Observations. Many of you are reading this and thinking, “well of course that’s how it works”. But I believe there are some critical assumptions that make this story work:
- Everyone agrees the teams should operate on synchronized iteration schedules of 4-week duration
- Everyone agrees we all use story points, for all the benefits they provide
- Everyone agrees we need to have a common story point scale, so that we can easily aggregate and arithmetize the numbers
- The POs and Tech Leads have been soliciting input from their teams on the risk and complexity of each initiative from that team’s perspective.
- The POs and Tech Leads have been working together, outside of the agile development teams, to integrate and reconcile the estimates into a candidate plan
- The entire program comes together to verify & revise the estimates, and then use the estimates to adjust the backlog to fit the strategic constraints.
This is the first scenario. The next one I want to cover is the usage of ideal days across a similar program.
What about you? How have you been able to use story points across large programs?