"Failing to plan is planning to fail." This quote by the time management expert Alan Lakein perfectly summarizes the importance of planning in project management. As much as we hate fixed dates and fixed scopes in the Agile world, it is the everyday life of many organizations, and we cannot just ignore its importance.
Even if we go outside the realm of fixed-date, fixed-scope projects and dive into the product development world, planning is still of crucial importance. Most customers won't commit their budget to an open-ended specification and demand a delivery date alongside the quote.
Assuming such a reality, a natural question to ask is, "How do we create an agile project plan?". This is a tough question, and most materials on the topic only cover the software development practice. It creates an impression that Agile is suitable only for the software industry, but nothing could be further from the truth.
We will demonstrate how your organization can start with agile planning in an easy-to-follow step-by-step guide.
What Is Agile Planning?
Agile planning is an iterative approach to managing projects avoiding the traditional concept of detailed project planning with a fixed date and scope. Based on the principles rooted in the Agile Manifesto, Agile project planning emphasizes frequent value delivery, constant end-user feedback, cross-functional collaboration, and continuous improvement.
Unlike traditional project planning, Agile planning remains flexible and adaptable to changes that may emerge at any project lifecycle stage.
Why Is Agile Planning Important?
Agile planning provides teams with a framework for managing projects that allows them to be more flexible and adaptable to changes, customer-focused and continuously improve their processes by learning from their experience.
Through regular feedback loops, teams are engaged in knowledge sharing and synchronizing of project goals and customer wants. This helps them to adjust their plans and prioritize their work based on the new information. In addition, Agile planning promotes frequent delivery of small batches of work and early risk identification and mitigation.
What Are the Steps in the Agile Planning Process?
The process of Agile planning may vary for the different Agile methodologies. However, there are some general steps that are involved in Agile planning:
-
Define project goals: project planning starts with clearly defining what the purpose of this project is. This will create direction for the team to follow and ensure that all efforts are aligned with the primary goals.
-
Load backlog with work items: identify what needs to be done to complete a project. Agile teams use work elements like initiatives, epics/ projects and tasks/ user stories to build their work structure and create an alignment between the project goals and execution.
-
Release planning: review the backlog and determine the order of work execution. In Scrum, teams conduct Sprint planning, choosing the next highest priority items to execute in the sprint. Kanban teams use historical data to estimate project length and use Kanban boards as a planning tool to prioritize upcoming work.
-
Daily stand-up: holding a daily meeting will ensure everyone on the team is in the loop. This meeting aims to identify and resolve issues, find new opportunities for improvement and discuss project progress.
-
Process review: examine the end-to-end flow of work from initiation to customer delivery. Gather feedback to identify areas for future improvements. Scrum teams do that during Sprint Review and Retrospective meetings, while Kanban teams have Service Delivery Review meetings.
How Agile Project Planning Differs from the Traditional Project Planning?
In the past, business leaders spent enormous amounts of time laying out detailed plans of execution for years in the future.
For a long time, this way of planning worked perfectly. However, as markets became more dynamic in the last decades of the 20th century, business requirements began to change more frequently, and a new, more flexible way of planning was necessary.
Тhis need became obvious and somewhat critical with the rise of knowledge work. While just 50 years ago people worked primarily in factories, these days the work gets done in offices, where people use their heads more than their hands. It is precise knowledge work where an Agile project plan is most needed.
The main difference between Agile planning and the traditional way (also known as Waterfall) is that the first one is iterative and adaptive to changes. In contrast, the second one is a step-by-step heavy planning process.
We have to mention that both approaches have their virtues. When you're building a bridge or a building, you want to have a very detailed and well-thought-of plan. Here, welcoming requirements late in the process with an Agile project plan is not the most suitable approach. Of course, it can happen, but changes might be costly to implement.
However, in knowledge work, change is welcome at any stage of the process, even at the very end. The goal is to create a solution that satisfies customers, and everything is allowed. Simply said, in Agile project management, you lay down detailed plans only for shorter time frames, and you can easily make changes when needed.
Agile Planning Is NOT Scrum Planning
Often you will read that Agile planning is the same as Scrum planning. However, this is far from the truth. Scrum is a prescriptive framework for software development that proposes one concrete way to plan. It is prevalent in the software world, but it is often the subject of severe criticism.
We won't go into the details of why Scrum planning is flawed, as we would rather talk about Agile thinking applied across various industries and not just software. It is more important to know how to apply generic techniques and practices on the global company level, regardless of the business type. For the time being, it is only essential to know that Agile Planning does not necessarily involve the Scrum framework at all.
The 6 Levels of Agile Planning
The "Agile Planning Onion" best describes the different levels at which you can plan your Agile project lifecycle.
Let's have a look at each level from a product development perspective:
-
Strategy: The outermost layer of the onion represents the overall strategic vision and goals of an organization and how they are going to be achieved. It is usually conducted by the senior leadership team.
-
Portfolio: At this level, senior managers discuss and plan out the portfolio of products and services that will support the execution of the strategy defined in the previous level.
-
Product: Teams create a high-level plan and break it down into significant deliverables of key features and functionalities that will contribute to accomplishing the strategic objectives.
-
Release: The key features defined are set to be delivered within a time-framed box (usually a month).
-
Iteration: This level focuses on managing work in a timeframe of a few weeks. Teams select several individual tasks or user stories from the backlog to deliver in small batches.
-
Daily: The goal of the daily planning meetings is for teams to walk through their tasks and discuss project progress and any impediments threatening the process. During this time, they create an action plan for the next steps of the project execution.
It is fundamentally essential to grasp the idea that Agile planning applies to every slice of the onion. You don't just do Agile on the team level (Day, Iteration, Release). You can have an Agile product management service, Agile portfolio management, and Agile strategy. Being agile in your strategy is what defines business agility.
As we already stated but didn't explain, Agile planning is iterative. This means that you develop and adjust your plan multiple times as you find necessary. The goal is to invest time in planning at the best possible moment and adapt to changes easily if they occur during the execution phase.
What Are the Main Characteristics of Agile Planning?
Irrespective of the level at which you operate, your Agile project plan will have similar characteristics. Let's explore them in no particular order.
The Goal from the Eyes of a Customer (Value)
An Agile plan must consider what exactly the customer wants. If we need to borrow a term from the Lean dictionary, we will use the word Value. In other words, our plan must be clear on how and when we are going to deliver value to the customer.
In this regard, the more the plan is focused on outcomes, the better. If you are used to putting activities inside the plan, think again. Is it crucial to know what people do or what value they have produced?
Lack of Detail Whenever It Can Be Avoided (Commit as late as possible)
Imagine you're preparing for an expedition to a high mountain that hasn't been explored before. You will have a rough estimate of the duration of the expedition to prepare enough food and water. However, you won't know if there's a place suitable for camping and where that place might be at all.
Many projects in the knowledge work realm are quite similar to the described expedition. You know a lot about the project in advance but not enough to commit to every single piece of it. Yet, many managers insist on having a strict, detailed plan for every single project deliverable. Interestingly, we are offloading the commitment to the last responsible moment in real life, but we fail to do so in our project plan.
Frequent Deliveries and Fast Feedback Loops (Small Batch Size)
An Agile plan should accommodate frequent deliveries and make the collection of feedback explicit. Indeed, the feedback taken should be reflected in the next version of the plan, which would improve the likelihood of successful project closure.
Projects are big batches of work, by definition. However, there is no obligation to deliver them all at once. Most customers would want to have an early preview of the results to ensure that the project does not deviate too much from what they expect.
Suppose the project team misunderstood the requirements and set off to work on something completely different from what you envisioned as a customer. Would you rather give them feedback early on or wait until the project deadline? It is more than natural to have frequent feedback loops early in the cycle and prevent wasting precious time and resources.
Date Ranges instead of Single Date Estimates (Probabilistic vs. Deterministic)
Customers usually expect a fixed date when they ask about the project duration. But you would be surprised how many customers would actually approve if you provided a date range instead of a single date.
As they say, it's better to be roughly right than to be precisely wrong. And this is what we would encourage everyone to do – use date ranges based on historical data and forecasting methods to create an Agile project timeline for your plan.
Focus on the Work and Not the Worker (Team Is the Owner)
This comes from the same perspective as the late commitment example. If you assign people to the jobs too early, you're risking doing the wrong thing at the wrong time. From the perspective that we care about the flow of work and not necessarily utilizing every worker at 100%, it’s OK to leave a self-organizing team around the project.
It is most certainly true that you have specialists on the team, which creates many dependencies, especially in larger companies. An Agile coach's natural response would be to eliminate the dependencies, but this is an answer detached from the real world. You can't just remove all dependencies without creating a ton of problems elsewhere in the organization.
The reasonable approach is to manage dependencies coming from the holistic view of your organization and value streams. If the flow of value to the customer is blocked because of team X, then that's where you should be focusing on, even if it means that team Y will have nothing to work on.
This is a bit radical and requires a paradigm shift, but it's a fundamental concept in Lean and Agile project planning. It's needless to say that in such situations, your plan has to reflect the focus on block/issue resolution with less focus on employee utilization.
No Separate Phase for Quality Assurance (Build Quality in)
Toyota became the biggest car manufacturer in less than 50 years, starting from a small family company. One of the principles they used was "Build quality in", which means that no time should be spent fixing the product after it has exited the production line.
It would be best if you strive for the same level of quality during the execution phase of the project and, by any means, try to avoid a final "Quality Assurance" phase. If you have a big final quality assurance phase, you've most likely ignored the quality aspect throughout the project life cycle, and once you get into the quality phase, things start to look ugly.
Of course, it's better to have a final quality check instead of shipping a defective product, but this should be an exception rather than the norm.
Two-tiered Plans (Plan Only the Initiatives and Not the Work Items)
This is one of the essential characteristics of an effective Agile plan. If you have a high-level plan of all major deliverables, it's easy to break these initiatives down into tasks and then pass the tasks to the actual execution teams.
While this might sound trivial, it represents a substantial difference compared to the traditional Gantt chart plans. When you break down an initiative (project deliverable) into its comprising tasks, we recommend that no start and end dates are determined for the tasks unless necessary.
For example, a task representing the creation of posters for a concert would be useless after the concert, so it must have a deadline attached to it. However, more often than not, tasks won't have any real deadline.
When you skip the start/end dates for all individual tasks, you allow your teams to pull new work when they have the capacity and not when you thought they should have the capacity. The word PULL here is used on purpose, as it illustrates the pull system principle that we know so well from Toyota.
The fact that you put start and end dates to the initiative but leave out the dates from its children tasks detaches the planning from the execution. This way, you maintain the Agile project plan in terms of time and commitment, but you allow your teams to make the optimal decision, as they are the ones closest to the work's technical details.
Data-driven Decisions (Use Historical Data to Plan the Future)
If you use the Kanban method to run the day-to-day tasks in your teams, it is easy to employ statistical methods for data-driven forecasting. One such method widely used in the Agile world is the so-called Monte Carlo simulations.
The Monte Carlo simulations take as input historical data (throughput and cycle time). Then, with the help of mathematical algorithms, simulate thousands of possible outcomes for your project. After assessing all the possible outcomes, the Monte Carlo simulation provides information about the project's potential completion dates with some probability attached to the forecast.
For example, a Monte Carlo simulation can forecast an 85% probability that your project will finish by the 2nd of July. Alternatively, the forecast can tell you that there is a 95% probability that you will deliver 200 tasks or more by your deadline. This gives a good indication of the project status, and it's based entirely on statistics, which can save you the trouble of estimating all tasks one by one.
10 Years Kanban Experience In 1 Free Book.
Project Manager's Guide to Kanban
Tools for Agile project management combine this idea with the previous one (two-tiered plans) to create a continuous forecasting system that informs managers of all projects' actual status and their deliverables. Businessmap's software platform extends this type of continuous forecasting to the portfolio level, as it's easy to see a real-time forecast of all projects in the portfolio. All you need to do is run the day-to-day tasks in a set of team Kanban boards and connect them to the parent projects.
Agile Project Plan Example
As we've already discussed Agile planning characteristics, let's look at a practical example of building an Agile plan and how we do it at Businessmap.
Defining Major Project Deliverables or Releases
Let's say we have to plan the creation of a new website. As the scope for that is quite big, the first thing that we would do is define different functional parts (deliverables) that will be continuously released to the market.
Here, we should note that we won't plan the deliverables in detail. An Agile project plan leaves this for the "last responsible moment" and includes it progressively throughout the project. This will save us the otherwise wasted time of unnecessary planning and help us retain agility for any emerging changes.
To build a roadmap for the execution of the deliverables, you can use an Agile project timeline. In Businessmap, for example, we use a Kanban timeline (as seen from below) to accomplish that. You can then input one or more of the deliverables to be executed in parallel or visualize a sequence when some of them are dependent on one another.
Breaking Down Deliverables into Tasks
Once we have the major functional parts of the project visualized in a roadmap-like view, our next step would be to break them down into individual tasks. As we progressively elaborate on our Agile plans, we will start with the most critical deliverables at this point.
To visualize the tasks and their flow to completion, you can use a dedicated Kanban board. In our platform, we connect the Agile timeline containing the project roadmap and the Kanban board.
This gives an unmatched view of the entire project progress from concept to fruition. As a result, we can see which deliverables are currently in progress, their status, and who is working on what at any given moment. This setup also allows us to collaborate with one another when tasks get stuck in the process and resolve issues faster.
Through the concept of "just in time" planning, we can retain agility for any last-minute changes, emerging requirements, or shifting priorities. This allows us better to satisfy customer needs with the delivery of our projects.
Agile Planning Frequently Asked Questions (FAQs):
What Are the 6 Levels of Agile Planning?
Embracing business agility in a company means that Agile planning applies to every team and organizational level. According to the popular “Agile Planning Onion” model, the 6 levels of Agile planning are daily, iteration, release, product, portfolio, and strategy.
How Do You Estimate Work in Agile Planning?
Using techniques such as T-shirt sizing or story points, agile teams estimate the complexity and effort needed to complete a user story or task.
Can Agile Planning Be Combined with Other Project Management Methodologies?
Yes. Combining Agile planning with Scrum, Kanban, and other Agile methods can tailor the planning process to fit the needs of the project.
We offer the most flexible software platform
for outcome-driven enterprise agility.
In Summary
Agile planning is a new, flexible way of organizing future projects and adjusting to changing requirements without generating waste. These are the most important characteristics of a good Agile plan:
- A goal from the eyes of a customer
- Lack of detail whenever it can be avoided
- Frequent deliveries
- Date ranges instead of single date estimates
- Focus on the work and not the worker
- No separate phases for Quality Assurance
- Two-tiered plans
- Data-driven
