So what exactly is an IPM, and why would I want to show up to one?
An IPM is an iteration planning meeting, and ’cause I said so. Boom. We're done. Thanks for reading.
Ok, ok, since that definition was sufficiently vague, and the “why” is nonsensical, let's dig a bit deeper. By the end of this post we will have gained a shared understanding of what an IPM is, and we will be able to discuss what the goals of an IPM are and how we reinforce them through an IPM’s activities. Let's start with a better definition: an IPM is a meeting for the whole team (seriously, every member of each discipline) to gather and discuss upcoming work and align on what needs to be done next.
So what actually goes on in an IPM? If I were to run one, what would I do? The main activity that takes place is walking through stories, giving context to the team, and making sure that every member understands the complexity and value that each story entails. This is where the cross-disciplinary sharing comes into play. Product managers (PMs) are given the opportunity to explain upcoming stories and how they affect the overall vision of the product and business goals. The designers talk about the value to the user, and how any particular story fits into the user flow. With the understanding of the story’s value, the developers are given the opportunity to discuss the complexity that they foresee with the story’s implementation. This discussion then allows the PM to make informed decisions about its priority, weighing the user value against its relative complexity.
The backlog might even grow during IPMs! Gasp! Sometimes risks or unknowns are surfaced through the discussion, so new stories can be added to mitigate them by creating spikes or chores. Feedback about the live software is discussed and prioritized in the form of bug fixes. In general, the PM should add stories to the backlog prior to the IPM to keep the discussion focused on delivering user value, but that focus shouldn’t exclude things that might arise through the conversation.
So how do you know when you have run an effective IPM? First, the team should leave with a clear projection of what they think they can accomplish in the time until their next IPM, as calculated against known risks and the expectation of some unexpected work. Second, every story in the backlog is sorted in priority order—the result of the user value vs. complexity discussion.
Beyond those measurable outcomes, I can think of five principles or values that stem from an effective IPM.
Now, you may say, “Hey, afb—you didn't mention pointing once!” and I would reply, “Yes.” Not only because it is factually correct, but also because pointing stories is not the purpose of an IPM. Pointed stories, sprint commitments, projected velocity, and a whole host of other things might be side effects of an effective IPM, but they aren't the actual goal. An IPM at its core is a meeting to foster team alignment and understanding of the work to be done.
Focusing an IPM on anything other than the goal of team unification means that as a team works to improve their processes (via retros and other ceremonies), these side effects will be optimized for. Take having pointed stories as the goal, for example: in this paradigm, it might be quicker to have the PM point the stories as they write them—then IPM could just be used to make sure that the point vs. complexity makes sense, and to tweak as necessary. Or perhaps it might be more efficient for only the developer who will pick up that story, or who has the most domain knowledge of that part of the stack, to point it.
Luckily for us, we don’t have those concrete outcomes (aka side effects) as the goal. Earlier I mentioned the prioritization of stories, as well as projections of work over time as “measurable outcomes.” These are important to highlight because they are external outcomes that can be used to demonstrate an IPM’s effectiveness to folks outside the team. But an IPM’s real goal is internal to the team.
We have IPMs because we want to know that we are doing meaningful work, and to help the team make the best decision it can by sharing and fostering team-wide knowledge and understanding.