How often do you refine your release plan?

Replies to This Discussion

Permalink Reply by Scott Gilbert on March 4, 2010 at 0:19

The not very useful answer is that you update as often and whenever necessary based on new information that is gathered during the execution of the development and re-planning process. For example since you mentioned that you are using time boxed sprints, the moment you know you're not going to meet or hopefully you are going to exceed your sprint goals...this could potentially have a material impact on the overall plan. I would say that the product manager should be updating the backlogs and in turn the release plan after every sprint until such time as the amount of new information or rate of change flattens out and the team is "running down hill" towards the release goals of date, scope and quality.

Socializing with customers (assuming you mean people who pay $ for your products) that's a trickier answer that I think is heavily dependent on the type of product being developed. For example, if I'm building big piece of enterprise platform infrastructure software I might not bother with smaller magnitude changes to the release plan but if we start to cut major features/capabilities from the plan or the date moves up or out by a quarter then I might update. If I'm building a volume consumer product then communicating with 10's of thousands of customers may not be needed. In short, your context really matters here.

Hope that helps and I look forward to seeing what others say on this topic.

Scott Gilbert
@AgileProductMgr

• ▶ Reply

Permalink Reply by Walter Bodwell on March 4, 2010 at 2:45

To me, a release plan is a forecast of when stories will likely be done in the release. It is a great way to get everyone on the same page as to what to expect (particularly when multiple teams are involved). But it is important to be clear that it isn't a commitment. Otherwise, you won't leave yourself flexibility to change the plan as you learn more.

Given that, I'd generally recommend updating the release plan after every sprint. That's when you'll know if there is any carry over and you'll already be revising what you're planning to take on in the next iteration. Right after sprint planning is a good time.

You want to update it in a place that the whole team can see it. If you're using a tool, that can be a great place. Make sure you specifically communicate out any major changes to expectations so that no one is surprised and you can use their feedback to help refine your plans.

I typically wouldn't communicate a release plan externally as it will be taken as a commitment and tends to be more detailed than you need. You might use it to determine what you're comfortable saying to customers. For example, the items in the sprints in the first half of the remaining iterations are pretty likely. Those in the second half are more risky. Those not on the plan are unlikely based on what you know currently.

Other tips are to communicate high level goals / themes not specific features / approaches and to communicate priorities (i.e., here's how we're prioritizing things, does this seem right?). By communicating the priorities you can reinforce that those things higher on the list are more likely and those things lower less so.

• ▶ Reply

Permalink Reply by Manish Manekar on March 4, 2010 at 6:17

Most of these questions are for the product owner and one who is specialized (Certified Product Owner) in Agile would know how best to handle it. I believe that we have a "theme for a release" rather than a "release plan". By large the theme remains the same even if details are renegotiated. The theme statement and a set of top priority product backlog shall constitute the release document. This can best be achieved if we have the theme and user stories well articulated.

In my experience, yes, we allocated user stories to future sprints. But it is just for reference/reminder and a sprint backlog is finalized only during the sprint planning meeting for each sprint.

• ▶ Reply

Permalink Reply by Patrick on March 4, 2010 at 14:34

Thanks for all the replies - great info!

When writing themes for the release plan (and perhaps this should be a different post), how do you go about writing the themes in such a way that they aren't completely open to allow for massive scope creep, but aren't too focuses so that you don't have any room for change?

Our customer wants more details in the release plan, to ensure that the overall vision is represented, but at the same time not so broad as to allow for scope creep.

I like the idea of allocating user stories to themes - but I also don't want to get down the slippery slope of building a waterfall type release plan.......

• ▶ Reply

Permalink Reply by Walter Bodwell on March 4, 2010 at 22:43

An example of a theme would be "Making it easier to integrate with our application". Stories under this might involve adding a REST interface for various types of information, exporting to a CSV file from certain screens, etc.

You might also call it an investment area. We're confident that we'll be improving things here, but we'll refine exactly where we'll invest and how much as we go. We're going to attack the highest value items first. What do you think is the highest priority?

• ▶ Reply