PRINCE2 Agile Tips

From PRINCE2 Agile wiki
Jump to: navigation, search

Tips from the PRINCE2 Agile Manual

Tip: Technical phases (such as analyse, design, build, test and implement) can cover such terms as requirements, planning, deployment, integration, acceptance and construction. They can also be referred to as Technical stages.

Tip: Acceptance criteria is a term that is commonly used in agile to assess whether a user story has been completed. It is the equivalent to quality criteria in PRINCE2 and Definition of Done in Scrum.

Tip: AXELOS’s Management of Value(MoV) says that value is subjective, with different people applying different criteria to assess whether they are getting good value. It is this subjectivity that makes it so essential to manage value deliberately, instead of leaving it as a by-product of any other management activity. Added value is provided by the delivery of enhanced, but useful, benefits and more effective use of resources. Not all perceived benefits are actually necessary. MoV provides a means of distinguishing between needs and wants. Likewise the supply of resources is often (indeed usually) limited. Effective expenditure is essential to make the most of what is available. MoV recognizes that not all benefits are financial and that the differing priorities of key stakeholders need to be considered and reconciled. Expenditure must cover short- and long-term needs and recognize that resources are finite and must be conserved. Balancing and reconciling these conflicting demands, to maximize value, is one of the core principles of MoV.

Tip: For any situation that arises on a project, a key question (for anyone) to ask is ‘How does this affect the business case?’ This represents the bigger picture or, to put it another way, the main thing is to keep the business case as the main focus.

Tip: An independent quality assurance (QA) role means that there is a separation of duties and people don’t ‘mark their own homework’ (hence the need for the role).

Tip: Customer QA and supplier QA are split into two so that it is possible to check that: The thing has been built right and The right thi been built.

Tip: Working agreements and team rules include or are similar to policies, team norms or team charters

Tip: The Pastor of Fun is not an official PRINCE2 role.

Tip: Assess carefully the people representing the customer side of the project. Are they empowered? Are they respected? One useful ‘rule’ is to engage with people who the customer ‘won’t let you have access to’ (people who are seen as indispensable and the customer cannot afford to lose them to project work for any length of time).

Tip: Acceptance criteria are commonly used in agile to define how to know if a user story has been completed. See the glossary for definitions of ‘acceptance criteria’ and ‘quality criteria’.

Tip: If you don’t know how to test a requirement, then assume you haven’t understood the requirement yet.

Tip: An estimate should always have at least two parts: the estimate itself and a level of confidence for that estimate.

Tips: A good project manager prefers to be good at managing risk and not good at fighting fires. Quick check: Are risks getting identified during daily stand-up meetings?

Tips: The devil is in the detail – so expect it, allow for it and respond to it. The customer will ask for changes, so don’t let this come as a surprise.

Tip: Information radiators include or are similar to information displays, big visible charts (BVCs), team boards, Kanban boards.

Tip: If progress is visible and transparent it goes a long way to making life easier. You get all the news (good or bad) quickly.

Tip: Retrospectives include or are similar to continual improvement, Kaizen, inspect and adapt.

Tip: PRINCE2 uses the term ‘review’ for a specific purpose (i.e. when using the quality review technique) whereas it is used frequently in many forms when using agile.

Tip: PRINCE2 Agile regards agile as a family of behaviors, concepts, frameworks and techniques.

Tip: The project board should determine how long a stage should last before deciding what goes into it. They may wish to adjust this in a collaborative manner in the light of what is planned, but they should not be driven by this.

Tip: ‘Must’ is a level of priority for a requirement (or user story) that ‘must’ be satisfied because without it, either the output from a timebox won’t work or it is not worth delivering the output.

Tip: MoSCoW always relates to a deadline.

Tip: If ever you need to quickly demonstrate prioritization with MoSCoW, a simple ballpoint pen can be a useful prop (see Figure 25.2). It can also be used to illustrate decomposition and how a ‘must’ can exist within a ‘could’

Tip: It is possible to release features too quickly! So you need to involve the right stakeholders.

Tip: It may be appropriate to populate a list of FAQs for when the product goes into operational use.

Tip: Sometimes sprint zero (or early sprints) can be used for the initial delivery. (Also referred to as iteration zero or discovery.)

Tip: To deliver more, deliver less!

Tip: Take two minutes just to look at your team. How are they acting? What are they doing? What are they saying? How are they adopting the principles and behaviours? The answer will be obvious, as long as you take time to look for it and not look away from it!

Tip: Planning poker is a technique used to estimate effort or the relative size of development goals. Each member of the development group selects one card from a set of numbered cards and places it face down on a table. The cards are revealed, and the estimates are then discussed