23.1 Baseline products
Baseline products are subject to change control. In Table 23.1, the numbered baseline products refer to the numbers used in the PRINCE2 manual for the PRINCE2 management products (see also Table 16.2).
|Baseline products||Overview of the tailoring required and further considerations|
1. Benefits review plan
There is likely to be an emphasis on how frequent releases have been planned in order to enable benefits during the course of a project. This may lead to the early delivery of actual benefits to the customer. The way these are planned will have an impact on the ongoing viability of the project. It would be likely that a significant amount of benefits are planned to be delivered (or at least enabled) before the project end date.
2. Business case
This needs to be expressed in a way that allows for flexing of the amount being delivered. The MVP would need to be identified so that an exception can be raised if this is forecast to be delivered later than expected (see Chapter 9, Business Case theme, for more details).
4. Communication management strategy
It is essential that there is a clearly understood and agreed strategy regarding the common techniques and concepts that agile uses to communicate (e.g. informal interactions, daily stand-ups, modelling, prototyping, visualization and workshops). See also Chapter 25.
This applies to all levels of the project and would define approaches to such things as how a sprint review will take place and how the delivery teams will communicate with the project manager through checkpoint reports.
6. Configuration management strategy
The iterative and incremental nature of agile means that there will naturally be several versions of products and that change is inevitable; therefore this should be embraced and supported accordingly. In environments where automation and frequent releases into operational use occur, specific tools may exist and their use should be clearly defined.
The level at which configuration management takes place needs to take into account that project- or stage-level change may affect the agreed baseline, whereas detailed change is likely not to.
16. Plan (project, stage and team)
Agile plans tend to be informal or low-tech at the delivery level and this can be highly effective even though they may be no more than to-do lists or backlogs. However, there may be more formality as the level of planning goes higher. Release plans may also be created to complement the planning at the stage plan level.
Agile plans are likely to show features (or sets of features) and their order and their dependencies, and are likely to have been created collaboratively by those who will carry out the planned work.
Product-based planning can still be used at all levels of the project (including product delivery).
17. Product description
Product descriptions can be used interchangeably with user stories (and sometimes epics). Both product descriptions and user stories can be product backlog items. They describe the ‘who, what and why’. A product description can contain more information than a user story. Product descriptions can be used in tandem with user stories by defining the higher level of understanding with product descriptions and the lower levels of understanding with user stories.
The format of a product description could be an index card or a document.
See Figure 25.1 for mapping product descriptions, requirements, epics and user stories.
19. Project brief
Although this is an important product in PRINCE2 it may have an informal format and presentation when working with agile.
The project definition in an agile context is preferably more outcome-based than solution-based and is also likely to outline the areas of scope and quality criteria that have flexibility in the sense that they can be prioritized.
The project approach will contain an agile element describing the use of agile, which techniques and approaches have been selected, and how the agile element will benefit the project.
The delivery-level roles in the project management team structure will have more detail and may be included.
Due to the desire for incremental delivery of benefits there will probably be more detailed information on the impact this may have on areas such as operations and maintenance.
20. Project initiation documentation (PID)
The guidance provided for the project brief is also appropriate for this product although the understanding of the project will now have evolved further.
In an agile context the PID should be created with the view of ‘enough and no more’. That is to say it should be complete, but it needs to be as concise as possible and at the appropriate level of detail. Otherwise its role as a form of communication will suffer.
This product (or parts of it) may exist on an information radiator if appropriate for the project environment.
21. Project product description
In alignment with the business case this is likely to focus on defining a product with a close link to a desired outcome in preference to just defining a solution. It may be created as part of a workshop (e.g. a visioning workshop). The purpose of this product should be clearly visible to all irrespective of the project environment (e.g. it should be clearly displayed on a wall or clearly displayed on the intranet).
It is an important product when combining PRINCE2 with agile in that it defines the ultimate output (the final product) and the outcome, which needs to be clear and precise so that the iterative and incremental nature of agile does not go off track.
The ‘composition’ field will either contain the highest level of product descriptions or product groupings and their respective priorities. Either way these will be similar to epics.
22. Quality management strategy
The agile way of working needs to be incorporated into the strategy for ensuring that the quality level is maintained. Some agile concepts exist in order to protect the level of quality (e.g. by delivering fewer requirements in order to ensure that the quality reviewing is not compromised). Agile behaviours will need to be part of the strategy, as they need to be assured.
There may be occasions when the quality level will be set at a low level due to the uncertainty of the work involved (e.g. the project could be highly innovative). The audience for this may be ‘early adopters’ who are more interested in utilizing the product and do not mind some deficiencies in terms of robustness or stability.
24. Risk management strategy
Any way of working has risks associated with it, and the risks associated with using agile need to be managed. An agile risk assessment is used to help with this (see Chapter 24). There is likely to be more focus on the risks associated with the agile behaviours than with other areas of agile because this is where many of the benefits of using agile are found. There may be a significant impact on the project should the behaviours break down.
In terms of roles and responsibilities, the agile way of working relies on everyone looking out for risks and raising them quickly (see also Chapter 13).
26. Work package
How work packages are specified has a very significant impact on successfully combining PRINCE2 with agile. Although it is a formal interface this would typically be carried out in a collaborative way and negotiated by the project manager and the team manager and perhaps with the delivery team as well.
One or more work packages may be collaboratively defined as the output from a sprint planning meeting.
A work package should be defined in such a way as to create a safe boundary of control, while at the same time creating the space for the delivery team to create the product (or products) in the most effective way through self-organizing.
A customer subject matter expert (SME) is likely to help with prioritizing the work involved.
A work package may include one or more releases and one or more sprints. Therefore it is essential from the start to get clarity on how work packages will be designed and how they will operate on a project.
Table 23.1 Tailoring baseline products