The Complete Beginners Guide to Agile Project Planning
An Agile project plan is a must in today’s volatile knowledge work environment. Learn more about the Agile planning process in the following paragraphs.
We Will Teach You Kanban in 7 Days. Learn the Basics. For Free.
The only email crash course you need to get started with Kanban. You will learn how to reduce bottlenecks, visualize workflows, and get more done with the help of the Kanban method.
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 for 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 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.
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.
Agile Project Planning VS 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.
Characteristics of Agile Project Planning
First, let's focus on the different levels at which you can plan. The "Agile Planning Onion" best describes these levels:
It is fundamentally essential to grasp the idea that Agile Planning is applicable at 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 in general.
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.
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)
Lack of detail whenever it can be avoided (commit as late as possible)
Frequent deliveries (small batch size)
Date ranges instead of single date estimates (probabilistic vs. deterministic)
Focus on the work and not the worker (no particular assignees, the team is responsible)
No separate phases for Quality Assurance (quality is built-in)
Two-tiered plans (Timelines for initiatives, tasks have no start/end dates)
Data-driven (Based on historical data and Monte Carlo simulations)
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 & fast feedback loops (small batch size)
An Agile plan should accommodate for 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 give feedback early in the cycle and prevent wasting precious time and resources.
Date ranges instead of single date estimates (probabilistic vs. deterministic)
When customers ask about the project duration, they usually expect a fixed date. But you would be surprised how many customers would actually approve if you provide 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 (the 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 to do 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 the team to self-organize 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 tasks)
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 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 your 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 about the project status, and it's based entirely on statistics, which can save you the trouble of estimating all tasks one by one.
Tools for Agile project management like Kanbanize 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. Kanbanize 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 Kanbanize.
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 Kanbanize, 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 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 Kanbanize, we connect the Agile timeline containing the project roadmap and the Kanban board, as seen below.
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 the 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.
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:
