The Agile Planning Onion: Making Sense of Planning in an Agile World

I recently wrote a post on 13 Myths about Agile Project Management. One of the myths (or misconceptions as I prefer to call them) stated that there is no planning in an Agile project.  Whilst I addressed this misconception briefly in the post, it requires more explanation because, contrary to the stated misconception, there is a lot of planning in an Agile project.  So, (without wishing to make anyone cry!) have you ever heard of the Agile Planning Onion?  If not, then let me introduce you…

 

Project Means Planning

To understand the Agile Planning Onion, it is first necessary to discuss general project planning because all projects need to be planned.  Without planning nothing would ever be organised or achieved.  In the project management world, proper project planning allows the team to have a better understanding of user requirements and allows them to put in place a workable strategy for successful completion of the project.  It’s a little like preparing for an exam. You know you have a deadline to meet (exam date).  You know you have a lot of work to do if you want to pass.  You plan your revision strategy accordingly.  Your goal is to have the project (revision) completed by the time your exam (product) is due and to then pass it (achieve completion and success).

Without initial planning for the exam followed through with revision, passing may not be an achievable goal.  Similarly, if organisations embarked on projects without any planning, whether an Agile or Waterfall project, then the project is unlikely to be successful.   So, whatever project is being worked on, without a plan, it is going to be difficult to make that project a success. 

Traditional Waterfall Planning

Traditional waterfall planning charts the course forward at the beginning of the project.  So, if the product is going to take one year to produce, then plans would normally be drawn up at the start of the year that would try to capture all requirements.  The team will have detailed plans for achieving the end goal right at the start of the project.  It sounds ideal; everyone knowing what and how to do things right from the start…. but there is that little 6-letter word that could throw a spanner in the works at any time… CHANGE!  This is where waterfall methods can occasionally struggle because the methodology does not easily allow for change, whereas the Agile Planning Onion does.

Change

Everything is open to change, so to plan a project at its beginning means unforeseen issues may be difficult if not impossible to deal with once production is underway.  The customer may change their requirements, or the market may change, meaning that parts of the original plan may not be achievable or even relevant. 

Unclear or incorrectly defined responsibilities make for mistakes and to change plans in the later stages of a waterfall project would be difficult, if not impossible.  The waterfall method is sequential and so tries to capture all the requirements for the project before any work begins.  (See Waterfall vs. Agile Methodologies: What are the differences?)   The team may struggle to meet the original criteria due to unforeseen changes.  If this happens then it is unlikely that the product will be delivered successfully, within budget and deadline.  The knock-on effect of this on the team could mean pressure and low morale.

The Agile Planning Onion

Each layer of the Agile Planning Onion is executed multiple times during the lifecycle of the project.  How often each layer is executed depends on where the layer is situated within the Onion.  More regular planning takes place at the lower levels of the onion, than at the higher levels.  More executive members of the organisation plan at the higher levels and have less involvement from the Release down. 

The Development team plan consistently during the Daily Stand Up, Iteration and Release phases of the project, but they may only occasionally need to revisit the original vision layer of the onion.  So, let’s now look at each layer of the onion in more detail…

 

Image Source

 

Vision

Annual Review. Higher level plans are made at the beginning of an Agile project when the Vision of the final product is originally planned.  These plans are made by the more executive members of the organisation together with the users. Business goals and success metrics are defined at this stage. These initial plans will be reviewed as the project progresses. 

 

Roadmap

Quarterly Review. This is where the team make long-term plans that consist of releases. The team will create a high-level plan of how requirements discussed at the vision level can be achieved during product development. Ideally, this roadmap should be visual so that dependencies between product features can be displayed and the team can decide which will be the most effective means of approach.

 

Release

Monthly Review. This is the monthly progress review.  A well-defined release plan will allow the team to determine timelines for delivery of each product feature. This is where stories come into being and mid-term plans are made that consist of iterations.

 

Iteration

Fortnightly Review. This is short-term planning where the team take ownership of individual stories. The team choose the stories to be addressed during the next iteration and then create a plan to deliver them.

 

Daily (Stand Up)

This is a daily planning session. Team members will discuss where they are up to presently and how far they hope to be by tomorrow.  It is a time for discussing any issues that have already been encountered and those that may crop up later. The idea is to focus on creating a plan that allows the team to continue with development.

 

As you move through the onion layers participants change.  At the Vision layer, as I said earlier, it is likely to be executive members of the organisation who are the decision-makers.  When you get down to Release, Iteration and Daily meetings, participants are going to be those who are working on specific tasks.  These layers are where collaboration between those working on the development of the product takes place most, as the individual is better placed to decide how their specific task/s will be addressed.

 

To Sum Up

So, to say that AgilePM does not involve any planning, is a complete misconception.  As has been shown, there is much planning during an Agile project, but it is carried out differently and more frequently than in a waterfall project.  Waterfall methodology demands planning right at the start for the whole of the project, whilst Agile plans are made regularly throughout the projects’ duration. 

A structured approach to planning is a must if the project is going to be successful.  For Agile, the Planning Onion allows teams to choose the right amount of planning for each timeframe as they progress through the project.  This allows for changes and alterations to be made at each stage of development, whereas waterfall methodology, being sequential in nature, may not find it so easy to adapt to change.