If you make a plan with the full realization that it’s going to change, is it really a plan at all? You bet it is.
Agile planning might sound a little backward because agile focuses on iterative development. In fact, I have heard some people say that agile project management can’t be planned, but these people are misguided (and likely just trying to get out of doing any up front work)!
Even though agile is rooted in being open to change and pivoting when we learn new information, the lack of an upfront plan can mean more rework and realignment later.
If you’re ready to change your mindset about planning and focus on delivering value incrementally (while also following a plan), this article is for you.
What is Agile Planning?
Agile planning is the process of defining a vision, roadmap, and paths to achieve your desired result as well as tracking progress throughout the development cycle. It takes the ideas of traditional project management planning and adds the concept of continuous improvement to create a planning methodology focused on helping teams deliver value to customers.
In other words, agile planning is a flexible approach to project planning where we emphasize adaptability and collaboration in an effort to deliver value continuously and incrementally while refining and improving project plans and outcomes.
Understanding how agile project planning can be possible begins with understanding agile’s core principles and values, namely the focus on iterative approaches and incremental development, tight feedback loops, and self-organizing teams.
What are the Benefits of Agile Planning?
Planning ensures that agile teams move together in alignment toward producing high-quality products that actually meet users' needs. It puts us on the path to building something that is valuable, where the adaptive characteristics of agile allow for flexibility in a changing environment.
Agile planning offers the following four benefits to agile teams.
You can adapt quickly
When you think agile, you should think iterative and incremental. These values are core to agile and are found within each agile methodology or agile framework (yes, there are many methodologies that are part of agile, as it’s not actually a methodology itself).
Throughout the agile planning process, if something changes or you learn new information that impacts your plan, you can adapt! This is one of the key differences between agile and waterfall planning (and between agile and waterfall more broadly) and is one of the characteristics that makes agile so reasonable and related to reality.
Say you want to paint your bedroom. If you paint one wall and it turns out terrible, do you keep going or do you try something else? Agile planning would say, “Wait, this sucks, let’s do something else and see if we can get a different result.”
Agile planning recognizes that requirements and priorities can change over time. When things change, instead of carrying on pretending everything is fine, we get to pause and change the plan to meet the new requirements or priorities.
Agile planning embraces the unfolding nature of projects and allows for adjustments along the way. This iterative and incremental approach lets development teams deliver value to customers sooner (one great-looking wall in your bedroom looks great, yay!) and enables teams to listen to customers and change their plans based on evolving needs.
You get frequent feedback
Agile planning requires tight feedback loops with customers and stakeholders. Frequent feedback enables quick course corrections and helps the project stay on-track with the evolving, needs-based plan.
I like to say, “I can’t fix what I don’t know about.” This rings true here. Frequent feedback is required to enable project plans to shift to meet the evolving requirements of customers and stakeholders. We can’t fix what we don’t know about, so we need to get feedback frequently!
Frequent feedback also allows you to solve problems before they get bigger, badder and harder to fix. By getting feedback early and often, agile planning enables teams to identify and address issues before they escalate, leading to better outcomes and higher customer satisfaction.
Let’s go back to that bedroom painting project. You painted a wall, and the paint stuck fine, but your partner decides they don’t like the color after all. Good thing you got feedback about how the color looks on the wall before you painted the other walls!
It sidesteps silos
Agile planning relies on close collaboration between team members on cross-functional teams. The agile principles, as outlined in the Agile Manifesto, emphasize the value in teams working closely together and being made up of people with different specialties, coming together to create one fully capable team to solve problems.
Agile planning values active collaboration and hearing from everyone on the team. In the best agile environments, every team member is empowered to speak on any subject and they work together regardless of tenure, title, education, etc. Everyone’s voice matters and the team works together to define and develop the best possible outcomes in delivering value for the customer.
This agile approach might seem like common-sense also, but in many cases, project teams are siloed. Think about a team of software engineers that doesn’t work alongside UX designers and QA testers.
They think, “Oh, that’s for the QA team to fix” or “UX designed it this way, so I guess we are building it this way, even though this isn’t going to work.” Cross-functional teams work closely together to provide feedback to each other, reduce silos, stop throwing things over the fence at each other, and ensure better product development.
It keeps the focus on the customer
The real goal of agile planning and development is to deliver value to customers. If this is achieved, then the team will likely be considered successful.
If the team is successful in delivering value to customers and the team says they would attempt a similar project in the future, that is a great sign that the planning was enough to be helpful but not too overbearing that the team wouldn’t want to attempt the work again. Remember, one true goal: delivering value to customers.
The 5 Levels Of Agile Planning
Planning agile projects or agile software development involves five distinct levels of planning, starting with the widest, most abstract level (vision) and working down to planning individual releases and iterations. Each level paves the way for the next one.
1. Overall Vision
The best place to begin agile planning is the vision for your product or project. You’ll define what the desired future might look like (we say might because it could change), and this is where you begin paving the way to the goal. Vision planning may happen annually, plus or minus 6-months, typically.
The vision keeps people aligned and focused on a common goal while also providing a way to gut-check various options or decisions that might come up along the way.
The vision is typically created by a product manager, key stakeholder, or project sponsor, and is a clear and compelling statement of what they want to achieve with the project or product. Elements of a vision may include purpose, objectives, and desired outcomes.
In creating a vision, you should answer questions like:
- What is the problem we are solving?
- Who are we solving this problem for?
- What are the goals we want to achieve?
- How will we know if we have achieved the goals?
The best visions are easy to understand by everyone. Avoid using technical jargon, company-specific terms, or value statements. Instead, be clear and forward-looking. Try to inspire and align people towards the desired goals. An effective vision should evoke a sense of excitement, urgency, and motivation.
If you can build a well-defined vision, your team will have the best opportunity to stay focused on the most important elements of customer value. Because you have a vision, each time something pops up that requires a decision, you can check the options and potential decisions against the vision.
Without a clear vision, it can be easy to get sidetracked and lose sight not only of goals, but the reason the team is working together in the first place.
2. Roadmap Planning
Roadmap planning begins by breaking down your vision into key themes or high-level initiatives, depending on the scope of the vision. These themes might represent areas of capability or key objectives that the project or product needs to fulfill.
Once the high-level themes or initiatives are defined, the next step is to prioritize them based on value or other considerations. Then, you can start creating a product roadmap or timeline to visually represent the opportunities for implementation of these high-level items. You might think, “How can you possibly put these items on a timeline without estimating how long they will take to build?”
That’s a great question, but this is an imperfect science—it’s actually more of an art. What I typically do is talk with leaders of delivery teams to get a ballpark idea of how long each item will take end-to-end, and I represent it at that level, leaving a bit of extra time in the roadmap because things change and sometimes we just need extra time.
Socialize the roadmap as you build it to gather feedback from key stakeholders and delivery team members. This will get everyone informed about what you think is most important and is coming up next.
It also helps people give you feedback to be sure you haven’t missed something. This collaboration helps to build a shared sense of ownership and accountability for the results, which generally leads to better outcomes and stronger delivery of value.
Remember that your roadmap is meant to evolve and change over time. Things change, new priorities emerge, and customer requirements shift, as will your roadmap.
The roadmap needs to reflect best-case reality, meaning that if something is completely unrealistic, the roadmap needs to reflect something that actually can be true in the future.
3. Release Planning
Release planning is where the rubber hits the roadmap. This is where the team gets into the details for various roadmap items and begins to set estimates.
A “release” is a “shipped” section of value or software. You could consider these milestones. In release planning, the goal is to create a plan that outlines the elements of each roadmap item that can be included in each release.
If your group is using the Scrum methodology, this is where you might see epics and some high-level user stories form. As the release is planned, features and functionality are defined in alignment with the product vision.
Once the features in the next release or the next few releases begin to be known, you can start to estimate the time and effort required to complete them.
When you have estimates that are calibrated to your team’s delivery, you can start to work back to the plan and get an idea of when pieces of functionality will be delivered. Be sure to continue getting feedback from your stakeholders throughout! In some cases, the customer might have a different idea of what is most important or what should come first.
A common output of release planning is an ordered backlog of epics, typically defined by a product owner. An epic represents a material piece of functionality and the priority of the epics indicates what is most important and should be delivered first.
From the prioritized product backlog, the team knows what is most important to work on and deliver first. Priorities may change, and things that seemed simple may become more complex, so be adaptable and be open to the plan changing. Remember, your job is to deliver value to the customer, even if it's not as you had originally envisioned it.
4. Iteration Planning
In iteration planning, the team takes the vision, roadmap, and release planning into consideration to plan the next iteration or increment of work (typically two to four weeks in duration).
This is where the delivery team can dig in deeper with the product owner or project manager to plan individual iterations (many varieties of agile project management use iterations, so that’s what we’re using here).
In iteration planning (also known as sprint planning in Scrum), the cross-functional Scrum team will work together with the product owner or Scrum master to define the specific tasks or deliverables that are needed to achieve the previously defined release goals.
This includes determining which items will be addressed, estimating how much time it will take to build each item, and determining a priority order for execution.
The output of the iteration planning meeting is an iteration backlog, which details the specific items that will be completed during the iteration. The iteration backlog guides the team and helps them stay focused and on-task.
5. Daily Planning (Standup)
Once you’ve done vision, roadmap, release, and iteration planning, you get to take it day-by-day.
A common practice in several agile project management methodologies is the daily standup. This meeting is typically about 15 minutes in length and is used by the team to share progress and bring forth challenges or blockers they are facing as they look ahead into their work for the day.
Often, small questions pop up here, and holding this meeting daily ensures a quick feedback loop so the team can keep moving forward with the answers to these questions.
The daily standup helps to promote transparency within the team. Everyone knows what everyone else is working on, which fosters collaboration. If someone is stuck, there is someone on the team to help them quickly.
The daily standup also ensures the team is working on the highest-priority tasks and is aligned and focused on the project goals. Sometimes events, incidents, or operational issues can interfere with staying the course toward the iteration and release goal, and the daily standup helps keep these side-quest activities in-check.
By facilitating effective daily standup and planning sessions, you can help the team stay aligned and moving forward towards delivering value and achieving the big goals.
Are You Ready to Begin Agile Planning?
Learn more about project planning in agile, waterfall, and other methodologies by checking out our course offerings in the DPM School.