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

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.

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

I fully agree that release planning is important. The challenge is how to set up release plan? Would you please give some instructions.

Jarred