Our iteration planning meeting (IPM), like many, is not really a planning session but a status report and demo for managers and SMEs who are generally mostly disconnected from day-to-day development and support. Team leads provide information and our PM assembles the slide deck and gives the presentation.
In a recent retrospective we talked about how for two weeks in a row, the only questions attending stakeholders had were about about release dates and release contents. We agreed to add a slide to highlight this information. I think that will help but it's not enough. Following are some observations I shared with our PM and GM.
As I see it, our biggest problem, and it may be true for you too, is confusing the recitation of lists of things with telling a story that the stakeholders can connect to.
1) Our deck includes one slide that shows how the business handled by our application is growing (or not). It is the most interesting thing in the presentation but the rest of the material doesn't connect to it. When I see this slide I have two questions, "Are these numbers in line with our expectations?" "And what are we doing to keep things moving along as-is or fix what is deficient?" In short, I am looking for the slide to be followed by a statement of strategy.
2) Assuming that the deck gave a clear picture of strategy, then, as a stakeholder, I'd like to see how the stories just worked and being planned match up to that strategy; and I'd like to know how the current priorities fit the strategy too.
3) Listing issues that came up in the past iteration is not useful if we don't also show how these issues affect the strategy and talk about their solutions and status.
4) A long list of priorities is not effective without relating them to the business strategy and giving projected timelines and dependencies.
Obviously, no one ever works a dozen priorities at once. There is usually some short list of 1 - 5 things that are getting immediate attention. That makes one slide. Then there is an equally short list of things expected to come to into play within the next 1-2 months and some work (research, design) may be starting or going on already.
Finally, there is a third short list of things brewing on the horizon that have the potential to become very important any time between now and the next 4 or 6 months. These are under watch but no one is acting on them yet. Three slides, three short lists with discussion about how each one fits into the business plan.
5) Just giving a count of open and fixed bugs is not informative either. People want to know what the trendline looks like. Are things getting worse, better or holding steady?
Put the numbers in the deck but focus the talk on the trend -- the direction and its implications. Also take time to touch on the top issues that were faced in the past week(s) -- usually just two or three, never more than five.
6) Give a summary. And be sure it packages the message you want everyone to hear.
It's a cliche but every journalist knows you have to tell your audience what you're going to tell them (agenda, introductions), then tell them the story (the deck), then tell them what you've told them (the summary). Here's an example of a summary that takes care of the message:
"So in conclusion, many new accounts have come online but they are not necessarily using the application regularly. We are targeting improvements in reporting, and implementing analytics to better monitor usage and identify pain points. We are making enhancements to the admin functionality to make it easier to support accounts and fine-tune pricing.
"We are getting ready to add new business lines. The team velocity continues to trend up and we are getting three time as much work completed now per iteration than at the start of the quarter. Our next release will deploy on Thursday and it will contain the things listed on the next slide. (show next slide and tell people they will get a copy of it, but don't read it aloud. Ask for questions or comments instead.)"