Tailoring Prince2 Themes Flashcards
List the Prince2 themes to be tailored for Agile
- Business case
- Organisation
- Change
- Risk
- Plans
- Progress
In terms of the theme “Business Case” what is the general view from an Agile perspective?
(2 bullet points)
• May not exist in some Agile environments as there maybe a focus of value assigned to features instead
• Maybe created at the beginning (Sprint Zero)
Provide an overview of tailoring the Prince2 theme with Agile for: Business Case
• BC maybe affected by amount being delivered
• Early delivery of benefits will affect BC
• MVP needs to be clearly stated
• Project viability not the same as MVP
• Best-case, worst-case and expected-case relate to amount of features delivered (these scenarios only applicable to high/intermediate requirements not at detailed level)
• The least possible time taken when its high uncertainty
Summarise “defining value” in the business Case when tailoring Prince2 Agile
• Subjective
• Easier to assign relative values
• Value assessed in many ways (revenue, costs, satisfaction)
• A need to differentiate between output, outcome and benefit
• Outcome & benefit need to be measurable
• BC should be flexible to maximise benefit
• Focussing on benefits is helped through collaboration
Summarise “User Stories”
• Similar to requirements:
As a <role>, I want to <function>, so that <benefit></benefit></function></role>
• Additional info: Acceptance Criteria, Effort Involved & Value
• A starting point not fully defined
• Technical stories can be used for non-functional requirements
What are the 2 common techniques for creating User Stories?
- The ‘Three C’s’
- Card (writing it)
- Conversation (Ongoing discussion)
- Confirmation (writing acceptance test)
- INVEST mnemonic
I - Independent
2 - Negotiable
3 - Valuable
4 - Estimable
5 - Small
6 - Testable
Summarise ‘Using Prioritisation’
• Used on: Non-functional Requirements, Quality Criteria, Quality Review Activities
• Handles change, but us it detail change or baseline change
• Detail change can be handled dynamically
In MoSCoW, what ideal percentages of the project should be set to working on “Must Have, Should Have and Could Have” requirements?
60% on Must Have Requirements
20% Should Have Requirements
20% Could Have Requirements
When is the “ordering” method of prioritisation appropriate?
• Little dependency between items
• Items do not naturally group together
If there are baseline changes to the Project who owns/responsible for this?
• Senior User
• Not the development team
In terms of the theme “Organise” what is the general view from an Agile perspective?
• Self-organising
• 2 common roles:
- Scrum Master
- Product Owner
• Less prominence for:
- Project Manager/Team Manager role
- Requirements Engineer/Business Analyst etc
What are the adjustments to the theme “Organisation” when Agile is applied?
• Common Agile concepts may need to be adjusted
• Agile teams prefer to be led/coached rather than managed
• Common Agile guidance refers to a single product owner
• Common Agile guidance does not have a PM unlike P2.
• TM role needs to integrate into an Agile Delivery Team.
Outline how the theme “Organisation” links to the Delivery Team when Agile is applied.
• How the PM relates to the delivery team is key
• 3 options:
> Leave the delivery roles as is
> “ but identify a single point of contact for PM
> Create a TM role in delivery team
Outline how applying Agile affects the Delivery Team Roles in the theme “Organisation”.
• Usually represented by some or all of the following:
- Someone to lead the team (scrum)
- “ from customer to represent the customer
- A team to create the product
- Someone to assure product quality
- “ “ coach the team (Agile too) Scrum Master
- Multi-skilled generalising specialists
In the Agile Delivery environment how is the PM seen as?
Servant Leader in the team
• Partially conflicting with P2
• Focusing on:
- Empowerment
- Collaboration
- Facilitation
• How much of a servant leader depends on context
• P2 doesn’t limit servant leadership use
Provide an overview of tailoring the Prince2 theme with Agile for: Change
- Agile embraces change
- Detail change is viewed as positive
> However baseline change may not be
What is the general guidance of the theme “Change/Guidance” in regards to the tailoring of Agile
• The definition of “requirement” can be binary or spectrum
• Good risk& configuration management can lessen impact of change
• Empowered Self-organising teams handle change dynamically within defined tolerances
Provide an overview of tailoring the Prince2 theme with Agile for: Risk
• Risk addressed during stand-up meetings
• Agile risks assessed using the Agilometer
• The 5 behaviours in P2Agile help manage risk
Provide an overview of tailoring the Prince2 theme with Agile for: Progress
• Vitally important
• Burn charts & WIP boards commonly used
• The bigger picture relates to key Agile values (eg. Transparency)
How would it be discovered that something needs to be descoped?
• Via daily stand-up meetings in the delivery team
• Use of visuals like burn charts
Summarise Cumulative Flow Diagrams (CFDs)
• Track work items and show amount of work in each column each day
• WIP is the vertical difference between top & bottom lines, whereas horizontal difference shows lead time
Provide an overview of tailoring the Prince2 theme with Agile for: Quality
• Important techniques like Def. of Done & “Acceptance Criteria” address quality control - avoids last minute scope creep
• Concepts like ‘test as you go’ or ‘test first’ are used for testing and quality checking
• Evolving the def. of done is commonly used
• In some Agile environments, not much emphasis on quality planning & management during start.
What is the guidance when tailoring Prince2 Agile with regards to the theme “Quality”?
• Product Descriptions & work packages are flexible (eg. can be user stories)
• Purpose of the Project Product Description would now preferably be defined as an outcome
• Quality Management & Planning now includes:
- Tools & approaches to be used
- Customer Role (now essential)
- Assessing & costing the resources
- Quality control considerations
When tailoring the Prince2 Agile theme “Quality” How is testing undertaken?
• Care when transferring these concepts from software domain
• Common Agile terms:
- Test-driven Development (TDD)
- Behaviour-Driven Development (BDD)
- Definition of Done & Ready
- Refactoring
- Technical Debt
Summarise the Prince2 Agile Quality Testing method “Test-Driven Development (TDD)
• Short development cycle in software:
1. Developer creates a test for a new function (automatically fails)
2. Dev produces minimum code to pass
3. New code refactoring to meet srandards
Summarise the Prince2 Agile Quality Testing method “Behaviour-driven Development (BDD)
• Software development based on Test-driven development
- More collaborative
- Used in a wider behavioural context
- Simple language for the customer
Summarise the Prince2 Agile Quality Testing method “Refactoring”
• Changing a product and improving its internal structure but not altering external behaviour
Summarise the Prince2 Agile Quality Testing method “Technical Debt”
• Refers to eventual consequences of poor system design, architecture or development in software
• The debt is seen as the work required
• If not repaid it will accumulate interest making changes harder later on
- eg developer forced to move onto next piece of work without all the testing being done. Still needs doing later on!
• Unpaid debt affects level of quality
• In P2 tolerances can be applied any may even cause an ‘exception’
Provide an overview of tailoring the Prince2 theme with Agile for: Quality in relation to SCOPE.
• A reduction in scope is not seen as a reduction in quality (P2)
• Customer Quality Expectations are set and need to be maintained
• Quality defined by Quality Criteria
• Scope is defined by the products themselves
What are the 5 Prince2 Agile Behaviours?
• Transparency
• Collaboration
• Rich Communication
• Self-organisation
• Exploration
In Prince2 Agile how is the behaviour “Rich Communication” focused on?
• Problems need to be proactively addressed
• Effective communication is vital to Agile
• Channels: Written, visualisation, Verbal via telephone & face-to-face
• Circle of communication theory
- Tone of voice - 37%
- Words of choice - 7%
- Non-verbal communication - 55%
