One of the main differences between predictive and adaptive (Agile) systems is that predictive projects are planned upfront, and the goal is to follow the plan. Upfront plans are not used in Agile projects the same as predictive ones.
Upfront Planning in Agile
Agile projects are still planned, and one should understand the differences. Upfront planning is not acceptable, as long as blocks adaptation, which happens when you try to define the product. It's OK if the plan is value-based and looks at the product only in a high-level way.
While a complete Agile system doesn't use limiting upfront plans for the product, those that try to use a fixed-price contract have to define the scope along the price. This unfortunate situation limits Agility, but since many suppliers cannot afford to lose most of the customers who insist on having a fixed-price contract, it's common to see Agile projects with upfront plans. In this case, the customer and the supplier will have to have a swapping/trading system to enable changes in the project. Check the Change Theme for more information.
Agile Planning Approach
PRINCE2 Agile recommends following the three common planning approaches of Agile systems:
- Having product-based plans, rather than process-based ones. E.g. planning the features and functions, rather than steps such as specification and design. Note: this is a general good practice that have been promoted by PRINCE2 and PMBOK all the time.
- Involving the team in planning. This is again a good practice promoted by most project management systems such as PMBOK: when you involve the team in planning,
- The plans would be more realistic, and
- You will have the team's buy-in.
- Planning as late as possible. This approach might be counter intuitive, and needs elaboration. The product-related plans should be done as late as possible, because we don't want to block adaptation, and need the product to evolve during the project, based on the feedbacks. The value-based and strategic plans are better done as soon as possible.
A good practice in Agile environments is to use effort-based units instead of time-based units such as man-hours. The most common effort-based unit is Story Points, which are relative. This is how story points work:
- An item is selected as the reference in the beginning of the project, and it will stay the same. The item should be small, and familiar for everyone.
- Then a story point value would be assigned to the reference; usually 1. In this case, the reference would be the definition for 1 story point.
- And finally, when you're supposed to estimate an item, you will compare it with the reference; if it seems to be twice as big as the reference, it would be 2 story points (can be shorten to 2sp); if it's half the size, it would be 0.5sp; and so on.
- You can always convert the story point to time using historical information. For example, if your velocity is 10sp/day, you can say that a 5sp item will take half a day to complete.
It's best to use effort-based units in PRINCE2 Agile as well.
Backlogs vs. Gantt Charts
A well-formed Agile project uses independent items in the scope, and therefore, there would be no need for a traditional Gantt chart and CPM calculations which are all based on the dependencies. In return, simple lists called backlogs are used to capture the information. These lists, along with their metadata, are an important part of plans in Agile projects, and can be used in PRINCE2 Agile too.
The scope of the project is usually fixed in predictive systems: the project is not finished until all features are developed. In Agile projects in contrast, the identified parts of the scope are prioritized (e.g. using MoSCoW Prioritization), and we might drop some of the lower-priority items. More on this on the Requirements focus area.
Levels of Planning
PRINCE2 is originally based on the Manage by Stages Principle, and consequently, 3 levels of plan. This increases into 4 levels in PRINCE2 Agile.
The Project Plan should be formal, based on values and strategies, and since it's about very high-level items, some dependencies can be expected among them.
The Stage Plan is likely to be formal, in a less or more traditional way.
Release Plan is specific to PRINCE2 Agile and is located between the original Stage Plans and Team Plans. Each release is a set of iterations, when their output is supposed to be put into operation.
The Release Plans can be formal or informal, but likely in a backlog format rather than classical diagrams.
If required, each Stage can be tailored into a release. In this case, the Stage Plan and Release Plan would be the same.
Team Plan / Iteration Plan
Team Plans are optional in PRINCE2, but cannot be considered optional in PRINCE2 Agile; while they would be really simplified. They are usually in a backlog format. In case of using Scrum, the Sprint Backlog is the Team Plan.
- SU: Starting up a Project Process
- IP: Initiating a Project Process
- SB: Managing a Stage Boundary Process
- CP: Closing a Project Process
- (DP): Directing a Project Process (note that not all activities in this process are shown in this diagram)
- The above image assumes that Scrum is used in the delivery level, which is not necessary.
- The number of stages, releases, and Sprints are just examples, as well as the exception in the third stage.
- The diagram is schematic and many details are not shown.
- Plans Theme at PRINCE2 wiki