For development projects that use iterations, I’ve come to prefer a lightweight approach for organizing them around themes. This allows the team to focus on a core intent and an ability to align with product management goals. It’s evolved out of my want to coalesce varying requests while still allowing just-in-time decisions. And I’ve found the approach promotes stakeholder appreciation for how an iteration fits into a broader plan.
This post shows how a theme-based approach can be applied to a single iteration. While this method also helps with tying into a longer program of iterations, that discussion is beyond this post’s scope.
Planning
I’ll explain themes more in a moment, but let’s start with a concrete example. Here’s the kind of artifact we want produced from an iteration planning conversation:
Iteration: May 8 - 22, 2025
Theme: “Add clickable map for weather forecasts”
Members: Margaret, Miguel, Beth, Aren, Alec
Targets:
- US Map display added with each state clickable
- Detail pane update with clicked state’s weather forecast
- Hovering over a state reveals its name and the day’s weather icon
Risks:
- Still having trouble with latency from weather forecast service
- Design for detail pane not yet finalized
- Beth is out second week of iteration
It doesn’t matter where we write this – a shared document, a slide, a wiki page – as long it’s quick to use and handy to reference.
Planning elements
Let’s break this down. There are four key elements that we want:
- a theme
- one to four targets
- one to three risks
- basic information (dates and team members)
The theme is the core organizing element that states the purpose and intent of the iteration. Try to have it land at 5 to 10 words. Whatever the details are, it is what is meant to be accomplished. It’s an agreed upon “elevator pitch”: anyone interested in what the team is doing should be able to appreciate the goal. This example answers “what are you working on?” with “we are adding a clickable map for weather forecasts”. If they’re familiar with the product the team works on, this iteration’s fit is clear.
The targets are the main ways everyone can recognize how the theme is satisfied. Tickets or issues on a project board can have the details – this here though is more of a quick and high level description to make success obvious. Phrase each of these in a way that one can imagine demonstrating it later. Avoid referring to interior details not meaningful to people outside the team: these are about the what, not the how. Be sure not to list activities, it’s outcomes that are important.
Think of these two elements, theme and targets, as the crux of the iteration’s mission.
The risks outline any key concerns that could prevent the targets from being met. These can be anything: uncertainty, team member absence, dependencies, technical concerns - anything that worries the team.
I constrain the length of every section because that pressure helps lift out the most crucial elements. There may be many small risks, but it’s the biggest ones that are most likely to prevent success, so choose only up to 4 or 5 of them. More than that and it’s just noise to others and I can miss what’s important to be on top of.
Similarly, on first draft, I might start with a 20-word theme, but then force it down. That helps pin down what we really mean. And it’s better to decide the 5 to 10 words for yourself that describe your work than leaving it up to others to infer. While you want to waste time “wordsmithing” too much, you do want something that’s direct and clear.
Closure
At the end of the iteration, we want to reconcile how we did.
There are four purposes generally in any kind of iteration review or closure event:
- compare to targets for accountability
- invite questions and comments for feedback
- celebrate wins for recognition
- inventory challenges encountered for learning
Here is an example artifact to create for the closure event:
Iteration: May 8 - 22, 2025
Theme: “Add clickable map for weather forecasts”
Wins:
- Clickable US map display deployed
- Detail pane updates with initial weather forecast display
Gaps:
- Hover not yet working well enough to include
Headwinds:
- Layout for detail pane was more involved than expected
- Addressing surprise support issues distracted from iteration
Tailwinds:
- Map SVG was easier to implement than expected
Acknowledgements: Thank you to Danielle for her help with accessibility concerns for map display!
Again, this can be done in any medium as long as it’s quick to access and easy to share.
Closure elements
After repeating the iteration’s basic information, there are five elements to include:
- wins (try to keep at 4 or less)
- gaps (4 or less)
- headwinds (3 or less)
- tailwinds (3 or less)
- acknowledgements (optional)
Wins are those main things accomplished in the iteration. Like targets from planning, they should be high level and readily demonstrable.
On some teams, we’ve defined a “win line” for our team, a standard we’ve agreed on for how we’d consider something a win. For instance, we always want to show that it runs in a deployed environment (e.g., staging) instead of the developer’s local machine for it to count as a win. This helped us avoid debt into the next iteration where we still had more to do before it could be released. It is okay though for a win to be for a portion of a target: it’s still progress as long as that portion crossed the win line.
Gaps are those items or portions targeted but not met. There may be something entirely not started or a key detail of a target that meant it wasn’t complete. Anything added later after planning isn’t a gap against the targets, so don’t include it here (but if it crossed the win line, it might be an unexpected win).
Headwinds are anything significant that slowed or impeded the progress of the iteration. Like risks from planning, they can be anything. They are not intended to be every little thing, just the most impactful ones that imperiled the targets. You may find that several smaller ones combine to a more impactful categorical challenge.
Tailwinds are the opposite of headwinds: anything that helped the iteration go better or faster than anticipated. Often, an iteration may not have any, but call them out just like headwinds.
Acknowledgements are hat tips to others outside the team that helped. These are most appropriate if they went outside their normal role to help the team be successful.
Again, I constrain these sections’ lengths to drive clarity around meaningful impacts. The counts above are guidelines, but straying too far beyond will muddy conclusions. It’s the effort of editing that helps distill details down to find what matters most.
Conducting a closure event is rather outside the scope of this post, but a couple of details help keep it real:
- if claiming as a win, it must be shown (demos help ensure it’s actually done)
- keeping the entire event to 30 minutes helps force anything covered to be the most impactful, high-level key items and useful to stakeholders attending.
Connecting
I treat the planning and closure artifacts as bookends of an iteration. These help ensure a cohesive core focus that informs the purpose of any included ticket or issue. If someone proposes a ticket for an iteration, it’s easier to see if it supports or distracts from the effort.
Tickets are still important to cover relevant details, but now they are in service to the chosen theme and targets. This way the team can better align their work to a central intention. It helps inform the relative value of those details to that intention (priority). And it helps those outside the team to see how they tie to any product management goals.
The closure event also helps lift out learnings and any remaining work that might need to be accommodated in later iterations. After all, it’s not agile if we’re not adapting to new information.
Challenges
Outside the team’s control, unexpected tickets might come up that have little or nothing to do with the theme (for instance, a critical bug). If they’re minor, that’s okay, but if they’re more than that, they can move the team off of its purpose. Those are injections and end up being headwinds. The new work might supply some unexpected wins, but are also likely to produce gaps. If injections often derail plans, maybe iterations aren’t useful and a kanban approach would be better. At that point, themes might be useful for prioritization, but more as a suggestion than a target.
Another issue is when tickets are initially scheduled that have little to do with one another. Sometimes the theme is simply to “Address necessary maintenance”. Or it might imply the team should subdivide into smaller pods of 2 or 3 people (never 1!), with each pod running parallel iterations with their own themes. Rearranging tickets to find more cohesion might also help discover compelling themes not previously realized.
Next iteration
This was a quick overview of what a single theme-based iteration might look like. Not all teams prefer this style, but it is a way to see the forest amid the trees and align to purposes others can appreciate. If your iterations could use more focus and intention, we can help!
