Running an IPM

I’m going to take a break from my blog posts on metrics, and was thinking I’d focus more on process. An Iteration Planning Meeting (IPM) is core to an agile process and provides the opportunity for the product owner(s) to communicate the vision for the upcoming Iteration.

I’ve sat in on enough IPMs to realize that they’re all unique snowflakes, but here’s what the agenda for an ideal IPM looks like to me.

PM as Facilitator

The Product Owner/Manager should run an IPM. It’s his/her job to ensure that everyone involved with the product development process knows where we just came from and where we’re going. To that end, I like to start by “walking the wall” to look through any stories still in progress from the last sprint, along with any pertinent information about features just finished. This should be a quick process to jog everyone’s memories and ground them in the work that’s coming up.

Invest in Stories

Starting at the top of the backlog, step through each story; the INVEST mnemonic is useful in confirming that they’re shovel ready. Talk through the user-facing value for a feature, ensure that any comps, wires, assets, flows, data, etc. are attached to the story. Confirm that the requester marked is the person accepting the story and 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. The worst thing you can do in an IPM is not respect everyone’s time during this kind of housekeeping.

Paying 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, PMs 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. [Giving canned examples of identifying technical debt is hard — please forgive this one!]

Two Iterations Max

Tracker will chunk stories into iterations based on Velocity. You should only step through stories until you’ve got two sprints worth of estimated work. I like to keep the visibility to two weeks to cover for quicker than intended delivery of features, and to 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.

Block and Promote

If a story is blocked, mark it as such and add a comment with what will unblock it. If a story won’t reasonably become unblocked during the sprint, I’ll move it to the Icebox to be sure the Backlog only reflects actionable work. Similarly, this is a good time to call for nominations for bugs/chores/features that should be prioritized out of the Icebox.

Short and Sweet

Once you hit an hour of IPM, developers zone out and business owners get antsy about the emails they’re missing (or worse, they whip out their phones). You can and should be able to limit sidebar discussions to stay focused on one story at a time. When you have a large team, it’s especially important to play time cop. If you don’t have a healthy Backlog and 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!

These are not hard and fast rules, but chances are if you sit in one of my IPMs I’ll focus on these pieces. What’d I miss? What parts of an IPM are essential to a successful sprint?

Logistics

Kill the Icebox and bump up the font size.

Use the Tracker Header bookmarklet to get some more real estate

Check team strength and set accordingly in Pivotal Tracker

Use screen sharing (i.e., join.me) for any remote participants

Turn off all screens unless they’re in support of the IPM (note taking, clarifying comments in Tracker)

A Javascript Bookmarklet to toggle the Tracker header on and off, giving you more room to view stories. To use it, copy “javascript:[“header”,”controlPanel”].each(Element.toggle);app.layout._resizePanels();”, paste into a new bookmarklet, go to your Tracker project, and toggle the bookmarklet to hide the header.

4 Comments

For every backlog I’m in, I always turn on the Tracker option to combine the current stories and the backlog. That way, everything for the IPM is in one column and it makes it easier to see continuity.

If the iteration is in the middle of a longer roadmap (1-6 months), I’ll also kick off the IPM reviewing where in the larger picture the iteration fits. That way, the stories under review in the IPM make sense in the larger context and reminds the devs about the end goal. That increases the likelihood they’ll be able to find flaws in the stories, prioritization, and make better implementation decisions around refactoring.

April 5, 2013 at 9:01 am

Emad says:

Great article.

Regarding your comment on wrapping technical debt into a feature, do you ever see that conflict with the best practice of keeping stories small and atomic? Is refactoring code, for example, explicitly specified in a story for a new feature or is the expectation that if the code suffering from tech debt is revisited due to a new feature, it will be cleaned up without prompting?

January 2, 2014 at 12:57 pm

Graham Siener says:

Hey Emad, good question. Normal refactoring should ideally occur as part of every story (unprompted), but there are certainly situations where business needs have changed or [as a team] we collectively have a better sense of where the product is going. It’s difficult to justify creating stories to tackle this type of technical debt, but by reducing velocity you can still reduce debt by letting user value drive the refactor [1].