Agile teams pride themselves on being able to adapt quickly and change plans as needed.
This might make you think that Agile planning is an oxymoron. When really, it’s more all-encompassing than traditional project management approaches because it happens throughout a project instead of just at the beginning.
Let’s take a closer look at what this means.
Agile planning is a collaborative, iterative process that helps teams align on objectives and keep making consistent progress. Unlike traditional project management methods such as Waterfall, Agile planning happens at every phase instead of only before any work can begin. In this way, Agile teams can get started sooner, adapt to changes faster, and make sure the objective and strategy still hold true as progress is made.
Another difference between Agile and traditional project planning is that you don’t spend all of your time planning upfront for longer time frames. With Agile, for example, you wouldn’t take the first two months to plan out the rest of the year.
The idea is that Agile planning leads to better outcomes and fewer roadblocks that derail projects.
The Agile planning process, visualized as the Agile planning onion, outlines the key phases of any project.
At every layer, being critical, providing feedback, and keeping the user at the center of your project is crucial for success.
Most people think about Agile planning as Release, Iteration, and Daily Planning. But there’s a lot more to it, which we’ll get into in the next section.
Agile planning balances a flexible approach with well-defined milestones and releases.
Develop and adjust your plan as needed, but also make sure your team knows what the priorities are and how they roll up to the main objective.
Start with a user story. Most commonly used in software and product development, a user story is the who, what, and why of your project. Describe your user, what they need, and why it will help them.
In the simplest terms, you’ll write something like this:
As a [describe your user], I want to [describe product or software] so that I can [benefit statement, or the why of your project].
With a solid user story, the next steps become a lot easier.
By the end of this phase, you’ll have:
Here, you’ll outline the specific requirements for completing the project. You’ll take each product from your portfolio, and create your product roadmap.
This is the high-level strategic overview of your product. Your roadmap needs to outline the features that are necessary to meet the project requirements.
Your roadmap might look like a grid, with the following line items for each release:
Even though Agile planning is, of course, agile, you still need some major releases planned so that you know you’re staying on track.
Once you have the strategy locked in, you know the steps to get there, and your project must-haves, you’ll plan releases and have your team agree to them.
This might look like having a minimum viable product (MVP) ready by a certain date, noting all the requirements that it must meet.
This step and the roadmap might be developed in tandem, but you’ll clarify details regarding releases here.
When you’re in this phase, you’ll define releases by scope and requirements more than by strict deadlines. Teams often use quarters to set releases so that it can happen sometime within those three months.
In this step, you’ll create tasks, assign team members, and plan out deliverables for each release.
If you’re using the Scrum framework for your Agile projects, this step will be considered Sprint Planning.
Sprints are typically 1-3 week durations where team members decide on priorities and only focus on those tasks. Sprints consist of current, future, and backlog lists.
Items should not get added or removed from the current Sprint once it’s started. If necessary, the entire team should agree and adjust plans.
If you’re not using Sprints, you’ll still plan out what happens during a certain time period so that your whole team is focusing on the right priorities.
Again, if you’re using Scrum, this will be your daily Stand-up or daily Scrum meeting.
Led by the Scrum Master, you’ll meet for 15 minutes to discuss what’s happening that day, and any roadblocks you have.
If you’re using an Agile PM tool to automate your daily Stand-ups, your team will answer three questions and submit their Stand-up:
The nice thing about Agile PM is that you can do all of your planning using the Google suite such as Docs and Sheets.
However, there are Agile project management tools that make this whole process more streamlined, and get your team involved with the process.
You can comment on tasks and assign team members, add release dates to each task, plan backlog and future sprints, and much more.