Planning is one of the skills that separates great product teams from the good ones. Teams that plan well are more likely to release in small and steady increments, build high-quality products, keep their customers happy, and reach their business goals. Even though planning might feel like a waste of time, it pays off to figure out what you’re building and why, before you start building it.
In this blog post, I'll make the case for planning as a team, cover the process we use at Swarmia, and walk you through details that involve planning and preparation.
Make planning everyone's business — the benefits of planning as a team
In software, we're usually working with a lot of uncertainty and unknowns. Product teams need to understand if what they're building is valuable or if they should be spending their time solving another problem. That’s why you’ll want to minimize the time to get your product increment out.
Planning as a team is crucial for developing shared context on the problem and minimizing the scope of the next product increment. When the team understands what success looks like, they're more likely to come up with a high-quality solution for the problem. Not only that, it becomes easier to plan the work for collaboration. With both the proper context and well-structured tasks, it's easier for multiple engineers to work together on a story. Finally, collaboration reduces the time it takes to complete the work. The improved flow of work makes the team more likely to succeed in the long run.
There are plenty of other long-term benefits of collaboration. Teams that collaborate tend to be happier; it's exciting to see work move faster. This also helps the team stay closer to the customer, and the increased user empathy gives meaning to the work. Solving problems is easier when collaborating, even in concrete terms like rubber ducking and getting reviews quickly. Collaboration is also a form of long-term team maintenance as sharing context helps combat siloing.
What does it mean to plan as a team? Simply put, it's about minimizing the handovers in the process and optimizing for shared context and collaboration. It's the team that builds the solution and they should be planning it as well. This is the strategy that'll yield the best results under high uncertainty.
Setting the scene — how we work
Before I explain our process, let's set some context for how we operate.
At the time of writing, our team consists of nine developers, a product designer, and a product manager — six of us having joined less than six months ago. This makes us a pretty large team already. We pay extra attention to ensure everyone one of us understands both the problem and our solution — we believe this will pay off later.
Our process of choice is Kanban because it's fairly flexible, very lean, and light on process. We take in the highest priority item when work is completed, based on our priorities as a company.
Sometimes this means swarming down on tasks and bugs before starting on new feature work. We find this helpful to keep our priorities clear (i.e., only have high-priority work visible on the board) and to avoid the anti-pattern of falling back to completing easy, low-priority tasks.
We deal with four types of work: epics, stories, tasks, and bugs.
- Epics are bigger problems that will take a month or two for us to solve — one recent example is our work on investment insights where we had to build a new type of reporting view, tweak our core data model to add the concept of investment categories, and add in customization of said categories.
- Stories are more incremental problems that we aim to solve within two weeks — for us, introducing a new working agreement falls into this category.
- Tasks refer to both subunits of stories and individual small adjustments we might want to make to the product — a recent example is adding the ability to exclude individual PRs from metrics. Optimally, a task takes one day of development time to complete.
- Bugs are tracked as a separate category of work as they usually call for a different type of prioritization than tasks. But otherwise, bugs and tasks are very similar in the amount of work they should take to complete.
In this post, we focus on planning stories as those are the most common type of increment to plan. The same approach can be used for planning a bigger batch of work, i.e., an epic or your batch-size equivalent. Just make sure you reserve at least an hour for properly going through the context.
Tasks and bugs that can really be solved in a day or two should not require much planning. If they do, you’re probably looking at more work and should discuss if you need a story instead, or if you can start with a smaller increment.
We aim to keep our planning process fairly lightweight. After we know which story should be prioritized next, we:
- Prepare for planning by doing shared product discovery with the trio of product manager, product designer, and software engineer.
- Run a planning meeting with the whole team. It's in this meeting that we share the full problem context, decide how to solve the problem, and break the work down to smaller tasks.
To constantly improve our planning process, we look at the flow of work in our bi-weekly retrospectives. We evaluate whether our work was focused and free of interruptions. We try to understand how we did and if there were factors affecting throughput unrelated to planning. We measure the scope creep of work to determine if the planning was done well and look into the individual tasks for more information if we think there's something we can improve.
Next, let's dive deeper into this process.
Don't rush — prepare for the planning meeting
We make sure to come prepared to our planning meetings. This way, we have three people spend a bit more time on formulating the first idea, instead of the whole team ending up planning as a committee and wasting a lot of time in the process — often with an end result that's worse.
Pre-planning is just another word for doing your homework in product discovery, but with a story-sized focus. At its simplest, the product manager, designer, and (lead) engineer work together to cover all the cross-functional aspects the product team is there for. The trio evaluates the concept regarding the four major risks — value, usability, feasibility, and viability — ironing out whichever wrinkles they identify. When there are no obstacles left, the team proceeds to planning.
The outcome of this preparation is to get clarity on the why and the what: why you’re solving this problem and what the solution could look like. At this point, the outcome doesn’t need to be a thorough plan just yet. Quite the opposite, it's the outcome of shared understanding that matters. As Marty Cagan summarizes in Empowered, it's about the discussion on "How do we solve this problem?".
We've noticed there are tangibles that help, though:
- A concise description of the goal
- A design prototype of the solution
- A summary of the initial scope of the solution
Align the team – running a great planning meeting
Now, we have everything together for an effective planning meeting: a solution with a goal, design, and scope. The only thing that remains is getting the team together and breaking the solution down.
The goal of the planning meeting is that the team knows what they'll be building and why, and what it will take to finish the story (i.e., the tasks in the story). This is where everything comes together, and when run well, it minimizes the back-and-forth later in the process. Because we already tried to identify risks, and because there’s all the functional expertise in the room, we’re well-equipped to tackle any issues that come up in the meeting.
We usually know enough about the context to jump right into the goal of the story and the proposed solution itself. If this isn't the case for your team, it might be good to book a bit more time for the meeting (we usually reserve 30-45 minutes).
At this point, we have three people in the team with a broader understanding of the problem and solution — the product manager, product designer, and software engineer who participated in the product discovery. One of them usually facilitates the planning meeting as they already have the full context.
Agenda-wise, our planning meeting consists of three parts:
- Present the goal and proposed solution
- Discuss risks and address objections
- Break the work down into tasks
As the output of the meeting, we get a story ready for development, already broken down into tasks. The most important outcome, though, is that the whole team understands what's going to be on our Kanban board for the next couple of weeks — and why.
Next, let’s take a closer look at what happens in the meeting.
Present the goal and proposed solution
We start the meeting by going through the problem at hand, and the goal of the story. We usually start with a brief overview and context-setting, before moving into the details of the proposed solution.
There’s nothing better for discussing an abstract, sometimes complex concept than a prototype. We prefer to have a high-fidelity prototype so that we can understand all the details of the solution. However, your team might prefer a detailed mockup instead. The design doesn't have to be a perfect representation of the solution but it's good to agree as a team what's good enough.
We tend to lean forward a bit and leave parts of the design out to keep the initial increment small. However, there's nothing wrong with making the phases explicit, especially if you're working with a complex rollout or a big gradual change. And if that’s the case, just understand that the end goal will change along the way.
If we’re introducing a new API or doing some database changes, we try to prepare a draft or simplified version to help everyone understand the concept and steer the discussion later.
Discuss risks and address objections
Next, it’s time for the clarifying questions and the implementation discussion as what will follow is shaping the story into tasks.
The goal of this part of the meeting is to surface any points that weren’t considered in pre-planning and to reveal which parts may entail more work or uncertainties than expected. At best, this helps direct discussions such as whether a refactoring task should be included in the story.
The whole team is present for this discussion, which improves the odds of finding the smallest possible product increment. Instead of getting into troublesome story-splitting work asynchronously or in daily stand-up meetings, our process tries to solve the problem here and in the next step.
When there are questions about risks or concerns that weren’t covered in the pre-planning, we either take note and start tackling them after the meeting — or, preferably, make a decision to simplify the implementation. Once we’ve agreed as a team that the solution is clear enough, we move on to planning the tasks.
Note that we rely heavily on personal communication and the whole team attending the planning meeting for sharing context. Our story descriptions are only a summary, and it would be hard to start working on a story just based on them. We think this is an acceptable trade-off for keeping the process lightweight.
Break the work down into tasks
We don't use user stories when we break down the story into tasks. Our friends at Linear have written an excellent critique on user stories and it happens to align well with our thinking. Simply put, because we already understand the context, we prefer to maximize the clarity of what actually needs to be done. We've paid attention to formulating the why in the story as a simple goal, but we leave it there.
For us, tasks describe concisely what should be done, e.g., "API for working agreement exceptions" or "Add graph for cycle time". You want to be able to make tasks small and specific, as vague tasks are more likely to result in scope creep, and often decrease the level of collaboration on the story. In other words, "Implement frontend" is probably not a good task.
Don't leave anything out to avoid surprises later. How will you roll things out? What about documentation? Is there any cleaning up that needs to be done? Covering these things in planning will improve your likelihood of remembering to do them later and give you a better idea of when the work will be completed.
Avoid adding anything that isn't absolutely necessary for the solution. When you’re building things with any level of uncertainty, you’ll face surprises, which will result in scope creep. Anything you can do to combat this is a good thing and will bridge the gap between your plans and reality. This includes discussing the sequencing and parallelization of work — identifying and breaking down the bottleneck tasks helps increase collaboration.
At the end, you should have a story ready for development, with subtasks that clearly describe the work to be done. More importantly, you'll have a team of engineers who understand what the story entails, what parts of the product they'll be working with, and what success will look like. Critically, the whole team also understands why they’re doing this work, empowering the individuals to overcome small blockers on their own, and linking the development work to the customer problem.
Start building — and learning
All that remains is executing on the plan you just made. The tasks should now be clear for everyone in the team and descriptive enough for developers to pick up.
If there's something that's sure, though, is that you're never completely done after the planning. Whether you're working with legacy or greenfield products, you're bound to run into new problems while building. When you do, just update your plans. You've already built a part of the solution, and now you have more information. All you have to do is adjust your plans based on what you’ve learned.
Feedback loops are useful for learning, and a way to measure your success with planning is to look at scope creep. This is the amount of work that's added to the story after the initial planning — most easily measured in subtasks. You will almost always have some amount of scope creep, and this is nothing to be concerned about. On the contrary, you might be over-planning or unable to do any adjustments if this figure is always zero.
Pay attention to exceptionally high levels of scope creep. If your team tends to average around 20-30% but a story suddenly creeps by 100-150% (more than double what you had planned), ask yourself what happened? Maybe the problem was more complex than you initially thought, and you could have split the story. A great place for this discussion is when you complete the work (and would need to plan the next increment) or in team retrospectives.
The more you work this way, the better you get at it as both a team and individuals. Because you've worked as a team, you have shared context to help you. Eventually, everyone in the team will become confident enough to make the initial choices without having to consult others. Instead, they’ll just inform each other. That's the magic of working as a team.
