Plans

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 between upfront planning in Agile and in predictive projects. Upfront planning is not acceptable, as long as it blocks adaptation, which happens when you try to fully define the product. It’s OK if the plan is value-based/outcome-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 with the price. This unfortunate situation limits Agility, but since many suppliers cannot afford to lose most of the customers who insist on having fixed-price contracts, 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. For example, 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^® Guide all the time.
• Involving the team in planning. This is again a good practice promoted by most project management systems such as the PMBOK Guide. 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.

Estimation

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 at 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 will be assigned to the reference – usually 1. In this case, the reference would be the definition for 1 story point.
• Then, 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 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.

Prioritization

The scope of the project is usually fixed in predictive systems, and 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.

• Project Plan: 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.
• Stage Plan: The Stage Plan is likely to be formal, in a less or more traditional way.
• Release Plan: 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.

See Also

• Requirements focus area
• Project Brief
• Project Initiation Documentation

External Links

• Plans theme in PRINCE2 wiki

Written by Nader K. Rad

This is (and will be) a work in progress: More details will be added in the future, depending on the feedback.

This wiki is developed and managed by an accredited trainer, independent of AXELOS. While aligned with their guidelines, it’s not an official resource.