The Many Levels of Planning on an Agile Project

Introduction

“He who fails to plan, plans to fail” Anon
“A good plan today is better than a perfect plan tomorrow” Anon
“Bad planning on your part does not constitute an emergency on my part” Anon
“Failing to plan is planning to fail” Anon
“Good fortune is what happens when opportunity meets with planning.” Thomas Alva Edison
“Plans are only good intentions unless they immediately degenerate into hard work.” Peter F. Drucker
“Proper preparation prevents poor performance.” Charlie Batch
“You can never plan the future by the past.” Edmund Burke

One of the fundamental Agile values is “we value responding to change over following a plan”  which has sometimes been misintrepreted to mean we don’t need to plan on an Agile project.

Nothing could be further from the truth.

The reality is that on adaptive Agile projects we do much more planning than on predictive projects[1] as we plan to accommodate the changes which we are certain will arise. Adaptive project environments are characterized by uncertainty in a number of areas:

• Requirements – while every project needs absolutely clear goals and objectives, the detailed requirements which need to be implemented to achieve those goals are probably not well understood in advance, and are likely to change over the life of the project
• Understanding of the problem domain – while accept that our understanding cannot be complete and that the initial vision of the solution needs to be able to change as we learn more about the realities of the problem area
• Rate of delivery – adaptive projects are largely creative in nature, and the teams are trying to solve problems where the solution may not be readily understood up front, and producing the solution requires invention. Individuals are not interchangeable and productivity is not consistent across individuals

Adaptive projects require an adaptive approach to development that allows the product to evolve as our understanding unfolds over the life of the project. The Iterative and Incremental way of working on Agile projects provides the needed feedback mechanism[2] to deliver adaptive projects.

Despite the adaptive nature of the Agile project ecosystem, it is reasonable and realistic that management want to know “how much will this cost and how long will it take”. Organizational resources need to be allocated to the project and decisions need to be made about what work to undertake. This means we need to provide feedback at a number of levels to answer the initial set of questions and on an ongoing basis through the project to ensure we are still delivering the best value for our organization's investment.

To achieve this we need to plan at many levels.

There are two broad categories which planning happens in:

1. The highest level of planning happens almost completely outside the team and this has to do with selecting which initiatives should be funded – doing the right work.
2. Once a project has passed the “should we do this?” filter we need to focus on doing the work right. This is where the five levels of planning on a project come in.

Doing the Right Work

This is about selecting which projects should get funded, and is represented by the graphic below:

Innovations and Problems

Every organisation needs a mechanism to get work into the pipeline – idea generation needs to be encouraged and problems identified. At the initial idea/problem generation stage there should be very little filtering, every member of the organisation should be able to point out something that is not working in the most effective way, identify a problem the organisation needs to address (such as a change in the marketplace or new legislation that we must comply with) or propose a completely new thing that could be done.

After an idea has been raised there needs to be an initial high-level filter – is this worth considering any further. Frequently this is based on a very quick cost-benefit analysis and feasibility assessment of the idea. Some ideas will automatically pass the first filter (a project that is about compliance with a legislation change must be done, for instance), some are quickly discarded (cost prohibitive or completely out of alignment with the organisation’s strategic objectives) and some will be worth considering further.

Those that get automatic approval and those which are worth considering further should feed into a Portfolio Planning process.

Portfolio Planning

Portfolio planning is a governance level activity which is about selecting the suite of programs and projects which the organisation should fund at any given time. Inevitably there will be more work requested than can be funded and the portfolio management process selects those which will be funded.

Deciding which work to undertake should be based on the organisations mission and goals – work should only be funded that delivers on the strategy set at the highest levels in the organisation. Portfolio planning is a risk-return based activity – the organisation’s risk management strategy helps select which pieces of work to fund.

Portfolio planning should happen above the level of any functional group in the business to ensure the end-to-end impact and value of the selected work is considered. At this level projects will impact many functional areas and it is important to avoid “turf wars” over jurisdiction. It is likely that any significant piece of work at this level will impact and require resources from a number of functional areas of the organisation (for instance launching a new customer self-service website is not solely an IT project, there will be an IT component, marketing to promote the use of the website, the service department to provide content for the knowledge engine, etc).

The portfolio process varies from organisation to organisation but should follow a clearly understood process and provide guidelines to[3]:

1. Build the portfolio of all projects
2. Evaluate the projects quantitatively and qualitatively
3. Decide which projects to fund now
4. Rank order the portfolio
5. Keep a running backlog of projects and actively manage the backlog based on new project requests and completed work

Where the work to be undertaken crosses multiple functional areas of the organisation and breaks into logical streams of related but independent activities then manage that set of projects as a Program of work.

Program Management

A program requires additional coordination to keep the interrelated streams of work synchronised – the advertising campaign needs to be ready to run when the software is completed, the call centre staff need to be employed and trained before the advertising campaign launches, the software needs to be on the production server before the advertising campaign launches etc.

The program manager should be a dedicated role who has the strategic view of all the streams of work that must come together to deliver to overall program. The program manager provides the unifying vision for the separate project teams who will work on different streams of work.

The program manager is the ultimate customer for all the project teams, and sets overall priorities and milestones.

Program management is an adaptive process as the program of work will need to respond to the changing realities of the organisation and the actual delivery and throughput of the separate project teams.

An overall program plan should be produced and maintained as things change. Key elements in the program plan include (ref Manage IT chapter 14 page 279):

• Overall product high-level requirements and goals/key features to be delivered
• Organisational goals to be delivered on by the program
• Costs & benefits across all aspects of the program
  • Marketing investment and approach
  • Sales approach
  • Likely revenues to be generated over the anticipated life of the product
  • Estimated costs to deliver across all the streams of work
  • Service, support and maintenance costs
  • Training for internal and external staff
• Key milestones and high-level schedule for the program, including the ongoing release cycle
• Staffing profile across the various streams of work and time
• Overall risk register for the whole program

Program management needs to provide direction for each of the streams of work. This is ideally conveyed in a Product Vision that each team fully understands and commits to.

Doing the Work Right

This is about making sure that the team working on a product deliver against the product vision. This is where the adaptive Agile team delivers business value on an iterative and incremental basis.

This diagram shows how planning happens at a more and more detailed level:

The Product Vision

The product vision is the point where we move from governance and organisation-wide strategic decision making to tactical delivery of products that result in changes to the way people in the organisation work.

The product vision is a crucial tool that needs to convey to the team why they are working, what they are working on and what key constraints they must work within.

The vision is often conveyed in a Project Charter document.

Ideally preparing the project charter should be a whole-team activity in a collaborative workshop. The project sponsor and product owner should be present at this workshop and they are responsible for articulating why the project is of importance to the organisation and what the key measures of success are for delivery of the product.

Sanjiv Augustine describes the key question for the project vision as “What do we hope to achieve for the organisation with this project?”[4]

The answer to this question will then guide all the work the team undertakes on the project, and also tells the team when to stop work. The overall definition of “done” for the project should be conveyed in the product vision.

Typical contents of the project charter include:

• Problem/opportunity description and rationale – why does this project matter to the organisation?
• What value will this project deliver to the organisation?
• How does the project align with the organisations strategic goals?
• High level solution description – what are we trying to deliver?
• Key features of the product to be built
• Any assumptions that are driving this project
• Technology or other constraints the project must work with
• Scope – what is included and what is excluded from this team’s responsibilities?
• Key timelines that the project should deliver against
• Budget and cost-benefit analysis
• Dependant & related projects and key milestones for coordination with those projects – especially important where this is part of a broader program of work
• Risks associated with this project, with mitigation actions where appropriate

There are a number of simple tools that can be used in visioning workshops to help the participants articulate and express the product vision. A few are listed below:

The Focusing Question or Elevator Statement

A one or two sentence statement that conveys the goals and objectives of the project.

The “elevator statement” is something that will enable any team member to explain the purpose of the project in the time it takes to ride between floors in an elevator (imagine you get into the elevator with the CEO of your company and are asked to explain what the project is you are working on before the elevator gets to their floor).

During the workshop this is one of the first things that should be produced, and written up for all to read – it provides focus for the rest of the workshop activities.

The Vision Box

A Vision Box presents the features and benefits of the project as a box of cereal – the front has a name and branding, along with a list of the key benefits the product will convey to its buyers (the customers who will eventually use the product, be they internal to the organisation or real paying customers). The back of the box contains operating instructions (high level design decisions) and a list of the key features the product will have.

Building a vision box is a creative activity that helps the team articulate what they are thinking about. It can be useful to break into smaller groups and have the groups each build a vision box that they then “sell” to the remainder of the team. After the separate presentations a shared vision box should be produced that conveys the ideas of the whole team.

Business Benefits Matrix

A simple matrix which articulates the strategic value that the product is intended to provide. The matrix looks like the following table:

The goals of the project are expressed against the strategic drivers, there should only be one primary driver and there might be a number of secondary or tertiary goals. Where there is more than one goal in a column then they need to be ranked to avoid the “everything’s critical” conflict.

Preparing this as a group activity helps the team to understand the clear and explicit focus for the project.

Sliders

A tool for showing the priorities for the team across multiple dimensions.

The sliders range from Fully On to Fully Off – if an element is On then it will be the strongest factor that drives the decision making as the project continues. No two sliders can be set at the same level, and the more sliders there are on the “On” side of the grid the higher the risk of catastrophic failure this project accepts. Where there is little leeway in the project sliders then the choice becomes deliver everything or deliver nothing, whereas more leeway allows for partial delivery that contributes to the organisations goals.

Rob Thomsett describes the Slider tool in his book Radical Project Management.

Mike Cohn provides an online tool for setting sliders on his website

Scope Matrix

The “in/out list” is a simple tool that conveys clearly what will be done as part of this project, what will not be done and where there is uncertainty about deliverables.

Where a topic is “in” the project team is responsible for delivery of this component.

Where something is explicitly out of scope the team will not spend any time or effort on this component. If an “out” topic is something that the broader program of work is dependent on then it is important that the responsibility for undertaking this work is clearly defined, the project stream and person taking responsibility for ensuring this is delivered.

Where there is uncertainty about a topic being in scope or not then it goes into the “Undecided” area. The team will not work on his piece and the product owner or project manager needs to investigate further to identify if the piece of work is in or out of scope.

This tool is also explained in Radical Project Management, by Rob Thomsett.

Cost/Benefit Matrix

This should convey the level of uncertainty surrounding the estimates of both cost and benefit the organisation will get from the project. Early in the project the costs will have a large Cone of Uncertainty[5] and as the project progresses this will get narrower and narrower. It is likely that the benefits also have a wide range of uncertainty. Uncertainty in both costs and benefits is not necessarily a problem on a project provided the range is correct. Both costs and benefits should be shown at three levels – optimistic, likely and pessimistic. For example:

The figure in each cell is the net of benefit minus the cost.

This project should be considered high risk, as there is a distinct possibility that the organisation will lose money on it. There might be other drivers which warrant the investment and the reward profile if things go well is significant.

Undertaking cost/benefit analysis on a project is primarily a management level responsibility, but the financial goals and drivers should be shared with the team.

Articulate the Vision

These tools can help teams gain a clear understanding of the goals and objectives that have driven the selection of this project to be worked on.

Preparing the product vision is a very important starting point for the project. This provides the focus for the work the team will undertake as the project continues. The wallware[6] artefacts produced during the workshop(s) should form part of the team environment so anyone working on the project can see at a glance the project drivers and goals. It may also be valuable to produce a formal document that summarises the product vision. Remember that the value lies only partly in the document but in the shared understanding that the team has achieved in producing the vision.

If the team who will work on the product are distributed they should be brought together for the production of the product vision – this will help to create a “one team” culture and help with the ongoing communication when they are dispersed.

Team members who join after the vision has been created need to be walked through the project charter by someone who was present at the workshop(s) to help them understand the drivers behind the work being undertaken.

Stewardship of the product vision is the responsibility of the product owner – the person who brings the business need to the project team. If during the execution of the project the environment changes and the vision is no longer achievable or the organisation goals/drivers change such that the project no longer delivers on them then the project should be stopped and reassessed. Changes in the product vision are frequencly evidence of massive change in the organisation ecosystem.

The Product Roadmap

The product roadmap is a list of the key features and characteristics that the product will need to deliver in order to achieve the vision. The product roadmap is important where the project spans a number of releases of the product. If there is only a single release then the product roadmap and the release plan could be the same thing.

The product roadmap is a time-based view of the anticipated delivery lifecycle of the product. It is a high-level plan maintained by the product owner and project manager that is expected to change over time.

The product roadmap is regularly validated against the product vision and is used to convey to the team and the outside world the likely release schedule for components of the product.

The product roadmap is at the level of features and epics – user stories are not included.

A product roadmap should be expressed as a big visible chart that shows important milestones, features and target release dates. As changes are made items are added, moved and removed from the roadmap.

The picture below is an example of a product roadmap from a real project, showing two releases over a six month period:

(Image credit - Livestock Improvement Corporation, New Zealand)  

This roadmap is on the passage in the team environment and acts as an information radiator for all the teams who are working on the program of work, and for anyone else who is interested in the project. The product roadmap provides a context for the teams working on a single release.

The Release Plan

The release plan shows the features that are to be delivered in the current release of the product. It contains the currently agreed prioritised list of features at the level of epics and stories. The release plan is based around the team’s anticipated velocity and conveys a shared understanding about what needs to be included in the current release.

The initial release planning activity is undertaken by the team with the product owner providing the goals for the current release. A release consists of a number of iterations during which the team will undertake work to deliver a set of features that deliver measurable value to the organisation. The set of features and capabilities make up the release criteria – the subset of overall product functionality and capability that is to be delivered in this release.

Stories and epics need to be sized (in story points[7] or ideal days) and prioritised so that the work can be allocated to iterations. Release planning starts with the product owner explaining the goals for the release. The team discusses what is needed to deliver against these goals and expresses any other factors that need to be taken into account when delivering the release. Other factors can include risk and dependency between epics and stories. High risk-high value features should be prioritised for delivery early so the project can adapt should the risk evolve into a problem (eg the technology can’t actually do what we anticipated it would). Dependencies might impact the sequence of delivery (if we do this piece first then that piece will be easier to do later).

The team’s velocity is used as the starting point for the release planning activity. If this is the first release then the velocity needs to be estimated, for subsequent releases then the actual velocity from the previous release should be used (unless the team changes significantly between releases).

Identifying the estimated velocity is initially a guess – the more accurate the guess needs to be the longer it will take to come to the answer. The simplest approach is to ask the team how many story points they think they can deliver in an iteration and plan based on that number. It will probably be wrong, but it could be a good enough starting point.

To get a better estimate of the team’s capacity to deliver, use more thorough estimation techniques, understanding that more accuracy costs more to achieve and may not provide significant benefit for the cost incurred – James King provides a useful estimation toolkit downloadable from his website: 

Once you have the estimated velocity this can be used to plan the iterations as follows:

1. List the stories and epics for the release in priority order with their size in story points
2. Decide (from your estimation activity) how many story points can be delivered in a single iteration
3. Consider the impact of non-story work the team may need to undertake (for example it is common that early iterations will be slowed down by not having all the tools and environments the team needs in place)
4. Add a new iteration to the plan
5. Add stories to the iteration until the available capacity is consumed
6. Ask – have all the stories been addressed and the release goals achieved
7. If not then add a new iteration to the plan and repeat steps 5 &6
8. Once all the stories have been allocated, socialise the plan and ask for feedback from the team – is it sensible and achievable.

This process can be seen as a flowchart:

The release plan is an adaptive plan – it WILL change as the project progresses.

Once the release plan has been produced and agreed to it is used to guide the work in the iterations.

The release plan is also used to produce the initial target velocity graph for the project.

The Iteration Plan

At the beginning of every iteration the team is able to completely replan the project based on what has been learned from the work done so far, and changes to the broader project environement. The iteration planning session has two primary activities:

• Validating and updating the release plan and
• Making the iteration plan for the current iteration.

The first activity is to examine the current release plan and update it based on any changes that have happened since the last update. The beginning of iterations is where an Agile project adapts – changes are made to the plan based around the actuality of the project environment.

Specific things that impact the revised release plan are:

• Actual velocity of the work delivered in previous iterations – is it faster or slower than was originally planned; changes in velocity define the scope of work that can be undertaken in the remaining time of the project
• Changes in priority of existing stories and epics
• New stories and epics that need to be introduced to the project because of changes in the project ecosystem
• Defects and technical debt[8] that have surfaced as the work is undertaken
• New or changed stories that have surfaced as a result of risk identification
• Hangover stories from the previous iteration that have not been completed
• Non-project work that reduces the team’s ability to undertake project tasks

The first part of the iteration planning meeting is to identify the currently most important set of epics and stories that the team will work on during the iteration. The product owner explains the current priorities and the reason behind the changes, to ensure that the whole team has a clear understanding of why priorities have changed.

Once the list of stories and epics has been reprioritised and everyone on the team understands the revised release plan, the team builds the detailed iteration plan for the work to be done in this iteration.

The team estimates how much they will be able to complete in the iteration based on “yesterday’s weather” (it is very likely that they will complete the same amount of work in the next iteration as they did in the previous iteration, unless something has significantly changed in the working environment or team makeup) and common sense. They then pick the stories to be worked on for the iteration based on the capacity to deliver work.

Once the set of stories and epics to be worked on is identified then the team breaks the work down into specific tasks for each team member – task allocation is ideally done on a “pull” basis whereby team members identify the work they are able to do and select their own tasks. Tasks should be very small – from a few hours to a day or so, and are discrete measurable activities. The iteration manager (Scrum Master in Scrum) confirms that all the tasks are allocated and performs a sanity check on the work being committed to – is it likely that the team will be able to deliver what they are committing to given the reality of the project environment?

Once tasks have been identified the team members sequence and estimate them. Estimation is now at the level of hours of work needed to undertake a single task. These tasks could then be written up on task cards and the task cards tracked on the storywall.

Tasks are linked to stories, and tracking a story from one state to the next on the storywall should be accompanied by the completion of the task for that activity.

Tasks include every piece of work needed to complete the stories in the iteration, and to start preparing for the next iteration.

The Iteration Backlog is the list of stories and epics which will be tracked on the story wall for this iteration.

An example of a partial list of tasks is shown below:

During the iteration team members report and track their work against the tasks. This is their individual daily commitment.

A burn-down chart shows the initial estimate and remaining effort for the iteration. The actual amount of time taken for each task can be tracked and used to help the team improve their estimation in the next iteration planning meeting.

Daily Commitment

This is where the team members monitor their own progress and report against the tasks they have committed to.

The Daily Standup is the primary communications tool for communicating progress within the iteration. Every working day of the project the team gets together and reports to each other their progress against the tasks they have committed to. The Daily Standup has a few simple rules:

• It is held standing up
• Maximum duration is 15 minutes
• Each team member will speak for no more than one minute
• Progress is reported against stories and tasks ONLY
• Task reporting is binary – a task is either Done or Not Done
• Tasks that are not done are reported with hours/points/effort remaining to completion
• Obstacles that are preventing a task from being undertaken or hindering progress are reported separately
• Each team member answers the following three questions:
  • What have you done since the previous meeting (with reference to the tasks, not how you spent your day)?
  • What will you do before the next meeting?
  • What is in your way? (“Nothing” means you have confidence that you will deliver the current task within the timeframe that was estimated for it)
• If there are issues to be addressed they will be taken up AFTER the daily standup – it is common for the daily standup to be followed by a few short one-on-one sessions to address specific issues
• The iteration manager is primarily responsible for getting the obstacles removed so the team can be fully productive

An Agile project must be a “safe to fail” environment – team members will not be punished for not meeting task commitments. It must be safe to tell the truth about task status and to learn from the actuality of the project environment. Sometimes we will estimate badly (it is an ESTIMATE not a quote) or something will happen that prevents someone from working on their task – the environment must make if OK to report the truth, as that way team members can adjust their schedule and sequence of tasks and adapt to the realities of the project.

When all the tasks for a story have been completed the story will move into the Done state, and the project velocity is credited with the story points for that piece of work.

Conclusion

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” Dwight David Eisenhower

This table summarises the levels of planning and the involvement in the planning process at each level:

Planning pervades Agile projects – simple tools and safe environments support adaptive planning and honest reporting which means progress is reported truthfully and management have the information they need to make good decisions that enable the delivery of the best outcomes for the organisation, team and project.

Agile planning takes into account that systems development is undertaken in complex and often unpredictable environments and that flexibility and the ability to respond to change is paramount.

References

• Agile Project Management – Sanjiv Augustine
• Agile Project Management – Jim Highsmith
• Manage IT – Johanna Rothman
• Manage Your Project Portfolio – Johanna Rothman
• Radical Project Management – Rob Thomsett
• Agile Estimation & Release Planning – Software Education
• This link
  

  ---

[1] We use the term “predictive” instead of the more emotive “waterfall”. Predictive projects are ones in which the needs are not likely to change and where the work being done can be easily identified and measured. An example of a predictive project would be the deployment of a new operating system across all the computers in an organisation – the amount of time and effort needed for upgrading each computer is predictable and (to a certain extent) putting more people on the work will result in a directly proportional reduction in the time needed. Adaptive projects are those where requirements are likely to change and the work is largely creative with high levels of uncertainty – software development is an inherently adaptive process and does not suite a predictive project framework.

[2] Alistair Cockburn provides a very valuable discussion of the meaning of Iterative and Incremental – iterative means subject to change, incremental means piece by piece. Agile development is both iterative and incremental. See this link. 

[3] Manage IT by Johanna Rothman Chapter 16, p 307

[4] Agile Project Management – Sanjiv Augustine

[5] See this link 

[6] Wallware refers to flipcharts, graphs, story cards and other artifacts that are prominently displayed in and around the team space, they provide a visual record of the project, serving as reminders of key decisions and visible to anyone who has an interest in the project. Other commonly used terms are Information Radiators and Big Visible Charts.

[7] Story points are an estimation tool based on the relative level of effort and complexity involved in delivering the product. Planning using story points takes advantage the power of collaboration where each team members participates in evaluation of the user stories in terms of complexity. Criteria such as difficulty of implementation, clarity of understanding and technical risks are included in the estimate of the effort required to implement a particular story. This approach has been found to o be much more effective than traditional one off estimates at the beginning of a project.

[8] See this link