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)
[1] Tracker Header Toggle Bookmarklet
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.
