Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see:
- Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work.
- The product managers and project portfolio managers depend on the team finishing everything the team commits to. Too often, they use the team’s commitments to create external dates.
Planning for an entire quarter at a time often becomes “push” planning—the teams push everything they can into one quarter. If everyone gets together, it’s an expensive meeting and the results are questionable. Teams have less adaptability and resilience to change what they do. In my experience, the team needs to change what they do within the first couple of iterations.
One-quarter planning, especially across multiple teams, has these assumptions:
- All the feature sets have an even distribution of features. That is, feature set A has the same number of features as Feature Set B.
- The value of all the feature sets is similar.
- The arrival rate is predictable for all features.
- The team(s) can properly estimate what they can finish in one quarter.
Very few people or teams can accurately estimate a quarter’s worth of work. If you use the ideas of epics and themes, that helps people realize the work is big. On the other hand, people have the assumptions as above, especially the even distribution of value for all the features in the feature set (what you would call an epic or theme).
Here is an alternative. Think about feature sets (which helps with the idea that this is Big Work), counting features, MVPs (to validate a business hypothesis), and MVEs (to learn something small with an experiment).
Let me discuss the idea of feature sets and counting features. You notice I don’t use the words epics and themes in my writing. That’s because the definitions are not consistent between teams and tools. I use feature set to describe all the features for one chunk of work.
Here’s an example. You might want “Reports” in your product. Reports often include searching by some form of type. You might want:
- Reports by product
- Reports by geography
- Reports by customer or customer type
You might even want to restrict certain types of reports depending on the user. Now we have a security issue which requires different features.
Instead of “Reports” as an epic or theme, consider Reports as a feature set. (I would split this into “Reports by product,” “Reports by geography,” “Reports by role,” “Reports by customer,” etc. Note that this starts to help the more senior people realize that “Reports” is too big, and they need to think about MVPs and MVEs for different kinds of reports.
Now, we can create the feature set as a brainstorming activity:
- In teams of three (developer, tester, PO/BA/someone else), write cards as fast as they can to brainstorm all the reports. I often timebox this to 7 minutes.
- At the end of the timebox, get together with everyone else in their team and look at their cards. Organize the cards by removing duplicates, and splitting features they realize they need. I often timebox this to 7 minutes.
- Add up all the features in this feature set. What does the team think—do they think they need more brainstorming time in their smaller groups or as a larger team? If so, another 7 minutes to brainstorm. (I prefer smaller teams, but that’s me.) Then do the duplicate removal/split again. If they think they have more features, this is a gigunda feature set and we probably don’t know enough about it. I ask the team to agree on no more than three MVPs and three MVEs they commit to because the unknowns are too high. Assuming the team can settle on the features (the feature set is not too large), continue to step 4. Cycle in this step as long as they need, but if it’s more than two times, I ask what the team members’ concerns are.
- Count the features in the feature set. Yes, just count them.
- Look at the historical cycle time (time it takes for a team to move an item from Ready to Done) for this team. If the team has not calculated cycle time, assume each feature takes three days if the team mobs/swarms on it. Why three? Because that’s a place to start. It might not be right. But without historical data about cycle time, no one can know anything. I have found that when teams think about an average of 3 days for a story, they tend to swarm or mob, and that helps their throughput.
- Now, for time-based one-quarter roadmapping, count the number of stories a team can deliver in 12 weeks. This is why cycle time is so important. The team can attempt to commit to this work and see where they are as they proceed.
How is this different from estimation the way I’ve seen it?
- The team doesn’t estimate tasks. They stick with features.
- They don’t try to do detailed estimation. They use their historical cycle time data (if they have it) or a SWAG of 3 days per feature to count.
- They can “estimate” an entire feature set in under 30 minutes.
It’s not that I don’t like estimation. I have found that for me and teams I’ve worked with, one-quarter estimation is useless—it’s too large. Things change—someone wants more of one thing and a change to something else. I found it’s even less useful if we try to estimate tasks. Too often, “If Rob takes that task, it’s a half-day. If I do it, it’s 3 days.” Instead, ask the team to work together (swarm or mob) and they can finish with the person with the “most” knowledge also explaining what that person did.
I stick with features, not tasks. That’s because customers buy features. I want to know the MVPs and MVEs because we will learn the most that way. I want the feedback.
I don’t have a magic bullet for time-based one-quarter estimates. I’ll talk next about creating a smaller rolling wave than a full quarter.
| Reference: | Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets from our JCG partner Johanna Rothman at the Managing Product Development blog. |
