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
