I live in Colorado, which boasts some of the world’s best hiking trails and North America’s greatest concentration of mountain peaks over 14,000 feet (nearly 4,300 meters). There are so many mountains over 14,000 feet high here that they are referred to simply as “fourteeners.” Most of Colorado’s fourteeners are non-technical routes; no special equipment is needed and anyone in good shape can make it to the summit.
This means there are a couple of different ways to climb a fourteener. One approach is to drive to the base of the mountain and start walking toward the highest thing you see. This will almost certainly be a false peak—once you’re reached it, you’ll see a higher point that had been obscured by the false peak. So walk again toward the highest point you see. It, too, will probably be a false peak. But, keep this up long enough and you’ll eventually find the true summit. In doing so, though, you will probably have to descend into a few valleys only to climb higher on the other sides. The approach will feel highly inefficient.
A second way to climb a fourteener is to purchase a topographic map, identify a route up the mountain, and then proceed that way. Looking first at a topographic map allows you to plot a course to the summit that avoids much of the inefficiency of the first approach. Of course, we must be careful not to value our route plan too highly—a stream we plan to cross may be too deep when we get there or a rock slide may have made a trail impassable, and we’ll need to alter the route when we encounter these problems.
An agile team does release planning to avoid the same type of problems we avoid with a topographic map when hiking a fourteener. A release plan helps a team avoid finishing a series of sprints and feeling that, while they always worked on the highest priority items, the collection of work completed does not add up to a satisfying whole.
Tags: agile release planning
Hi Mike,
I fully agree that release planning is important. The challenge is how to set up release plan? Would you please give some instructions.
Jarred
Hi Jarred–
I recommend looking at chapter 13 (“Release Planning Essentials”) of the Agile Estimating and Planning book.
Thanks Mike
Hello Mike,
I’ve gone through most of your articles and presentations on Agile Planning and Estimation and the question that popped up in my mind is the following:
I wonder how do you relate the statements that backlog prioritization during the release planning should preferably be done on the level of themes/epics, yet that backlog should consist of and be estimated on the level of user stories, yet that according to just-in-time elaboration principle, many stories (in my Agile projects – majority) will be produced/disaggregated during the iteration planning?
(hope I did not misinterpret your statements)
I understand that in order for release planning to be effective and subsequent release tracking (e.g. burndown chart) to be meaningful, there ought to be a baseline backlog which does not change much as a result of elaboration/disaggregation. But in order for it to remain as such, it should apparently be estimated and kept on a theme/epic level which contradicts to the proclaimed user-story based nature of the backlog. Besides, estimation on a theme/epic level is really difficult as you properly mentioned in one of your articles
Frankly, we did not find a universal solution to this problem short of waterfall-style upfront elaboration/planning. One of the approaches that we attempted to use is to have a mid-term planning covering a span of several iterations (akin your lookahead planning). This gives some confidence in a mid-term and allows to refine release plan but it does not really alleviate the problem of overall release planning, since in the absence of a baseline backlog of user stories, we don’t have a good measure of the release progress and confidence in the end result (whether we can deliver Minimum Marketable Features by the target timeframe) is not particularly high
I am wondering what are your ideas on this
Hi Dmitry–
First, I don’t say that stories should be disaggregated during iteration planning. This should ideally happen prior to that. Some will be disaggregated during the meeting but those should be exceptions.
There are two levels of prioritization. I recommend using a formal approach such as relative weighting, theme screening, theme scoring, or such for this. These are described in Agile Estimating and Planning. Comparing epics and themes this way lets the product owner clearly explain the prioritization to others: “I put this one on top because…..” After themes/epics are prioritized, I think of the product owner as “opening up” each theme or epic and looking inside it at the individual stories. To prioritize these, I don’t advocate a formal approach but rather rely on the product owner’s deep knowledge.
By doing it this way we can formally prioritize big goals against one another but then have flexibility in how each goal is achieved and can make those decisions just in time, as you noted above as a goal.
Thank you, Mike!
Sorry if I misinterpreted your words about disaggregation. I totally agree with you on two levels of prioritization. There are some challenges with this, however, that we are experiencing on release planning level:
- 1. Two level prioritization somewhat obscures the simplicity and clarity of the flat backlog prioritization. Not once I and my product owner were faced with questions like “whether feature 3 in theme 1 is more important that feature 1 in theme 3″
- 2. The concept of the backlog “being elaborated and unfolded” makes it more difficult to establish the real baseline for the project, track its progress (i.e, maintain burndown chart), and, generally, use velocity effectively for mid- and long- term estimation and planning
- 3. In the environments with a fierce internal resource competition, where resources are constantly being rebalanced between the projects, it is more difficult to justify the need in specific number of resources (so, just fund the project) if scope targets are given on a high level (themes) and committment is avoided
One of the common solutions for these challenges was to come to the concept of a Minimal Feature Set acceptable for each theme in order for it to preserve its wholesome business value. Thus, features are not prioritized within a theme but rather broken into two groups: included in MFS (“must haves”) and not included (“nice to haves”). Themes remain ranked, however, and serve as a basis for prioritized iteration planning
Further on, the concept of MFS can be used for resource committment as well. In other words, resources are calculated based on the fixed release date and rough effort needed to deliver MFS for major business objectives (themes). This smells like a waterfall-style committment, but in reality MFS can be renegotiated with the product owner (what is really “must” and what is “nice” for a particular theme) especially if this is driven by changing business needs
All of this, inevitably, requires some initial elaboration of the backlog during the release planning, from the themes/epics level down to features. The challenge is that this disaggregation may be coarse and estimations may be rough which gives a poor baseline for subsequent planning and tracking. The solution here may be to use relatively non-volatile measures of estimation, such as perceived business value of the features, for overall release tracking, and use technical (effort/size – hours/stories) estimates for tactical planning (akin your lookahead planning) using the results of the detailed disaggregation (into stories)
I would be glad to chat with you about these topics in Sunnyvale in November during the Planning and Estimation training course
Thanks a lot!
Dmitry