Agile BA Agile Business Analysis Foundation and Practitioner
Agile. BA® Agile Business Analysis Foundation and Practitioner © The APM Group Ltd 2016. This document is not to be reproduced or re-sold without express permission from The APM Group Ltd. Agile. BA® is a registered trade mark of Dynamic Systems Development Method Ltd. The APMG-International Swirl Agile. BA Device is a trade mark of APM Group Ltd.
2
Welcome Name Background Individual objectives from the course 3
Course Objectives To enable delegates to: Understand the role of the Business Analyst in an Agile world To prepare for the Agile. BA exams – Foundation exam format: • 50 questions, 40 minutes, 25 marks to pass (50% pass) • Closed Book – Practitioner exam format: • 4 questions, 80 question items, 2. 5 hours, 40 marks to pass (50% pass) • Open Book 4
5
Content 6
Chapter 1 The Role of the Business Analyst in an Agile World The Holistic View of the Business Understanding the Business Environment The Value Chain and Lean Thinking Implementing the Organisations Strategy Change Projects 7
The Holistic View of the Business The Business Analyst’s role is to study the overall business and information needs of an organisation at: Corporate Level Programme Level Project Level The main focus of this course is at the Project Level 8
Structure of the Business Organisation 9
Understanding the Business Environment 10
PESTLE Analysis 11
Porter’s Five Forces Analysis 12
MOST Analysis 13
Resource Audit Identifies an organisation’s strengths and weaknesses: 14 Physical resources e. g. buildings Financial resources e. g. assets Human resources e. g. skills, flexibility "Know How" e. g. Patents, exploitation of technology Reputation e. g. Brand Recognition
SWOT Analysis 15
TOWS The organisation Strengths – S Weaknesses – W 1. Existing brand 1. Brand perception 2. Existing customer base 2. Intermediary use 3. Existing distribution 3. Technology/skills 4. X-channel support Opportunities – O SO strategies WO strategies 1. Cross-selling Leverage strengths to maximise opportunities Counter weaknesses through exploiting opportunities 2. New markets = Attacking strategies = Build strengths for attacking strategy Threats – T ST strategies WT strategies 1. Customer choice Leverage strengths to minimise threats Counter weaknesses and threats 2. New entrants = Defensive strategy = Build strengths for defensive strategy 3. New services 4. Alliances/Co-branding 3. New competitive products 4. Channel conflicts 16
Porter’s Value Chain © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook. 17
Lean Thinking 18 © Double Loop Limited
Mc. Kinsey 7 S Model 19
Balanced Business Scorecard 20
Planning and implementing change: Core considerations Culture Communication Collaboration 21
End of Chapter 1 22
Chapter 2 Agile Fundamentals and the Agile BA Choosing DSDM as your Agile approach Philosophy and Fundamentals Understanding Project Variables DSDM Principles DSDM Process DSDM Team Model 23
Source: www. agilemanifesto. org 2001, reviewed 2011 24
Philosophy “Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people” 25
Project Variables Traditional Approach 26 DSDM Approach
The 8 Principles Focus on the Business Need Deliver on Time Collaborate Never Compromise Quality Build Incrementally from Firm Foundations Develop Iteratively Communicate Continuously and Clearly Demonstrate Control 27
Focus on the Business Need Every decision taken on a project should be viewed in the light of the overriding project goal – To deliver what the business needs to be delivered when it needs to be delivered It is important to remember that a project is a means to an end, not and end in itself 28
Deliver on Time Delivering a solution on time is a very desirable outcome for a project Late delivery can often undermine the very rationale for a project – with respect to market opportunities or legal deadlines The best way to demonstrate control over the evolution of the solution 29
Collaborate Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association Collaboration encourages increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their parts. 30
Never Compromise Quality In DSDM, the level of quality to be delivered should be agreed at the start All work should be aimed at achieving that level of quality – no more and no less A solution has to be ‘good enough’ If the business agrees that the features in the Minimum Usable Subse. T meet the agreed acceptance criteria, then the solution should be ‘good enough’ to use effectively 31
Build incrementally from firm foundations DSDM advocates first understanding the scope of the business problem to be solved and the proposed solution, but not in such detail that the project becomes paralysed by overly detailed analysis of requirements Once firm foundations for development have been established, DSDM advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical. 32
Develop iteratively DSDM uses a combination of Iterative Development, frequent demonstrations and comprehensive review to encourage timely feedback Embracing change as part of this evolutionary process allows the team to converge on an accurate business solution It is very rare that anything is created perfectly first time and it is important to recognise that projects operate within a changing world 33
Communicate continuously and clearly Poor communication is often cited as the biggest single cause of project failure DSDM practices are specifically designed to improve communication effectiveness for both teams and individuals 34
Demonstrate control It is essential to be in control of a project, and the solution being created, at all times and to be able to demonstrate that this is the case High-level plans, designs and standards outline the fundamentals of what needs to be achieved It is also vital to ensure transparency of all work being performed by the team. 35
The DSDM Process 36
The Management Products See Handbook Section 2. 7 37
The DSDM Team Roles q Business Interests q Solution/Technical Interests q Management Interests q Process Interests 38
Roles and Responsibilities One person can have more than 1 role A role can be shared between people All responsibilities must be covered Project roles – Manage – Direct – Co-ordinate Solution Development Team roles (SDT) – Shape and build the solution Supporting roles – Specialists, as appropriate – Provide ad-hoc assistance and guidance 39
Business Sponsor Most senior project level role – the Project Champion Committed to project and proposed solution Committed to the approach for delivering the project High enough in organisation to resolve business issues and make financial decisions Responsible for business case and project budget 40
Business Visionary Single person actively involved to provide a clear vision and strategic direction Interprets and communicates business needs of Sponsor and ensures these needs are represented in business case Ensures solution will enable business benefits 41
Technical Coordinator Technical authority for project, providing the technical vision Ensures project is technically coherent and meets agreed standards Provides “glue” that holds technical aspects of project together Advising on technical decisions and innovation 42
Project Manager Management Style: To provide high-level Agile-style leadership to Solution Development Team(s) To adopt facilitative style for managing empowered SDT Leaving detailed plan focuses on managing the working environment for evolving the solution Coordinates high-level management aspects of project Responsible for business and technical aspects 43
Business Ambassador Key business representative within Solution Development Team During Foundations Provides significant input into creation and prioritisation of requirements During Evolutionary Development Provides day-to-day detail Main decision-maker to ensure Evolving Solution is to meet business need fit-for-purpose Responsible for day-to-day communication between project and business 44
Business Advisor Often a peer of Business Ambassador Provides specific / specialist input to development or testing of solution May be intended user or beneficiary of solution or may provide legal or regulatory advice for compliance 45
Technical Advisor Provides specific / specialist technical input to the project Often advising from the perspective of those responsible for Operational management Operational support Ongoing maintenance of the solution 46
Solution Developer & Tester Solution Developer solution Interprets business requirements and translates them into a deployable Solution Tester Team 47 Empowered and fully integrated with the Solution Development Performs testing in accordance with agreed strategy
Team Leader Acts as servant-leader for Solution Development Team Leadership, rather than management Ensures team functions as a whole and meets objectives Works with team to plan and co-ordinate all aspects of product delivery at the detailed level Ideally elected by peers as best person to lead team through this stage of project Often fulfils another Solution Development Team role as well 48
Business Analyst Fully integrated with SDT Not an intermediary between Business Ambassador and team Supports communication between the business and the SDT Facilitates relationship between business and technical roles Ensures accurate, appropriate day-to-day decisions about the Evolving Solution Ensures business needs are properly analysed and correctly reflected in evolution of solution 49
Workshop Facilitator Responsible for planning, organising and managing workshop process Independent of workshop outcome Responsible for the context not the content 50
DSDM Coach Helps teams with limited experience to get most benefit from DSDM within context and constraints of their organization Needs to be an expert with real practical experience Preferably certified 51
End of Chapter 2 52
Chapter 3 The Agile Business Case Why do we need a Business Case? The Project Business Case Evolution Agile Business Case Content Agile Roles and the Business Case Agile Practices and the Business Case 53
Business Case Defines when and how benefits will be measured and should identify actions required during the project to support the delivery of those benefits. The Business Case needs to remain active and visible to both project-level and Solution Development Team roles throughout the project It also needs to embody sufficient flexibility to enable learning and accommodate a changing business environment Benchmark against which the success of the project is measured and is used at key points to justify whether the project should continue or be closed. 54
Business Case Content Where we are now 55
Business Case Content Business Vision Options Solution Overview Strategic Alignment Cost and Benefits Investment Appraisal Investment Risk Assessment Key Assumptions, Risks and Dependencies for the Project The Recommended Option / Proposed Solution 56
Roles Associated with the Business Case Business Sponsor Business Visionary Technical Coordinator Project Manager Agile BA 57
Business Case: Business Sponsor Responsible for the project budget and ensures that the project’s objectives are correctly aligned with strategic objectives. Approves the project’s Business Case 58 © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook.
Business Case: Business Visionary Overall responsibility for the benefits of the project being delivered Final arbiter for prioritisation of the requirements Provides guidance on where the best business value is to be found 59 © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook.
Business Case: Technical Coordinator Responsible for the technical aspects of the solution architecture Should be involved in the production of the Project Business Case Involved in scoping the solution alongside the Business Analyst and providing an initial vision for the architecture and increments of delivery for the product. 60 © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook.
Business Case: Project Manager Responsible for facilitating the planning of the project and its increments these are the high-level plans against which the costs within the Business Case are calculated. The PM is then responsible for facilitating activity to enable the project to deliver the solution, within the cost and risk parameters outlined. 61 © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook.
Business Case: Business Analyst Links expected benefits and business value with requirements Facilitate the prioritisation of the requirements by the business Provides guidance on how benefits will be measured 62 © Dynamic Systems Development Method Ltd. Reproduced from Agile. BA ® Agile Business Analysis Handbook.
Agile Practices and the Business Case Mo. SCo. W Modelling Facilitated Workshops Iterative Development Timeboxing Lean Canvas Product Vision Box 63
Business Canvas/Lean Canvas PROBLEM SOLUTION Top 3 problems your idea will solve Top 3 Features METRICS Key measures of the features UNIQUE VALUE PROPOSITION UNFAIR CUSTOMER ADVANTAGE SEGMENTS Single clear message why your product is different and worth buying What can’t be easily bought or copied about your idea CHANNELS The ways you get your product to customers COSTS REVENUE STREAMS Key elements of cost of production, marketing etc. Investment Appraisal – How does the ROI occur, when and how much? 64 Target customer groups
Product Vision Box 65
End of Chapter 3 66
Chapter 4 Stakeholders in the Agile Project What is a Stakeholder? Agile Culture and Stakeholder Engagement Project Stakeholder Agile Roles Stakeholder Analysis Techniques 67
Definition “A Stakeholder is an individual, or a group, with a stake or vested interest in the success or failure of an activity” 68
Three Stakeholder Categories Project Business External 69
Working with Project Stakeholders The Project-level Roles Business Sponsor, Business Visionary, Technical Coordinator and Project Manager The Solution Development Team Roles Business Ambassador, Team Leader, Solution Developers and Solution Testers The Supporting Roles Business Advisors, Technical Advisors, Facilitator and DSDM Coach 70
Business Sponsor The Business Sponsor assures the continued justification for the project, via the Business Case The Agile BA supports the Business Sponsor via business process modelling, value- chain mapping and Business Domain Modelling and facilitation skills The Business Sponsor will find they need to truly champion the Agile project, and be appropriately available and supportive to the Agile BA 71
Business Visionary The Business Visionary ensures appropriate requirements prioritisation and the delivery of business value The Agile BA supports the Business Sponsor via business process modelling, value-chain mapping and Business Domain Modelling and facilitation skills The Business Visionary will find that they are expected to participate regularly in the project, in many workshops, demonstrations and reviews and to make key decisions about priorities. 72
Technical Coordinator The Agile BA will work closely with the Technical Coordinator to turn the business requirements into solution requirements, both in Foundations and during Timeboxes The Technical Coordinator will work with the Agile BA to create and evolve the Solution Architecture Definition based on the business requirements During Feasibility and Foundations, prototypes may be built to indicate the vision of the future solution – this requires collaboration of the Agile BA and the Technical Coordinator 73
Project Manager The Project Manager and Agile BA work closely together to enable effective stakeholder analysis and engagement Project Manager is focused on managing the working environment to deliver on time and on budget The Agile BA’s main focus is on the enablement of business value 74
Business Ambassador Business Ambassadors are the empowered day-to-day representatives of a business area. In a DSDM team, they will find that they are expected to participate actively and regularly, as empowered members of the team The Agile BA support to the Business Ambassador(s) in the fulfilment of their responsibilities and facilitate communication within the Solution Development Team 75
Team Leader The Agile BA works with the Team Leader to facilitate the work of the Solution Development Team It may be that, in some Timeboxes, the Agile BA is a good choice for the role of Team Leader If the Agile BA is not the Team Leader, they will need to support the person who holds that role in maintaining the team’s focus on the business need 76
Solution Developers The Solution Developer works closely with the Agile BA, Business Ambassador and Solution Tester roles within the Solution Development Team Together they evolve the detail of the solution in line with the high-level requirements of the Prioritised Requirements List (PRL) established during Foundation 77
Solution Testers The Solution Tester is an active member of the Solution Development Team, working collaboratively with Solution Developer, Agile BA and Business Ambassador The Agile BA will work closely with the Solution Tester during Timeboxes, assisting them through the detailed requirements elicitation, analysis and validation activity as required The Solution Tester, Agile BA and Business Ambassador will work to establish clear Acceptance Criteria for the requirements 78
Business Advisors are not empowered members of the Solution Development Team, but will may be asked to give time to the Agile project They may be asked to provide specialist skills, knowledge and review from time to time, but are represented by a Business Ambassador for day-to-day input and decisions about the Evolving Solution 79 The Agile BA will liaise closely with the Business Visionary, Project Manager and Team Leader regarding the involvement of this wider stakeholder group
Technical Advisors are not empowered members of the Solution Development Team, but will may be asked to give time to the Agile project They may provide specific technical expertise, for example, or may represent the support of the product or service once it is in operation The Agile BA understands both the “As Is” and “To Be” situations, and can bridge the gap between the current systems and the new 80
Workshop Facilitator The Agile BA may cover the role of Facilitator some of the time For specific workshops, however, they will need to recognise that they are not the right person to facilitate as they have to contribute to in the content of the workshop, and another, independent, facilitator may be needed 81
DSDM Coach The DSDM Coach facilitates the project in the effective application of the DSDM Framework The Agile BA may be called on to assist the DSDM Coach in the coaching and education of stakeholders in the advantages and risks of Agile and in the expected ways of working within a DSDM project 82
The DSDM Team – Working Together 83
Agile Culture and Stakeholder Engagement 84 MORE LESS Transparency of process Physical documentation Frequent delivery Up-front analysis in detail Facilitated workshops Large unstructured meeting Face-to-face communication Detailed documentation
Stakeholder Analysis 85
Power / Interest Grid 86
End of Chapter 4 87
Chapter 5 Requirements and User Stories What is a Requirement? User Stories The Hierarchy of User Stories Requirements through the DSDM Lifecycle The Agile BA and the PRL 88
Requirements “a service, function or feature that someone needs” Requirements can also be constraints, business rules or other elements that must be present to meet the need of the intended users 89
Categories of Requirement 90
91
User Stories As a <user role> I need <requirement or feature> so that <goal/value> 92
Personas 93 Persona: Fiona Fresher Persona: Sam Skiver • 17 year old student • Lives locally with parents • Has a computer • Many friends • 18 year old student • Likes to drink beer • Plays computer games until late • Few friends
User Story – Story Card (Front) 94
User Story – Story Card (Back) 95
Well-Constructed User Stories - INVEST I ndependent N egotiable V aluable E stimable S mall T estable 96
Prioritised Requirements List (PRL) 97
A Hierarchy of User Stories 98
Story Maps 99
The Agile BA and the PRL Typically produces the PRL Maintains quality, completeness and consistency Requirements approved by the Business Visionary Facilitates sign-off, involving: Business Visionary Solution Development Team Other appropriate business stakeholders The Agile BA does not own the requirements - but they are the champion of the PRL 100
End of Chapter 5 101
Chapter 6 Prioritisation Prioritising using Mo. SCo. W Prioritising using KANO Model Effective Prioritisation 102
Eliciting Requirements Facilitate workshops Model building sessions Focus groups of end-users Prototyping sessions 103
Prioritising Requirements Many ways to prioritise : Assign numbers from 1 -5, 1 being most important, 5 least Assign High, Medium, Low categories Assign Showstopper, Highly Desirable, Desirable categories Have a list in priority order, with a cut-off line Mo. SCo. W prioritisation… 104
Mo. SCo. W M ust Have S hould Have C ould Have W on’t Have this time 105
KANO Model Three distinct types of customer need – Expected (which we shall refer to as “Will”) – Normal (things people just “Want”) – Exciters (which give the “Wow” factor) Two dimensions of Value – Reality – Perception 106
KANO Model 107
Effective Prioritisation Collaboration of appropriate stakeholders Reference to Business Case Baselined by the end of Foundation phase Reassessed as project progresses Not all Must Haves Escalation or decision-making process for issues Levels of empowerment 108
End of Chapter 6 109
Chapter 7 Stakeholders in the Agile Project When Should Facilitated Workshops be Used? Agile BA Role in Facilitated Workshops within the Project Workshop Roles Types of Workshops within an Agile Project 110
What is a Facilitated Workshop? Facilitated Workshops are a proven technique to ensure collaboration, rich communication and the achievement of results with speed, commitment and buy-in In a Facilitated Workshop, a neutral Facilitator is responsible for the structure and context of the event They guide a group through a process which enables them to work together effectively, to achieve an agreed goal 111
When to use a Facilitated Workshop Gather ideas Obtain decisions Extract information Agree requirements, priorities, dates Design aspects of a system Create a plan Obtain agreement Establish commitment Secure approval 112
Facilitated Workshops 113
Workshops Roles 114
Common Features of Facilitated Workshops 115
Facilitated Workshops - Associated Activities Plan the Workshop Prepare the Workshop Run the Workshop Document the Workshop Follow-up 116
The Agile BA and Facilitated Workshops Facilitation skill Cannot both facilitate and participate Focus on context rather than content Collaborate with the Facilitator to ensure there are: clear objectives clearly defined outcome 117
End of Chapter 7 118
Chapter 8 Modelling What is a Model? Target Audience for Models Modelling and Abstraction Modelling Perspectives Key Best Practice Modelling Techniques for the Agile BA Modelling and the DSDM Principles 119
What a Model is The diagrams, sketches, illustrations, built artefacts and prototypes, which make visible a situation we want to communicate to others They may show a current situation, a proposed option for change, or something that has been developed for future use 120
Modelling Perspectives 121
Modelling Perspectives 122
Modelling Techniques for the Agile BA Modelling Technique 1. Business Canvas / Lean Canvas Stakeholders, Goals 2. Business Domain Model (Class Diagram) Data, Business Rules 3. Business Process Diagrams (using Swim Lanes) 4. Context (Scoping) Diagram Scope of study or change 5. Customer Journey Mapping Events 6. Impact Mapping Benefit, Goal 7. Personas People 8. Product Vision Box Whole product 9. Rich Picture 10. Specification by Example 123 Main focus Process, Locations, Actors Any User Interface 11. Storyboards / Wireframes User Interface, Events 12. Use Cases Actors, Process 13. User Story Mapping Planning 14. Value Chain Mapping Process improvement
Business Domain Model (Class Diagram) 124
Business Process Diagram (Swim Lanes) 125
Context (Scoping) Diagram 126
Customer Journey Mapping 127
Impact Mapping 128
Rich Picture 129
Storyboards / Wireframes 130
Use Cases 131
Modelling and the DSDM Principles Focus on the Business Need Deliver on Time Collaborate Never Compromise Quality Build Incrementally from Firm Foundations Develop Iteratively Communicate Continuously and Clearly Demonstrate Control 132
End of Chapter 8 133
Chapter 9 Timeboxing and Iterative Development The DSDM Timebox Types of Timebox DSDM Structured Timeboxes – the wider context Agile BA’s Role in the Timebox Iterative Development Agile BA’s Role in Iterative Development 134
DSDM definition of a Timebox “a fixed period of time, at the end of which an objective has been met” 135
Types of Timebox DSDM Structured Timebox Free Format Timebox 136
Key steps in a DSDM Structured Timebox Sign-off what has been delivered. Assess impact of what has not been “done” Agree Timebox Scope and Mo. SCo. W priorities Investigate detail of work to be done 137 Work on the Solution in line with agreed Mo. SCo. W priorities Finish off, ensuring overall output of Timebox is fit for purpose
Timeboxing – The Daily Stand-up A key part of all Timeboxes Takes place same time, same place every day Solution Development Team share information to enable any day-to-day re-planning and reorganising Simple format - What I have done since the last stand-up to help achieve the Timebox objectives? What I will be doing until the next stand-up to help achieve the Timebox objectives? What problems, risks or issues (blockers) do I have that will prevent me or the team achieving the Timebox objectives? As a guide, allow 2 minutes person + 2 minutes 138
Team Board (Kanban) 139
Burn Down Chart 140
Timeboxing – The Wider Context Application of Timeboxing in conjunction with Mo. SCo. W prioritisation, ensures each Timebox delivers a fit-for-purpose product in the agreed timeframe As each Timebox delivers the relevant products on time, it becomes clear that the Project Increment is on track and thus the project as a whole is on track 141
Agile BA’s Role in a Timebox The Agile BA works particularly closely with the Solution Tester and Business Ambassador during Kick-off to clarify the Acceptance Criteria for the Timebox During the body of the Timebox the Agile BA works closely with the Business Ambassador, Solution Tester and Solution Developer to confirm the scope and objectives of the Timebox The Agile BA captures the expanding detail of the requirements as it emerges, documenting where necessary in the PRL The Agile BA works with the business roles to ensure business validation against the Acceptance Criteria 142
Iterative Development “the process by which the Evolving Solution, or a part of it, develops from a high-level concept to something with acknowledged business value within a Timebox” 143
Iterative Development Each cycle of the process is intended to bring the part of the solution being worked on closer to completion and is always a collaborative process – each cycle should be as short as possible, typically taking a day or two, with several cycles happening within a Timebox be only as formal as it needs to be involve the appropriate members of the Solution Development Team relevant to the work being done As Iterative Development proceeds, it is important to keep the agreed acceptance criteria in clear focus in order to ensure that the required quality is achieved 144
Quality in Iterative Development Quality Criteria – deal with required characteristics of a product or feature – define the characteristics of a product or service that determine whether it meets the express and implied requirements Acceptance Criteria – characteristics that define whether a product or service is sufficiently robust, secure, available etc. Validation – are we building the right thing Verification – are we building the thing right 145
Approaches to Iterative Development Solution Focus Horizontal Approach Vertical Approach Combined Approach 146
Solution Focus DSDM identifies that the solution may be considered to have a number of architectural layers The example used here relates to business system development but the concept can also be applied to a non-IT project, such as a marketing campaign 147
Horizontal Approach The horizontal approach considers the solution layer by layer with each Timebox incrementally delivering increased complexity of business process or layers of complexity/completeness as regards technology The advantage of the horizontal approach is that it allows an initial sight of the full breadth of the solution very early on The disadvantage is that nothing works fully until the last horizontal slice is delivered – no business benefit can accrue until that point 148
Vertical Approach The vertical approach slices through multiple layers of the solution with each Timebox delivering one or more fully functional features The advantage of the vertical approach is that delivery of prioritised features may enable Solution Increments to be more quickly and frequently deployed into live use The disadvantage is that the full breadth of the solution is not clear until late in the project 149
Combined Approach The combined approach starts by focusing one or two Timeboxes on (thin) horizontal slices of the solution in order to fully understand the breadth of the solution before reverting to a vertical approach to incrementally deliver fully functional features The advantages of the combined approach are that there is an initial view of the overall solution early in the project, and incremental delivery of business value into live use is also achieved There are no obvious disadvantages 150
Agile BA’s Role in Iterative Development Helps define prototypes, mock-ups, personas, scenarios, etc. May facilitate review sessions and/or “Show and Tell” sessions – the Agile BA must be aware of stakeholders experience and expectations Facilitates conversations between the different disciplines within the Solution Development Team Liaises with the Release Management Team and/or Operations Team – to ease the transition of the developed, tested solution into the business-asusual world 151
End of Chapter 9 152
Chapter 10 Requirements Planning and Estimating Throughout the Lifecycle Requirements Planning Through the Lifecycle Prioritised Requirements List Estimating within a DSDM Project 153
Requirements Planning The Agile BA works throughout the project to evolve the requirements from an initial idea to a detailed level The Agile approach is to agree requirements at a high level early in the project, along with high-level acceptance criteria – and then to further analyse them to provide just enough detail, just in time, throughout the project The Agile BA is the guardian of the requirements throughout the project, but not the owner. 154
Requirements Planning Through the Lifecycle 155
Feasibility The TOR from Pre-Project triggers the start of Feasibility – This is the first statement of any kind of requirement The Agile BA will work with the project-level roles and a wider group of stakeholders, as necessary, to – clarify the project vision embodied by the TOR, formulate the objectives and very high- level acceptance criteria – develop solution options and an outline Business Case Themes and Epics begin to emerge and an initial Story Map may be created, as an early roadmap for the project 156
Foundations The Agile BA will be instrumental in the clarification and dissemination of the project vision, objectives and acceptance criteria and in the evolution of the Business Case for the project During Foundations, the Agile BA needs to bring together the PRL, at a level of detail which is just sufficient to allow estimating for the Timeboxes Agile BA will collaborate with the project-level and Solution Development Team roles to influence the emergence of plans that are practicable from a business and implementation point of view 157
Requirements During Timeboxes The work planned for a Timebox should ideally be a small, usable subset of business functionality At the start of the Timebox, the selected features from the PRL which have been allocated to the Timebox need to be further analysed The order of work within a Timebox should be driven by the business objective for the increment and for the Timebox In order to ensure that a Timebox will finish on time, there has to be a level of flexibility in the deliverables it must achieve – Mo. SCo. W 158
Prioritised Requirements List (PRL) The PRL is first created at a very high level during Feasibility Refined during Foundations Persists through the project as the central repository for scope, prioritisation and detail The exact format of a PRL will depend upon the type of project and the organisation sponsoring it 159
Prioritised Requirements List (PRL) 160
Estimating within a DSDM Project Estimates need to be realistic and cover the risk associated with unknown factors Estimates should only be as precise and accurate as is necessary for their purpose at a given point in the lifecycle The people who will do the work, should carry out the estimating Estimates are expected to be revalidated throughout the project as the understanding of the requirements deepens and as the Solution Development Team’s actual delivery speed (velocity) is clarified 161
Estimating within a DSDM Project The difference in estimating within a DSDM project – contingency is managed within the Mo. SCo. W prioritisation of features – a key role for the Agile BA is to analyse and make visible the Mo. SCo. W priorities 162
Estimates and Requirements Detail 163
Planning Poker Planning Poker, an Agile estimating and planning technique popularised by Mike Cohn. It is a consensus based approach to estimating, using relative estimates to size User Stories against each other Each participant has a deck of Planning Poker cards with values in a series close to the Fibonacci series: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 The values can be used to represent story points (a relative measure), ideal days, or other units agreed by the team who are making the estimates. 164
Planning Poker When a feature has been discussed, the participants make their individual estimate of the size of the work involved All estimates are revealed simultaneously and any significant differences (typically the highest and the lowest estimates) are discussed The process is repeated until consensus is achieved or until the feature is put aside pending additional information 165
Estimating Workshop One of the best ways of estimating during Foundations, and again at Timebox level, is to hold Estimating Workshops using Planning Poker During this Workshop, the requirements need to be clearly understood and presented Whilst the Agile BA may be able to facilitate such a Workshop, it is more likely that their role as a participant is more important, inputting to the content of requirements detail – therefore a more independent facilitator should be considered 166
End of Chapter 10 167
Chapter 11 The Requirements Lifecycle in an Agile Project The Role of the Agile BA in Handling Requirements The Lifecycle of a Requirements within the Agile Project Lifecycle 168
Agile Approach to Requirements The Agile approach to requirements is to clarify the project objective and Business Case and then to define requirements, at a high level only, early in the project The definition of detailed requirements is deliberately left until just before it is needed; just before that particular aspect of the solution is developed and built 169
The Role of the Agile BA The role of the Agile BA is to be the guardian and champion of the requirements They do not “own” the requirements – it is important that “ownership” is accepted by the business representatives (Business Visionary and Business Ambassador) However, the management of a clear, useful and incrementally-evolving requirements set is the responsibility of the Agile BA 170
The Lifecycle of a Requirement 171
Elicitation Face-to-face conversations Observation Facilitated Workshops Demonstrations of working elements of the solution Scenarios Modelling and Prototyping 172
Analysis Realistic Unambiguous – clear enough to be understood by different stakeholders Feasible – technically, financially and socially Congruent – with the business goals Relevant – to the objectives of this project 173
Validation Applies to both the individual requirement and to the whole set of requirements for the increment and for the project Requirements must also be testable The Agile BA will ensure measurable acceptance criteria for each requirement are agreed with stakeholders 174
Documentation To pass a message from one person/set of people to another To record information now, whilst we know it, for later when we may have forgotten it To help manage complexity To prove something has been done 175
Management Once a requirement has been identified, its inclusion within the final product or its de -scoping should be traceable This enables the stakeholders of the project to understand what is, and is not, contained within the final solution It helps to prevent requirements being missed by accident or new requirements being brought into the project without consideration of their impact 176
Requirements in the DSDM Process 177
End of Chapter 11 178
Chapter 12 Making the Transition to Agile BA Why are we changing? 179
Transitioning to Agile Business Analysis Deliver change faster or benefits earlier Be more responsive to change in the external or internal environment Stay on time and in budget with business change Deliver reliably what the business really needs Understand the overall implications of change for the business in a fast moving environment 180
Balance Between Approaches 181
Course Review and Close 182
- Slides: 182