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.
What happens during an IPM?
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.
How do you know if an IPM is effective?
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.
- Context. Each team member gets to bring their own experience to the table. Designers can share user research and how it relates to stories and designs. Product managers share product visions and business objectives. Developers get to share how the new stories fit into current tracks of work and technologies that are being used.
- Visibility. After the meeting, everyone is aware of the various tracks of work and what the team will be working on in the future.
- Clarity. IPMs provide a shared understanding of why every task is in the backlog, and the risks and mitigations that will be taken to make sure that it gets done. Large stories are broken down, and descriptions and acceptance criteria are refactored.
- Focus. Well-run IPMs unify the team around a vision and help ensure that the team is working toward the same goal(s).
- Opportunity for iteration. By collectively assessing the backlog, the team can use any of the above benefits to reshape or improve the backlog and make sure that the best next thing will be completed next.
What are the goals of an 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.