Frame the conversation

Establish the theme of the next week(s), and tie it back to product and project goals. For example: "Just to reiterate, last week we focused on making our site more mobile-friendly, and this week we're going to revisit the sign-up flow with some improvements. This will help us convert more people coming in from our new mobile marketing campaign."

Clarify the stories

Start by looking at any stories still in progress from the last iteration, along with any pertinent information about features just finished. This should be a quick (less than 10-minute) process to jog everyone's memories and ground them in the work that's coming up.

Starting at the top of the backlog, step through each story. Talk through the user-facing value for a feature, ensure that any comps, wires, assets, flows, data, etc. are attached to the story. Clarify any acceptance criteria. The goal here is to be crystal clear on when a feature is "done done."

Complexity check

If it doesn't already have an estimate, each developer that could work on a story should roll on the points to deliver. If the implementation is not clear, they should have time to talk through approaches. That said, their role is to nail down a level of complexity, not pin themselves to a specific technical implementation. Based on the estimate size or developer feedback, stories can be nominated for merging or splitting up. If that's the case, capture the pieces of work as placeholders and update with details post-IPM.

Pay down debt

A healthy development process will incorporate refactors and tackle technical debt in concert with new user value. In addition to explicit tech debt chores, Product Managers and developers should look for opportunities to wrap this work into feature development. For example, if a story calls for adding a field to an existing form, you should consider also cleaning up the logic that delivers form validation errors.

Two iterations, max

Tracker will group stories into iterations based on the team's velocity. You should only step through stories once you've got two iterations' worth of estimated work. Keep the visibility to two weeks for quicker-than-intended delivery of features, and limit the IPM to a reasonable amount of upcoming work. It's taxing to keep the mental inventory of features in your head; sticking with the short-term future focuses everyone on the team around tangible new features.

Keep it short and sweet

Once you hit an hour of IPM, people zone out, and business owners get antsy about the emails they're missing (or worse, they whip out their phones). When you have a large team, it's especially important to play time cop. If you don't have a healthy backlog, and you find yourself with a lack of new work, end the meeting. It's far better to hold an emergency IPM two days later than to suffer the pain of making up stories in real-time!

If necessary, use a pre-IPM if you need to vet certain stories and get more clarity before bringing them to the whole team. Typically, review these stories with a team member from each discipline.