Agileba Handbook 5 8qYBzy2

This eBook was purchased by:
Name: Karolina Jurowicz

Email: gladczak.k@gmail.com
on 01/05/2022 10:06 UTC.
EditionMark Powered by EditionGuard.com

AgileBA®
Handbook
11
1 1
AgileBA Handbook
Disclaimer
This handbook, Agile Business Analysis, is intended for use as an aid to those undertaking APMG-International’s
accredited Agile Business Analysis training or revising for personal certification in Agile Business Analysis. he
guidance is presented within the fra ework of , an approach which defines the role of the project based
Business Analyst, in relation to business, develop ent and testing roles at all levels. owever, the guidance is wider
than this, with many generic and popular Agile techniques also included, where useful and appropriate to the
Business Analyst.
ote Agile Business Analysis training and Agile Business Analysis personal certification is accredited by A
nternational. nly accredited training providers or their affiliates are allowed to provide courses and e a inations
in A nternational s ualification sche es. eaders wishing to know ore about A nternational are
invited to visit the website at www.ap g international.co
©2015 Dynamic Systems Development Method Limited
onsortiu egistered ffice enwood ouse, enwood, Ashford, ent 24 8 ,
® ® ® ®
DSDM , Atern , AgilePM and AgileBA are registered trademarks of Dynamic Systems Development Method
i ited in the nited ingdo and other countries. Agile g is a trade ark of yna ic yste s evelop ent
ethod i ited.
eaders wishing to know ore about or use the Agile roject Fra ework are invited to visit the website
at www.dsd .org nly organisations accredited by the onsortiu ay offer accredited products
and services.
2® is a egistered rade ark of A i ited in the nited ingdo and other countries
ITIL is a egistered rade
®
ark of A i ited in the nited ingdo and other countries
All rights reserved. o part of the publication ay be reproduced, stored in a retrieval syste or trans itted in
any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written
per ission of the onsortiu . Applications to reuse, reproduce or republish aterial in this publication
should be sent to the address above, or by e ail to info dsd .org
Published by the DSDM Consortium
First published ay 2 15
B 978 9928727 8 6
rinted in the nited ingdo by Buckland edia roup i ited, www.buckland.co.uk
Acknowledgements
In the spirit of Agile collaboration, the development of this handbook has been enhanced by the involvement of a
wide range of individuals, so e with in depth business analysis e perience, so e with solid Agile e perience and
so e with both.
We would especially like to thank the following people for their continued input, reviews, feedback and interest:
Lead Author: Dot Tudor (TCC Ltd)
Key Contributors: Frank oe (BCS/Independent), Maria Weglowski (Mundipharma IT Services),
Charlotte Walters (Allianz), Gary Auger (GACS Ltd)
Reviewers: Stephen Ash (OOTAC), Judith Clark et ffice , Julia Godwin (Be Consulting), Barbara
oberts (DSDM), Victor Page (Time Shakers Ltd), Samantha Day (Bard Pharmaceuticals Ltd), eena watra (AXA
Insurance), obert hipley (TCC Ltd), Lynn Jackson (LJ Training), Andrew Craddock (nlighten), Steve Messenger
(DSDM), ate Blackall (APMG), Jennifer Stapleton (DSDM/Independent), en e d ener (ebg consulting),
Phran Ryder (Lloyds Banking Group)
Thanks also to: udith Foster (TCC Ltd)
Production: ily uf e (DSDM), i Whit ore (DSDM), ary enson (DSDM), Matt Newble (Newble Designs)
2
Contents
ntroduction to the AgileBA andbook 5
Chapter 1 he ole of the Business Analyst, in an Agile World 9
Chapter 2 Agile Funda entals and the Agile BA 21
Chapter 3 The Agile Business Case 39
Chapter 4 takeholders in the Agile roject 49
Chapter 5 e uire ents and ser tories 61
Chapter 6 rioritisation 79
Chapter 7 Workshops 89
Chapter 8 odelling 99
Chapter 9 i ebo ing and terative evelop ent 125
Chapter 1 e uire ents lanning and sti ating hroughout the ifecycle 139
Chapter 11 he e uire ents ifecycle in an Agile roject 149
Chapter 12 Making the Transition to Agile BA 159
Appendi A lossary 167
Appendi B odelling echni ues and where they are useful in the
DSDM Lifecycle 179
Appendi roject Approach uestionnaire A 181
Appendi o e ypical Agile Facilitated Workshops 183
Appendi Bibliography 191
Appendi F nde 197
AgileBA Handbook
4
Introduction to the
AgileBA Handbook
51
1 1
Introduction to the AgileBA Handbook
AgileBA Handbook
Foreword
Introduction to the AgileBA Handbook
Background
Why did we decide to write this andbook he answers can be found in the growing body of evidence that an
Agile approach is an effective way of working in projects. ts key features are
• The collaborative working and involvement of people with the right skills, including those of the customer and
end-users of the product we are producing
• An incremental approach, delivering value early and regularly
• The acceptance that we cannot know all of the detail at the outset, and that we will inevitably learn more as
work progresses
• he definition of fine detail only just before we need it, to avoid the waste of trying to predict the detail too
early
• The empowerment of people at the right levels, to make decisions on detail
ntroducing an Agile approach has a significant i pact on the role of the Business Analyst, on their e isting skills
and their way of working. heir traditional skills are still valuable, but new skills and ways of working need to be
adopted to harness the benefits of a new way of working and to appreciate the different relationships with co
workers.
Agile is here to stay. he Agile way of working has rapidly gained recognition since the publication of the original
Agile anifesto and its supporting rinciples in 2 1. his is for very good reasons. eeting business objectives in
ter s of ti e, budget, scope and uality and gaining the best value for oney fro business change projects have
beco e increasingly ore i portant. hese factors in uence whether or not the organisation can be co petitive
with others in their arket. Agile is not one ethod, but a fa ily of approaches with co on core values. For
organisations to achieve success with Agile, the entire cross functional project tea ust e brace the Agile values
and practices. n fact, the culture in which Agile thrives will in uence the whole organisation.
It is against this background that the desire arose to provide a clear and helpful reference to support Business
Analysts, especially those working in an Agile project world.
The Purpose of This Book
he andbook is intended to give useful, practical and co prehensive guidance on the role of the Business Analyst
working in an Agile way the Agile BA . t also ai s to give conte t to the Business Analyst role beyond the
individual project, in relation to organisational ission and strategy, and to give additional depth and guidance for
the Business Analyst role.
he guidance is presented within the fra ework of , an approach which defines the role of the project
based Business Analyst, in relation to business, develop ent and testing roles at all levels. owever, the guidance is
wider than this, with many generic and popular Agile techniques also included, where useful and appropriate to the
Business Analyst.
Why read this book?
he uestion is often asked why there is no specific Business Analyst role in Agile develop ent approaches such as
cru or anban.
The answer to this of course depends on what people regard the Business Analyst’s role to be:
• A discipline which focuses purely on re uire ents specification within a project
or
• a wider, more holistic approach incorporating process improvement, organisational change, strategic alignment
and benefits anage ent.
6
n a cru environ ent it is so eti es argued that the roduct wner the key custo er business
representative handles the wider business and strategic considerations. owever, they ay not have the skills, tools,
techni ues or position within the organisation to be able to do this effectively. he perspective of the Business
Analyst is a unique combination of being able to see the “top to bottom” view of the organisation’s, from mission
objectives and strategy down to the tactical level and to analyse the end to end perspective, fro supplier to
custo er, and the value chains of the organisation s processes . hey also have the perspective to see the here
and now” or “As Is” situation and to use their skills and techniques to both envision, and facilitate others to see, the
future situation, the o Be .
his i portant focus helps to preserve progress in line with the overall business direction, when an Agile project
will be delivering value incre entally, with detailed re uire ents e erging over ti e.
his andbook ai s to show the areas where the Agile BA can provide support for both the develop ent
tea and the wider organisation. t gives the Agile BA a fra ework within which to operate and clarifies their
responsibilities in the Agile roject. t also describes the key techni ues used by an Agile BA during an Agile project.
How to use this book
his book aug ents the guidance given in the Agile roject Fra ework andbook. ts chapters can be
referred to both as an overall reference across the whole project lifecycle and also as stand alone subjects that the
Agile BA can access on an as needed basis.
he chapters take the Business Analyst on a journey fro their initial strategic conte t in relation to an Agile
project, through the funda entals of the Agile way of working. We use as the fra ework for this journey,
but introduce a wide variety of additional techniques from the broader Agile world that are appropriate to
the Business Analyst. We progress to describing a series of practices and ways of working to support the Agile
approach to producing business solutions. he final chapter covers the vital area of ransitioning to being an Agile
BA . t helps the Business Analyst to assess where they are now in their role and how to ake the ove to an
Agile approach.
Full details of the ethod and guidance referred to earlier can be gained fro the Agile roject
Fra ework andbook
Final Thoughts
his andbook provides the eans for a Business Analyst to gain a greater breadth and depth of understanding of
business analysis techniques suitable for use within an organisation which is using an Agile approach to introducing
business change. t will help Business Analysts to understand the difference of working with others in an Agile way
and help the to blend their skills with those of others in the Agile olution evelop ent ea .
The Business Analyst is crucial to the success and competitiveness of organisations in today’s rapidly-changing
environ ent, enabling the ti ely delivery of high value, cost effective solutions. As our project world continues to
change, the BA role will continue to be an evolutionary role e bracing Agile is a part of this evolution.
7
AgileBA Handbook
8
1. The Role of the
Business Analyst,
in an Agile
World
91
1 1
The Role of the Business Analyst, in an Agile World
AgileBA Handbook
1.1 Introduction
Business analysis skills help an organisation to achieve its business goals by the analysis of the organisation’s needs
and the align ent of business projects to these needs. he ways of working of an Agile BA are so ewhat different
fro those of a ore traditional business analyst. his chapter sets out to su arise the conte t of an Agile BA s
activities in relation to business needs and the strategies of the organisation in which a business project e ists. t
also highlights some of the best practice techniques that can help the Agile BA support the organisation in the
for ulation and reviewing of its strategies. ven if the project level Agile BA is not directly involved in defining the
organisation’s strategies, they need to understand the way strategy is formulated and the factors and forces which
affect it. his will give the the perspective to ensure that the projects they are involved in have objectives that
align with, and support, the organisation s strategic goals.
The techniques considered below are typical of business analysis best practice, whether or not this is in an Agile
conte t. his chapter does not e plain the techni ues in detail. ather, the ai is to give an appreciation of the
areas addressed by each technique and to consider how, together, they can provide an understanding of the
longer ter direction of an organisation, which will infor the Agile project and help it to stay on track, in a rapidly
changing environ ent.
1.2 The Holistic View of the Business

The Business Analyst’s role is to study the overall business and information needs of an organisation, in order to
facilitate solutions to business proble s. his ay involve
• Strategic analysis, modelling strategic themes and drivers
• Business capability odelling odelling what the business does conceptual activity odels , as opposed to
how it does it physical process odels
• rocess and value strea value chain apping
• Skills and competency mapping
• rocess re definition re engineering
• ata definition and events identification
• Liaison between different business and technical disciplines
• e uire ents engineering
• iscovery and definition of cost effective, valuable solutions to business needs
Business analysis operates fro the top level of the organisation, dealing with the ision, ission, bjectives and
Strategy, right through to the tactical level where programmes of work are set up to address strategy and where
solution develop ent projects often reside.
At the higher level, the Business Analyst is a business architect, defining and odelling what the business will do
strategically. igh level organisational odels allow robust and coherent business architecture to be defined, with
clear objectives and easures. his will then support tactical decisions of how the objectives are to be achieved at
progra e and project level.
10
Top to Bottom Analysis within an Organisation
Mission, Business
Corporate Analyst(s)
Objectives
Business
Programme Strategy Analyst(s)
Business
Project Tactics Analyst(s)
Figure 1a: Top to bottom analysis within an organisation
1.2.1 Organisation, people, process, technology

At both a strategic level and a project level, the Agile BA needs to aintain a holistic view of business syste s.
his is especially i portant in an Agile project, where the delivery of change is incre ental, but a coherent overall
change ust e erge fro these separate incre ents. he Agile BA ust understand the big picture , the end
to end process and its value chain. he Agile BA will also understand and odel the structure of the business
organisation into which the project will deliver.
The holistic view consists of:
• rganisation
structure including opportunities and li itations inherent in the organisation type, e.g. non profit,
public sector etc.
- roles and responsibilities
e tent of cross functional working hierarchical and atri organisational structures
- management style and approach
- compliance and legal constraints
• People
- skills
- motivators
e perience
- training and development
understanding of business objectives
- culture and leadership styles
• Process
perfor ance achieved through well defined, well understood, well supported processes
• Technology
nfrastructure provides support for, and i prove ent of, business processes across the organisation
and people perspectives
his backdrop to the broader aspects of business analysis, results in technology being seen as just one of the any
factors in the provision and evolution of effective business operations. his is despite technology s all pervading
presence in today s organisations.
11
AgileBA Handbook
Organisation
People
Process Technology
Figure 1b: The holistic view of a business
1.3 Understanding the Business Environment

The Agile BA needs to build an understanding of the organisation in which they are working, from two viewpoints:
• he outside world and arkets, within which an organisation operates e ternal analysis
• he organisation s inherent internal strengths and weaknesses and current business strategy internal analysis
Below are a few of the techniques which can be used in each of these types of analysis and the differences that
arise when taking an Agile view of these.
1.3.1 External analysis
here are e ternal in uences on all organisations they are part of the world and arket situations in which the
organisation e ists and operates. hese are nor ally outside the organisation s control and the organisation ay,
therefore, have little or no power to change the . owever, by understanding the , the Agile BA is able to see
where changes are likely to co e fro that could i pact a project, and where opportunities ay e erge that can
be taken advantage of by reprioritising work within the project.
Below, we highlight a nu ber of techni ues for understanding the e ternal and arket in uences on the
organisation and identifying any inherent e ternal opportunities and threats.
12
Porter’s
PESTLE 5 Forces
MOST
Resource
Audit TOWS
te
In
rn SWOT
al
Figure 1c: External/internal analysis
PESTLE
his analyses the factors affecting the organisation fro the olitical, cono ic, ocio cultural, echnological,
egal, and nviron ental perspectives.
n, for e a ple, a dyna ic political situation, it ay be possible for the Business Analyst to foresee the likelihood
of ta ation changes olitical . n an cono ic recovery, it ay be co petitively advantageous to reco end
a more automated, rather than labour-intensive, model of technological support in order to be able to scale up
uickly to handle increasing de and.
Porter’s Five Forces Analysis
his identifies the co petitive forces within the organisation s arketplace by analysing five key co petitive
factors uppliers, Buyers consu ers , o petitors, ew ntrants and ubstitute roducts.
For e a ple, the prioritisation of e tending technological support to custo ers and suppliers ay produce
a barrier to entry for other organisations wishing to enter the organisation s arket. An Agile approach could
deliver the prioritised features of support ore uickly.
he Agile approach to projects should ake the changing e ternal environ ent easier to react to in a short
ti efra e, by prioritising and reprioritising as the environ ent changes.
ne of the key drivers for the birth of Agile, fro the early atte pts at apid Application evelop ent A ,
was this kind of co petitive environ ent. A gained a good reputation for delivering change uickly, but this was
under ined by the develop ents which were so eti es of low uality and or not aintainable. he whole fa ily
of Agile approaches which have e erged since these early days hapter 2 strives to deliver business value early.
DSDM in particular gives guidance which will allow the organisation to achieve valuable change on time, within
budget and preserve the uality of what is delivered.
13
AgileBA Handbook
1.3.2 Internal analysis

nternal analysis co ple ents the e ternal view of the world. t provides an inside out perspective on the
current strategy and capabilities of the organisation.
Below are a number of techniques for understanding the organisation’s current business strategy and identifying any
inherent internal strengths and weaknesses, whilst linking these to e ternal opportunities and threats.
MOST analysis
This stands for Mission, Objectives, Strategy, Tactics
• Mission - what the organisation is about, what it is seeking to achieve
• Objectives goals against which the organisation s achieve ents can be easured, through the definition and
use of ritical uccess Factors and ey erfor ance ndicators and targets
• Strategy he approach the organisation will adopt to achieving its ission and objectives
• Tactics he detailed ways in which the strategy will be i ple ented. he actics co ponent of
is where the projects are identified and initiated. t is where the Agile BA begins the task of ensuring that
overall align ent with the strategy and objectives is aintained fro re roject through to eploy ent and
Benefits Assess ent
Resource Audit
This is a means of identifying and assessing the current capabilities of the organisation across a number of
interrelated areas as follows:
• hysical resources e.g. buildings
• Financial resources e.g. assets
• u an resources e.g. skills, e ibility
• now ow e.g. patents, e ploitation of technology
• eputation e.g. Brand recognition
his analysis identifies the organisation s strengths and weaknesses and can provide input into the ne t techni ue
of W analysis.
1.3.3 Other techniques
SWOT Analysis
his is a si ple but powerful eans of pulling together key findings fro the e ternal and internal analyses. t is
a su ary of the organisation s current strategic position.
• Strengths within the organisation that can be built upon
• Weaknesses within the organisation that require action
• Opportunities that could be e ploited by the organisation
• Threats that may be presented to the organisation
he W Analysis can also be broken down into e ternal and internal environ ent, with the pportunities
and hreats being e ternal and trengths and Weaknesses being internal.
TOWS Analysis
his is a potential ne t step on fro a W analysis that could be used to identify the actions options needed
to pursue to help turn the state ents ade in a W analysis into action.
SO trategies that use the trengths to a i ise pportunities
ST - Strategies that use Strengths to minimise Threats
WO trategies that ini ise Weaknesses by taking advantage of pportunities
WT - Strategies that minimise Weaknesses and avoid Threats
14
1.4 The Value Chain and Lean Thinking
The previous range of analyses should provide a clear picture of what value is being created by the organisation’s
activities and processes and where such value is being created. his view can be both inwardly and outwardly
custo er focussed.
1.4.1 Value chain and value stream analysis
he idea of value chain analysis was proposed by ichael orter 198 . A value chain breaks an organisation
down into its strategically valuable activities in order to understand the costs and sources of product and service
differentiation. he organisation can then ai to gain co petitive advantage by perfor ing these strategic activities
ore cheaply or better than its rivals.
Firm Infrastructure
Human Resource Management
Technology Development
Margin
Procurement
Outbound Logistics
Marketing & Sales

Inbound Logistics
Operations
Service
Support Activities Primary Activates Gross Sales
Figure 1d: Porter's value chain
A linked concept is the value stream, which is an end-to-end collection of activities that creates value for a
custo er. his concept is found in lean anufacturing.
he Agile BA s thinking needs to enco pass the notion of a value chain and value strea s to ensure that project
re uire ents and the approach to deploying project incre ents are adding defined and agreed value and have a
direct link to the organisation s strategy and objectives.
1.4.2 Lean thinking
ean thinking links closely to the concept of delivering value. t is based on theory and practice developed for
anufacturing and e phasises the re oval of waste. Waste, often called uda a apanese ter refers to
everything which is not of value to the custo er internal and e ternal . he ter uda entered the Agile
vocabulary fro the lean values ade fa ous by the oyota roduction yste s. he ean approach advocates the
following five principles
• Specify what creates value from a customer’s perspective
• Identify all steps across the whole value chain
• ake those actions happen that create the value ow
• ake what is pulled de anded or triggered by the custo er happen just in ti e
• Strive for perfection by continually removing successive layers of waste
Waste needs to be considered as new processes are introduced, to avoid replacing one cause of waste with
another.
15
AgileBA Handbook
1.5 Implementing the Organisation’s Strategy

ple enting strategy involves change. his ay be subtle, or ay re uire ajor change progra es, with large
budgets, the involve ent of any people and depart ents and a protracted ti espan. he Agile BA needs to
consider the i pact on an organisation of those changes brought about by the project.
Two techniques highlighted below provide a wider picture of the elements involved and address how to measure
the success of i ple enting change.
Structure
Shared
System
Values
McKinsey
7S Model
Strategy Style
Skills Staff
Figure 1e: McKinsey 7S model
McKinsey 7S Model
his odel proposes that organisations are subject to seven interrelated aspects. All seven need to be considered
together. f one changes it will affect all the others. he seven aspects are
• Structure
• System
• Style
• Staff
• Skills
• Strategy
• Shared Value
16
The Balanced Business Scorecard
Objectives
Measures
Initiatives
Financial
Targets
“To succeed financially,
how should we appear
to our shareholders?”
Objectives
Objectives
Measures
Measures
Initiatives
Initiatives
Customer Internal Business
Targets
Targets
Processes
“To achieve our vision,
how should we appear Vision and “To satisfy our share-
to our customers?” Strategy holders and customers,
what business
processes must we
excel at?”
Objectives
Measures
Initiatives
Learning and
Targets
Growth
“To achieve our vision, A measurement

how will we sustain our and management
ability to change and
improve?”
approach
Figure 1f: Balanced business scorecard
he Balanced Business corecard provides a fra ework for easuring the success of the change. his approach
can be used to identify ritical uccess Factors and to set appropriate ey erfor ance ndicators and targets .
ts strength is that it considers not only the financial aspects of an organisation s success, but other factors too. he
scorecard is ade up of five parts
• Vision and Strategy
• Finance
• Customer
• Learning and Growth
• Internal Business Processes
t can be used to show the state of i ple enting the current strategy to date and its effectiveness. his for s the
basis for the organisation s business intelligence, analytics and anage ent infor ation syste s.
17
AgileBA Handbook
1.6 Change Projects

he Agile BA needs to ensure that the delivery of the project s solution, both by incre ents and in total, fully
takes the i pact of change into account. t will involve collaboration with the project s business representatives at
all levels. herefore, change anage ent needs to be included in the project s overall plan and the plans for each
incre ent.
he focus, as with other areas, is to adopt a holistic approach to change anage ent. Below are so e of the core
characteristics to consider when planning and i ple enting change.
1.6.1 Culture
There are various approaches to identifying, studying and categorising the culture of an organisation, including:
• ategories of feedback and reward eal and ennedy
• ulture in relation to organisational structure harles andy
• Five di ensions of aspects of national in uence ofstede
• he cultural web ohnson and choles
Agile affects culture, and will in uence and pervade the organisation around it. Aspects of Agile culture are
e bodied in the anifesto for Agile oftware evelop ent Agile anifesto and s 8 rinciples hapter
2 . Agile re uires the organisation to e brace the e power ent of individuals within the olution evelop ent
ea s s . t re uires the active involve ent of the business roles within projects, fro beginning to end. t
works best when resources are dedicated to projects as a stable tea . t needs business roles to accept that by
prioritisation, while they may not get everything they ask for, they will have increased control and choice over what
is developed. t needs anage ent to beco e co fortable with less detailed plans and less detailed re uire ents
specification early in the project, in e change for greater e ibility during the project. t re uires trust fro
management to allow the Solution Development Teams to make day-to-day decisions, and courage from the teams
to actively take on their decision aking role.
1.6.2 Communication
o unication is key to all parts of change anage ent and should be specifically planned for. he plan should
cover the following:
• Who needs to be communicated with
• ow they ay feel about the change if known, i.e. do they support the change if not, why not
• What they need to know
• What they will want to know
• What is to be communicated
• Why the message is important
• Who the messenger is
• ow the essage is going to be delivered
• When the message will be delivered
he Agile approach to co unication is very different fro that in a traditional, waterfall project, and is the subject
of any of the practices described in later chapters. o unication is at the heart of the principles of
and of the Agile anifesto too hapter 2 . Face to face co unication is the ost powerful, but ay not always
be possible. o unication tools that allow dialogue, visual contact for e a ple, video conferencing , and the
sharing of docu ents, screens and other artefacts are enabled by internet contact worldwide. owever, another
core value of the Agile world is to value individuals and interactions over processes and tools. he Agile BA should
keep this fir ly in ind when looking to facilitate co unication of any kind.
18
1.6.3 Collaboration
he analysis of stakeholders is key to any change initiative, and no less so in Agile. uch techni ues as a ower
nterest rid for stakeholder analysis hapter 4 will help to identify the level of involve ent appropriate to
each stakeholder or stakeholder group. Additionally, Agile re uires deeper collaboration and a different pattern of
involve ent fro stakeholders within the Agile project.
1.7 Conclusions
While perhaps only those BAs at a senior level will be directly involved in supporting and reviewing an
organisation s strategy, alongside depart ent divisional anage ent, it is i portant that all BAs Agile or not have
an understanding of the ele ents that have gone into the current strategy definition, internal and e ternal. his
knowledge and understanding provides the fra ework in which the internal initiatives and projects are identified,
developed and delivered. t infor s the prioritisation of work and the se uence in which ele ents of the evolving
solution are developed and deployed. As will be seen in the chapters which follow, the Agile BA has a role within
the project, at both governance and solution develop ent levels. An understanding of organisational strategy and
internal and e ternal forces will enable the Agile BA to work alongside the business representatives within the
project, to identify where the greatest value is likely to be gained and to spot opportunities for i prove ent and
the re oval of waste.
ence the Agile BA, by working alongside the business representatives on a project, can ensure that the project s
objectives, business case, re uire ents, develop ent and deploy ent are always aligned with the objectives and
strategy of the organisation. Further ore, the Agile BA will ake certain that the i pact of change is an integral
part of the project s planning and that they, and their colleagues, are able to assess, anage and onitor that
change.
19
AgileBA Handbook
20
2. Agile
Fundamentals and
the Agile BA
211
1 1
Agile Fundamentals and the Agile BA
AgileBA Handbook
Overview
n this chapter, we look at the origins of Agile in the Agile anifesto and e plore the funda entals of .
is the Agile fra ework upon which we structure the advice, guidance and role definitions within this
andbook. Whilst all Agile approaches have very si ilar core values, principles and practices, is the only
Agile approach which clearly defines the role of the Agile BA. t identifies their responsibilities and skills, and sets
their involve ent in the conte t of the other roles within a project. hroughout this andbook, however, we will
also draw ideas, practices, techni ues and guidance fro the wider Agile fa ily, where this is helpful to the Agile BA.
his andbook should, therefore, prove useful even to those Business Analysts who find the selves working in an
Agile environ ent which follows a different Agile approach.
2.1 Choosing DSDM as your Agile approach

2.1.1 RAD and Agile - how it all started
When was created in 1994, the world of solution delivery through projects was very different fro that
of today. For e a ple, the corporate world predo inantly used a traditional, se uential Waterfall approach for
their projects. Far too any of these projects were failing, for a variety of reasons, but ainly because projects
were just too big and too long, co unication and business engage ent were poor and progress was easured in
percentages co plete, rather than delivery of business value. When projects did deliver, they often delivered late,
over budget, and fre uently delivered the wrong thing. his was due to reliance on specifications which tried, and
usually failed, to capture and fi detailed re uire ents right at the start, coupled with the use of a process in which
the identification and anage ent of change was difficult.
o counter these proble s, so e projects had tried a co pletely different approach apid Application
evelop ent A with users of the solution working closely with developers to iteratively and incre entally
build software applications, not based on a for alised specification, but on discussions, de onstrations and short
feedback loops This addressed many of the problems of the traditional approach but, in doing so, it introduced a
whole new set of proble s, particularly around the supportability and scalability of the solutions. A provided
uick fi es but often its application adversely affected the uality of the solutions because the disciplines of analysis
and design were thrown out with the up front phases that used to contain the .
At that ti e, was launched to address the proble s of the traditional approach too slow, too big, not
transparent enough, not enough ongoing business involve ent as well as the proble s introduced by A focus
only on speed and uick fi es, no focus on uality, no view of the big picture issues either fro the business or
the technical perspective . achieved this by recognising that both approaches had strengths and areas for
i prove ent, and that being effective in all environ ents re uires the ability to deal with wider conte t issues as
well as the here and now. o brought together the best parts fro a traditional approach control and
uality and fro A good co unication, business involve ent, transparency .
2.1.2 DSDM, Agile and the Agile Alliance
ver since its launch, has been at the forefront of scalable Agile projects and solution delivery. t is e ually
effective on s all straightforward solutions or large co ple corporate projects. has been used effectively
on non solutions and is not just about develop ent of software. t is often referred to as ature Agile , since it
grew up with a strong base in the corporate world of projects fro 1994 and retains a strong project focus in the
21st century.
As a founder e ber of the Agile Alliance, has been at the heart of Agile since 2 1. he philosophy and
principles of DSDM helped shape the Manifesto for Agile Software Development, although DSDM takes the
concept of Agile far wider than just software. he Agile roject Fra ework fully adopts the values laid out
in the anifesto.
22
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
2.1.3 How does DSDM differ from more traditional approaches?

In DSDM, the iterative approach encourages detail to emerge over time; therefore, the current step needs to be
co pleted in only enough detail to allow the project to ove to the ne t step with any shortfall in detailed
understanding being dealt with in a subse uent iteration of develop ent. iven the very strong likelihood that
business requirements will change over time, and that such change is most likely to happen at the detail level, the
effort traditionally spent on detailed up front work is avoided in . olutions built using the approach
address the current and i inent needs of the business rather than, for e a ple, the traditional approach of
attacking all the perceived possibilities.
As a result, solutions are ore likely to have a better fit with the true business need and are easier to test and
easier to integrate into e isting and e erging business processes. he develop ent cost of ost solutions is only
a s all part of the total cost of ownership it therefore akes sense to build si pler solutions that are both fit
for purpose on the day of delivery and easier to aintain and odify thereafter. his is preferable to trying to
i ple ent a ore e tensive solution that has been co plicated and often co pro ised by failed atte pts to
predict future business needs.
23
AgileBA Handbook
2.1.4 How does DSDM differ from most Agile approaches?

re uires basic foundations for the project to be agreed at an early stage. his allows businesses to
understand the scope and fundamental characteristics of the proposed solution, and the way it will be created,
before develop ent starts. larifying and agreeing the foundations for the project fro the co bined perspectives
of business, solution and anage ent reduces the likelihood of nasty surprises on projects. For larger
corporate organisations or organisations with a co ple architecture and or governance standards, agreeing the
foundations early in the project is essential.
also describes a broader set of roles than ost Agile approaches giving it a better fit with ost corporate
environ ents without co pro ising agility.
2.1.5 Why Choose DSDM as your Agile approach
has a broader focus than ost other Agile approaches in that it deals with projects rather than just the
evolutionary develop ent and delivery of a product typically software . he project conte t re uires a focus on
the wider business need and on all aspects of the solution that evolves to eet that need.
ay also be used to supple ent an e isting in house Agile approach, where this has proved to be lacking.
For e a ple, is often used to provide the full project focus to co ple ent cru s tea focused product
develop ent process. he Agile roject anage ent and cru pocketbook available fro www.dsd .org
provides guidance on this particular co bination.
also takes a prag atic approach, recognising that it often needs to work alongside e isting standards and
approaches. a ples of this are with 2®, DSDM with ITIL, DSDM with formal quality processes,
such as or and with a .
is not only about developing new solutions projects to enhance e isting solutions are also well suited to the
approach.
2.1.6 Summary of the benefits of using DSDM
sing iterative develop ent, involves the solution s business stakeholders throughout the project lifecycle.
his has any benefits, for e a ple
• The business is better able to direct development of the solution and is more likely to feel ownership of the
solution as it evolves and, most importantly, as it transitions into live use
• rioritisation enables a project to be delivered on ti e whilst protecting the uality of what is being delivered
• he risk of building the wrong solution is greatly reduced the final solution is ore likely to eet the real
business need
Deployment is more likely to go smoothly, due to the co-operation of all parties concerned throughout
develop ent .
2.2 Philosophy and Fundamentals

The DSDM philosophy is that
“best business value emerges when projects are aligned to clear business goals,
deliver frequently and involve the collaboration of motivated and empowered
people.”
This is achieved when all stakeholders:
• nderstand and buy into the business vision and objectives
• Are e powered to ake decisions within their area of e pertise
• ollaborate to deliver a fit for purpose business solution
24
• Collaborate to deliver to agreed timescales in accordance with business priorities
• Accept that change is inevitable as the understanding of the solution grows over time
takeholders enco pass everybody inside or outside the project who is involved in or affected by it.
Philosophy
Principles
Products
Practices
Process
People
Common sense and pragmatism
Figure 2a: The composition of DSDM
The DSDM Philosophy is supported by a set of eight Principles that build the mindset and behaviours necessary
to bring the philosophy alive. he principles are the selves supported by People with defined roles and
responsibilities , an Agile Process enabling an iterative and incre ental lifecycle to shape develop ent and delivery ,
clearly defined Products and recommended Practices to help achieve the opti u results.
DSDM’s approach and style has always been founded on an underlying ethos of common sense and pragmatism. It
may be useful to clarify the meaning of these words:
• Common sense sound practical judg ent independent of specialised knowledge or training nor al native
intelligence.
• Pragmatism - “action or policy dictated by consideration of the immediate practical consequences rather than by
theory or dog a.
his is the style of thinking that underpins the way works . t is this e ibility of thinking that enables
to avoid the dog a that is so eti es encountered in the world of Agile. he ethos of co on sense and
prag atis ensures that individuals and interactions continue to take precedence over processes and tools .
25
AgileBA Handbook
2.3 Understanding Project Variables

rojects have to balance con icting de ands, and the four ost co on de ands are ti e, cost, features and
uality. rying to fi all four at the outset of a project is unrealistic, as this would only work in a perfect world
where the business need never changes, everything is fully and precisely understood in advance, and problems
never happen. his desire to fi everything is the cause of any project failures, as the lack of sufficient contingency
results in awed decisions that are often only noticed towards the end of the project when it is too late to correct
the .
For this reason, it is i portant at the start of a project to ask the uestion f we hit a proble , what do we protect
fi and what can we negotiate vary if necessary
Traditional Approach DSDM Approach

Fixed
Time Cost
Features
Quality
Quality
Variable
Time Cost Features
Figure 2b: Project variables - traditional and DSDM
ypically, in the traditional approach to anaging a project left hand diagra , the feature content of the solution
is fi ed whilst ti e and cost are subject to variation. uality also tends to beco e an unplanned variable pri arily
due to the fact that testing is typically left to the end of the project and, as a result of an atte pt to ake up for
previous overruns, is either truncated in ter s of testing effort or the ti e available to fi any defects identified.
By default, s approach to anaging the project right hand diagra fi es ti e, cost and uality at the end of
the Foundations phase see section 2.5 while contingency is anaged by varying the features the re uire ents
to be delivered. As and when contingency is re uired, the business roles identify the least valuable of the re aining
re uire ents. hese are then dropped or deferred in order to keep the project on track.
A project will always deliver a viable solution, on ti e and on cost on budget , as long as the practices
of o oW and i ebo ing are followed. elivery of a ini u sable ubse of re uire ents is
guaranteed as a worst case scenario. owever, in all but the ost e tre e circu stances, the e pectation is to
deliver far ore than the bare ini u .
The iterative and incremental approach to development ensures that the more important requirements are built
to the agreed level of uality. nly once this has been achieved does develop ent start on the less i portant
re uire ents. ncre ental delivery of the volving olution ensures that, on the day that the solution is deployed
into live use, uality is at the level e pected and previously agreed.
26
2.4 Principles
o enable the philosophy of driving out best business value through projects aligned to clear business goals, fre uent
delivery and collaboration of motivated and empowered people, DSDM is based on eight principles that are
supported by the definition of, and guidance on, people, products, process and practices.
Compromising any of the principles undermines the philosophy of DSDM and introduces risk to the successful
outco e of the project. f a tea doesn t follow all of these principles then it won t get the full benefit of the
approach. he collective application of s principles brings the philosophy to life.
The eight principles are:
“best business value emerges when projects are aligned to clear business goals,
deliver frequently and involve the collaboration of motivated and empowered
people”.
Compromising any of the principles undermines the philosophy of DSDM and introduces risk to the successful
outco e of the project. f a tea doesn t follow all of these principles then it won t get the full benefit of the
approach. he collective application of s principles brings the philosophy to life.
The eight principles are:
1. Focus on the business need 2. eliver on ti e
3. ollaborate 4. ever co pro ise uality
5. Build incre entally fro fir foundations 6. evelop iteratively
7. o unicate continuously and clearly 8. e onstrate control
2.4.1 Principle 1 - Focus on the Business Need

very decision taken during 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.
t is i portant to re e ber that a project is a eans to an end, not an end in itself.
2.4.2 Principle 2 - Deliver on Time
elivering a solution on ti e is a very desirable outco e for a project and is uite often the single ost i portant
success factor. ate delivery can often under ine the very rationale for a project, especially where arket
opportunities or legal deadlines are involved. ven for projects without a need for a fi ed end date, on ti e delivery
of inter ediate or contributing products is still the best way to de onstrate control over evolution of the solution.
2.4.3 Principle 3 - Collaborate
Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals
working only in loose association. ollaboration encourages increased understanding, greater speed and shared
ownership, which enable tea s to perfor at a level that e ceeds the su of their parts.
2.4.4 Principle 4 - Never Compromise Quality
n , the level of uality to be delivered should be agreed at the start. All work should be ai ed at achieving
that level of uality no ore and no less. A solution has to be good enough . f the business agrees that the
features in the ini u sable ubse eet the agreed acceptance criteria, then the solution should be good
enough to use effectively.
27
AgileBA Handbook
2.4.5 Principle 5 - Build Incrementally from Firm Foundations

ne of the key differentiators for within the Agile space is the concept of establishing fir foundations
for the project before co itting to significant develop ent. advocates first understanding the scope
of the business proble to be solved and the proposed solution, but not in such detail that the project beco es
paralysed by overly detailed analysis of re uire ents.
nce fir foundations for develop ent have been established, advocates incre ental delivery of
the solution in order to deliver real business benefit as early as is practical. ncre ental delivery encourages
stakeholder confidence, offering a source of feedback for use in subse uent i ebo es and ay lead to the early
realisation of business benefit.
2.4.6 Principle 6 - Develop Iteratively
DSDM uses a combination of Iterative Development, frequent demonstrations and comprehensive review to
encourage ti ely feedback. bracing change as part of this evolutionary process allows the tea to converge
on an accurate business solution. he concept of iteration is at the heart of everything developed as part of the
approach. t is very rare that anything is created perfectly first ti e and it is i portant to recognise that
projects operate within a changing world.
2.4.7 Principle 7 - Communicate Continuously and Clearly
oor co unication is often cited as the biggest single cause of project failure. practices are specifically
designed to i prove co unication effectiveness for both tea s and individuals.
2.4.8 Principle 8 - Demonstrate Control
t is essential to be in control of a project, and the solution being created, at all ti es and to be able to de onstrate
that this is the case. igh level plans, designs and standards outline the funda entals of what needs to be achieved,
how, by when etc. t is also vital to ensure transparency of all work being perfor ed by the tea .
2.4.9 Summary of Principles
he eight principles help direct and shape the attitude and indset of a tea . o pro ising any of the
principles undermines DSDM’s philosophy, as together they deliver a collective value that outweighs their individual
benefits.
2.5 The DSDM Process

In line with the DSDM philosophy that “the best business value emerges when projects are aligned to clear business
goals, deliver frequently and involve the collaboration of motivated and empowered people” the DSDM approach to
development and delivery is both iterative and incremental, with the most important business needs typically being
addressed early while less i portant features are delivered later. he iterative nature of enables business
representatives to see the solution as it evolves, to provide feedback on it and to request changes throughout the
develop ent of the solution.
nlike ost Agile approaches, integrates project anage ent and product develop ent into a single
process. For any organisations, is all that is needed, although so e gain value fro integrating with
other ethods e.g. project anage ent ethods, such as 2 and , or software engineering practices,
fro e tre e rogra ing .
28
Pre-Project
Feasibility
Foundations
Assemble
Evolutionary Review
Deploy
Development
Deployment
Post-Project
Figure 2c: The DSDM process
The DSDM process model comprises a framework which shows the DSDM phases and how they relate to one
another. his process odel is then used by each project to derive their lifecycle.
2.5.1 Pre-Project phase
he re roject phase ensures that only the right projects are started, and that they are set up correctly, based on
a clearly defined objective.
2.5.2 Feasibility phase
he Feasibility phase is intended pri arily to establish whether the proposed project is likely to be feasible fro a
technical perspective and whether it appears cost effective fro a business perspective. he effort associated with
Feasibility should be just enough to decide whether further investigation is justified, or whether the project should
be stopped now, as it is unlikely to be viable.
2.5.3 Foundations phase
he Foundations phase takes the preli inary investigation fro Feasibility to the ne t level. t is intended to
establish a funda ental but not detailed understanding of the business rationale for the project, the potential
solution that will be created by the project, and how develop ent and delivery of the solution will be anaged. By
intentionally avoiding low levels of detail, the Foundations phase should last no longer than a few weeks even for
large and co ple projects. he detail associated with re uire ents, and how they should be et as part of the
solution, is intentionally left until the volutionary evelop ent phase of the project.
he ai of Foundations is to understand the scope of work, and in broad ter s, how it will be carried out, by
who , when and where. he Foundations phase also deter ines the project lifecycle by agreeing how the
process will be applied to the specific needs of this project.
For s aller, si pler projects, the Feasibility and Foundations phases can often be erged into a single phase. For
larger, ore co ple projects, it ay so eti es be necessary to revisit Foundations after each eploy ent phase.
29
AgileBA Handbook
2.5.4 Evolutionary Development phase

Building on the fir foundations that have been established for the project, the purpose of the volutionary
evelop ent phase is to evolve the solution.
he volutionary evelop ent phase re uires the olution evelop ent ea s to apply practices such
as terative evelop ent, i ebo ing, and o oW prioritisation, together with odelling and Facilitated
Workshops, to converge over time on an accurate solution that meets the business need and is also built in the
right way fro a technical viewpoint.
Working within i ebo es, the olution evelop ent ea create olution ncre ents, iteratively e ploring the
low level detail of the re uire ents and testing continuously as they ove forward.
2.5.5 Deployment phase
he objective of the eploy ent phase is to bring a baseline of the volving olution into operational use. he
release that is deployed ay be the final solution, or a subset of the final solution. After the last release, the project
is for ally closed.
The Deployment phase comprises three main activities:
• Assemble - bring together what is to be released
• Review- review the increment and obtain approval to deploy
• Deploy - release into operational use
2.5.6 Post-Project phase
After the final eploy ent of a project, the ost roject phase checks how well the e pected business benefits
have been et.
2.5.7 The lifecycle in practice
Whilst there is a clear progression of phases fro re roject to ost roject in the process diagra above, there
are also arrows indicating a return path within the process, specifically the arrows fro eploy ent to Foundations
and fro eploy ent to volutionary evelop ent. he process shows the fra ework and the options available.
ach project derives their lifecycle fro this process. he lifecycle for the project is defined and agreed as part of
the Foundations phase.
2.5.8 Configuring DSDM for scalability and formality
recognises the real value of Agility in ter s of project productivity and solution uality while acknowledging
and accepting the necessary constraints that often e ist when working in a corporate environ ent. uch
constraints ay include financial governance, architecture and or infrastructure strategies, regulatory governance,
vendor agree ents and third party support considerations.
he process can be configured and calibrated to cater for a range of projects fro s all projects with light
governance to larger projects with stronger governance needs. ypically this is achieved by configuring a lifecycle
appropriate for a specific project and deter ining an appropriate level of for ality with which the products
are defined, created and approved.
With regards to scaling, the project organisation can easily be refined to support ultiple tea s, with key roles
acting as directors and coordinators across the tea s. o support a ore co ple project structure, products
such as the olution Architecture efinition, evelop ent Approach efinition, anage ent Approach efinition
and the elivery lan and i ebo eview ecords can be ade ore elaborate and ore for al than would be
appropriate for s aller projects.
2.5.9 Summary of the DSDM Process
provides an iterative and incre ental process, with a total of si lifecycle phases. ach phase has a specific
purpose, together with a nu ber of defined products intended to support the evolution of the solution and
the s ooth running of the project. he Agile roject Fra ework is designed to work effectively with
projects of varying si e and co ple ity. hrough the tailoring of its various products, ensures control is
de onstrated to a level of for ality appropriate to the organisation, thereby running a project so that all the
benefits of Agile are achieved without co pro ising effective project governance.
30
2.6 Roles and Responsibilities
eople working together effectively are the foundation of any successful project. recognises this and assigns
clear roles and responsibilities to each person in a project, representing the business interests, the solution technical
interests, the anage ent interests and the process interests. veryone involved in a project works very
closely together in order to break down potential co unication barriers.
he best solutions e erge fro self organising, e powered tea s. owever, these tea s, and the people within
the , ust actively take on the responsibility for their e power ent within the boundaries that have been agreed.
Business
Sponsor
Project Level
Business Project Technical

Visionary Manager Coordinator
Technical Business Business

Advisor Analyst Advisor
Solution Development Team
ti n g
Team
S u p p o rti n
Business Solution
Ambassador Leader Developer Sup p or
g
Solution
Tester
Workshop DSDM
Facilitator Coach
Figure 2d: The DSDM tea
2.6.1 The DSDM Team Model explained

he colour sche e in figure 2d is as follows
ran e - Business interests, roles representing the business view
ypically taken by business personnel, e.g. Business A bassador providing day to day business direction, Business
Visionary providing high-level direction and view of the future
reen olution technical interests, roles representing the solution technical view
31
AgileBA Handbook
ontributing to the technical develop ent of the solution, e.g. olution evelopers creating the solution,
Technical Coordinator providing technical leadership and direction
ue anage ent interests, roles representing the anage ent leadership view
Facilitating the anage ent leadership aspects of the project, e.g. roject anager and ea eader following
the process and anaging leading a project using Agile leadership co petencies
re - Process interests, roles representing the process view
Facilitating the process aspects of the project, e.g. Workshop Facilitator anaging the workshop process,
oach e bedding the Agile roject Fra ework
i of two colours A role that covers two separate areas of interest
2.6.2 Role categories
2.6.2.1 Project-level roles
n figure 2d, the project level roles Business ponsor, Business isionary, echnical oordinator, roject anager and
Agile BA are the directors, anagers and coordinators of the work for the project, where necessary. hey ay be
part of a project board or steering co ittee for the project and, collectively, have authority to direct the project.
hey are responsible for the governance of the project, liaising with governance authorities outside of the project
where necessary.
he Business Analyst is intentionally positioned as part of the project level as well as the olution evelop ent
ea . his allows the Business Analyst to, for e a ple, help the business to for ulate the Business ase, and also
to be involved in assisting the business in defining their re uire ents during Feasibility and Foundations, so eti es
before the olution evelop ent ea is assigned. he role then continues supporting the olution evelop ent
ea alongside the project level roles, as the ore detailed re uire ents e erge.
All roles at the project level need to adopt the facilitative, e powering leadership style which allows Agile tea s to
learn as they go, getting to an end point by their own eans, within an agreed fra ework of e power ent.
2.6.2.2 Solution Development Team roles
The Solution Development Team roles are Business Ambassador, Solution Developer, Solution Tester, Agile BA,
and ea eader. hese roles for the engine roo of the project. hey shape and build the solution and are
collectively responsible for its day to day develop ent and for assuring its fitness for business purpose. here ay
be one or ore olution evelop ent ea s within a project. ach tea will include all olution evelop ent
ea roles and cover all their responsibilities.
2.6.2.3 Supporting roles
he supporting roles Business Advisors, echnical Advisors, Workshop Facilitator and oach provide
assistance and guidance to the project on an ad hoc basis throughout
ghout the lif
lifecycle. he Advisor roles ay be filled
by one or ore subject atter e perts, as necessary.
2.6.3 Fulfilling the roles
ne role does not necessarily ean one person. ne person ay take on one or ore roles. ne role
ay be shared by two or ore people. Where a role is shared it is vital that the individuals co unicate and
collaborate closely.
2.6.4 The Roles
2.6.4.1 Business Sponsor
his role is the ost senior project level business role. he Business ponsor is the project cha pion who is
co itted to the project, to the proposed solution and the approach to delivering it. he Business ponsor is
specifically responsible for the Business ase and project budget throughout however for ally or infor ally this
ay be e pressed .
he Business ponsor ust hold a sufficiently high position in the organisation to be able to resolve business issues
and ake financial decisions.
32
2.6.4.2 Business Visionary
his is a senior project level business role that should be held by a single individual, since a project needs a single
clear vision to avoid confusion and isdirection. ore actively involved than the Business ponsor, the Business
Visionary is responsible for interpreting the needs of the Business Sponsor, communicating these to the team and,
where appropriate, ensuring they are properly represented in the Business ase. he Business isionary re ains
involved throughout the project, providing the tea with strategic direction and ensuring that the solution delivered
will enable the benefits described in the Business ase to be achieved.
2.6.4.3 Technical Coordinator
As the project s technical authority, the echnical oordinator ensures that the solution technical roles work in
a consistent way, that the project is technically coherent and eets the desired technical standards. his role
provides the glue that holds the technical aspects of the project together while advising on technical decisions and
innovation.
The Technical Coordinator performs the same function from a technical perspective as the Business Visionary does
fro a business perspective.
2.6.4.4 Project Manager
As well as providing high-level Agile-style leadership to the Solution Development Team, the role is focused on
anaging the working environ ent in which the solution is evolving. he roject anager also coordinates all
aspects of anage ent of the project at a high level but, in line with the concept of e power ent, the
roject anager is e pected to leave the detailed planning of the actual delivery of the product s to the e bers
of the olution evelop ent ea . anaging an e powered tea re uires a facilitative style rather than a
co and and control style.
t is usual that the roject anager takes responsibility throughout the duration of the project. his ust include
both business and technical delivery aspects of the project, fro Foundations if not Feasibility through to
eploy ent.
2.6.4.5 Business Analyst
he Agile BA is both active in supporting the project level roles and fully integrated with the olution evelop ent
ea . hey facilitate the relationship between the business and technical roles, ensuring accurate and appropriate
decisions are ade on the volving olution on a day to day basis. he Agile BA ensures that the business needs
are properly analysed and understood by the all e bers of the olution evelop ent ea .
Active involvement of the business users in the process of evolving the solution is vital to the success of a DSDM
project. herefore it is i portant to ensure that the Business Analyst does not beco e an inter ediary between
the olution evelop ent ea e bers but, instead, supports and facilitates the co unication between the .
2.6.4.6 Team Leader
The Team Leader ideally acts as the servant-leader for the Solution Development Team and ensures that it
functions as a whole and eets its objectives. he ea eader works with the tea to plan and coordinate all
aspects of product delivery at the detailed level. his is a leadership role rather than a anage ent role and the
person holding it will ideally be elected by his or her peers as the best person to lead them through a particular
stage of the project. t is therefore likely that they will also perfor another olution evelop ent ea role
e.g. Agile BA, Business A bassador, olution eveloper or olution ester in addition to their tea leadership
responsibilities.
2.6.4.7 Business Ambassador
he Business A bassador is the key representative of the business within the olution evelop ent ea . uring
Foundations, the Business A bassador has significant input into the creation and prioritisation of re uire ents.
nce the re uire ents have been agreed and baselined by the end of Foundations , the Business A bassador
then provides the day to day detail of the re uire ents during i ebo ed develop ent. his is either based on
their own knowledge and e perience, or drawing on the e perience of Business Advisors.
uring the volutionary evelop ent phase of the project, the Business A bassador is the ain decision aker
on behalf of the business. For this reason the Business A bassador needs to be so eone who is respected by
33
AgileBA Handbook
their business peers and who has sufficient seniority, e power ent and credibility to ake decisions on behalf of
the business, in ter s of ensuring the volving olution is fit for business purpose.
2.6.4.8 Solution Developer
The Solution Developer collaborates with the other Solution Development Team roles to interpret business
requirements and translate them into a Solution Increment that meets functional and non-functional needs of the
business as a whole.
2.6.4.9 Solution Tester
The Solution Tester is an empowered Solution Development Team role, fully integrated with the team and
perfor ing testing throughout the project in accordance with the agreed strategy.
2.6.4.10 Business Advisor
ften a peer of the Business A bassador, the Business Advisor is called upon to provide specific, and often
specialist, input to solution develop ent or solution testing a business subject atter e pert. he Business
Advisor ay be an intended user or beneficiary of the solution or ay, for e a ple provide legal or regulatory
advice with which the solution ust co ply.
2.6.4.11 Technical Advisor
he echnical Advisor supports the tea by providing specific, and often specialist, technical input to the project,
often from the perspective of those responsible for operational change management, operational support, ongoing
aintenance of the solution, etc.
2.6.4.12 Workshop Facilitator
he Workshop Facilitator is responsible for planning, organsing and facilitating workshops to ensure that a group
of people collaborates to eet a predeter ined objective in a co pressed ti efra e. he Workshop Facilitator
should ideally be independent of the outco e to be achieved in the workshop.
2.6.4.13 DSDM Coach
Where a tea has li ited e perience of using , the role of the oach is key to helping tea
e bers to get the ost out of the approach, within the conte t and constraints of the wider organisation in
which they work.
2.6.5 Summary of DSDM Roles
identifies roles in two di ensions categories and interests. oles are grouped into three categories
• roject level roles Business ponsor, Business isionary, echnical oordinator, roject anager and Agile BA
also a e ber of the olution evelop ent ea
• Solution Development Team roles - Business Ambassador, Solution Developer, Solution Tester, Team Leader and
Agile BA also a roject level role
• upporting roles Business Advisor, echnical Advisor, Workshop Facilitator and oach
And four interests:
• Business interests - covered by the Business Sponsor, Business Visionary, Business Ambassador and Business
Advisor roles
• olution technical interests covered by the echnical oordinator, olution eveloper, olution ester and
Technical Advisor roles
• anage ent interests covered by the roject anager and ea eader roles
• rocess interests covered by the Workshop Facilitator and oach roles
he Agile BA role covers both business and solution technical interests.
34
2.7 Products
he Agile roject Fra ework describes a set of products to be considered as the project proceeds. hese
products describe the solution itself the ain deliverable of the project and anything created to help with the
process of evolving it, and anything that is re uired to help with project governance and control.
ot all products are re uired for every project and the for ality associated with each product will vary fro
project to project and fro organisation to organisation. he for ality of the products is in uenced by factors such
as contractual relationships, corporate standards and governance needs.
he products, and where they feature in the project lifecycle, are shown in the diagra below. range products
are business focused, green products all contribute to the solution being created by the project and blue products
cover project anage ent control interests.
Several of the products - those marked with G - may also play a part in governance processes such as approval
gateways, and may be used to demonstrate compliance of the solution with corporate and regulatory standards
where this is re uired.
Pre-Project Feasibility Foundations Evolutionary Development Deployment Post-Project
Level of Detail
(Outline) (Foundations)
Prototypes
Business Case Supporting

Materials
Business
G G
Terms of Benefits
Reference Assessment
Prioritised Req’s List Models
Evolving
Solution Deployed
Solution
Solution Architecture
Solution
Definition Testing &

Assurance
Development Approach Solution

Increment
Definition
Delivery Plan
Management
G
Timebox
Timebox
Review
Plan
Record
Management Approach
Definition
G G G
Project
Feasibility Foundations
Review
Assessment Summary
Report
Figure 2e: DSDM products
2.7.1 The DSDM Products

2.7.1.1 Terms of Reference
he er s of eference is a high level definition of the over arching business driver for, and top level objectives of,
the project. he pri ary ai of the er s of eference is to scope and justify the Feasibility phase. t is identified
as a governance product because it ay be used for purposes such as prioritisation of a project within a portfolio.
35
AgileBA Handbook
2.7.1.2 Business Case

he Business ase provides a vision and a justification for the project fro a business perspective. he business
vision describes a changed business as it is e pected to be, incre entally and at the end of the project. he
justification for the project is typically based on an invest ent appraisal deter ining whether the value of the
solution to be delivered by the project warrants the cost to produce, support and aintain it into the future, all
within an acceptable level of risk.
Baselines of the Business ase are typically created first as an outline by the end of Feasibility, then as a basis for
approval of develop ent by the end of Foundations. t is for ally reviewed at the end of each roject ncre ent
in order to deter ine whether further work is justified.
2.7.1.3 Prioritised Requirements List
he rioritised e uire ents ist describes, at a high level, the re uire ents that the project needs to
address, and indicates their priority with respect to eeting the objectives of the project and the needs of the
business. onsideration of re uire ents begins in Feasibility and a baseline of the describes the scope of
the project as at the end of Foundations. After that point, further change will happen naturally in ter s of depth,
as a result of e ergence of detail. hange to the breadth adding, re oving or significantly changing high level
re uire ents needs to be for ally controlled in order to ensure ongoing align ent with the business vision for
the project and to keep control of the scope.
So ution Architecture De nition
he olution Architecture efinition A provides a high level design fra ework for the solution. t is intended
to cover both business and technical aspects of the solution to a level of detail that makes the scope of the solution
clear but does not constrain evolutionary develop ent.
De e op ent Approach De nition
he evelop ent Approach efinition A provides a high level definition of the tools, techni ues, custo s,
practices and standards that will be applied to the evolutionary develop ent of the solution. portantly it
describes how uality of the solution will be assured. A strategy for testing and review is therefore a key part of
the develop ent approach and described in the evelop ent Approach efinition.
2.7.1.6 Delivery Plan
he elivery lan provides a high level schedule of roject ncre ents and, at least for the first i inent
incre ent, i ebo es that ake up that incre ent. t rarely deals with task level detail unless there are tasks being
carried out by people who are not part of the Solution Development Team or before the Solution Development
ea is for ed.
Mana e ent Approach De nition
he anage ent Approach efinition A re ects the approach to the anage ent of the project as a whole
and considers, fro a anage ent perspective, how the project will be organised and planned, how stakeholders
will be engaged in the project and how progress will be de onstrated and, if necessary, reported. he product is
outlined in Feasibility and baselined at the end of Foundations and will only evolve beyond that when circu stances
change or if review of the approach identifies areas for i prove ent.
2.7.1.8 Feasibility Assessment
he Feasibility Assess ent provides a snapshot of the evolving business, solution and anage ent products
described above as they e ist at the end of the Feasibility phase. ach of the products should be ature enough to
ake a sensible contribution to the decision as to whether the project is likely to be feasible or not. he Feasibility
Assess ent ay be e pressed as a baselined collection of the products or as an e ecutive su ary covering the
key aspects of each of the .
2.7.1.9 Foundation Summary
he Foundation u ary provides a snapshot of the evolving business, solution and anage ent products
described above as they e ist at the end of the Foundations phase. ach of the products should be ature enough
to ake a sensible contribution to the decision as to whether the project is likely to deliver the re uired return on
invest ent. he Foundation u ary ay be e pressed as a baselined collection of the products described above
or as an e ecutive su ary covering the key aspects of each of the .
36
2.7.1.10 Evolving Solution
he volving olution is ade up of all appropriate co ponents of the final solution together with any
inter ediate deliverables necessary to e plore the detail of re uire ents and the solution under construction. At
any given ti e, such co ponents ay be either co plete, a baseline of a partial solution a olution ncre ent , or
a work in progress. hey include, where valuable odels, prototypes, supporting aterials and testing and review
artefacts.
At the end of each roject ncre ent the olution ncre ent is deployed into live use and beco es the eployed
olution.
2.7.1.11 Timebox Plan
he i ebo lan provides depth and detail for each i ebo identified in the elivery lan. t elaborates on
the objectives provided for that i ebo and details the deliverables of that i ebo , along with the activities
to produce those deliverables and the resources to do the work. he i ebo lan is created by the olution
evelop ent ea and is often represented on a ea Board as work to do, in progress, and done. t is updated
at least on a daily basis at the aily tand ups.
2.7.1.12 Timebox Review Record
he i ebo eview ecord captures the feedback fro each review that takes place during a i ebo . t
describes what has been achieved up to that point together with any feedback that ay in uence plans oving
forwards. Where appropriate, e.g. in a regulated environ ent, a for al auditable record of review co ents fro
e pert Business Advisors and other roles ake this a governance product.
2.7.1.13 Project Review Report
he roject eview eport is typically a single docu ent that is updated, incre entally, at the end of each roject
ncre ent by the addition of new sections pertinent to that incre ent.
At the end of each roject ncre ent, the purpose of this product is
• o capture the feedback fro the review of the delivered solution and to confir what has been delivered and
what has not
• To capture learning points from the retrospective for the increment focussed on the process, practices employed
and contributing roles and responsibilities
• Where appropriate to describe the business benefits that should now accrue through the proper use of the
solution delivered by the project up to this point
After the final roject ncre ent, as part of project closure, a retrospective covering the whole project is carried
out that is partially informed by the records for each increment
ene ts Assess ent
he Benefits Assess ent describes how the benefits have actually accrued, following a period of use in live
operation. For projects where benefits in the Business ase are e pected to accrue over a prolonged period, it is
possible that a nu ber of Benefits Assess ents ay be produced on a periodic basis aligned with the ti efra e
used for justifying the invest ent.
2.7.2 Summary of Products
he products above are guidelines to the infor ation needed to pro ote good co unication within a project.
hey are not andatory, and ay not always be presented as docu ents. owever, in circu stances where
strong governance and or proof of co pliance with standards is i portant, there is real benefit to creating for al
docu ents rather than just gaining a shared understanding which is the nor al default for . Although it
may not be obvious, it is important to remember that documentation created as part of the development process
and or tied to the proactive way the project is anaged, is likely to provide the ost effective and robust audit trail
if one is needed.
It is also critically important to remember that DSDM products are only created if and when they add value to the
project and or to the solution it creates. he ost i portant thing is that the stakeholders and participants in the
project understand what is needed and what is being delivered and that uality is assured. f docu ents genuinely
help achieve this then create the , if not, don t waste valuable ti e and effort doing so.
37
AgileBA Handbook
2.8 Practices
Agile eans working collaboratively, with good co unication. he ajor practices below enhance this way of
working:
harnesses any valuable Agile practices. A set of five key practices are specifically cited to support the
adoption of the eight rinciples. hese key practices are
• MoSCoW Prioritisation
• Facilitated Workshops
• odelling and rototyping
• Iterative Development
• i ebo ing
hese are considered, along with other Agile practices, throughout this andbook. ater chapters give specific
guidance for the Agile BA on each one in turn.
2.9 The Agile BA within the Agile Project

The Agile BA has an important role within the Agile Solution Development Team, supporting and facilitating
co unication and bringing business analysis skills to give the wider view to any proposed change.
Additionally, the Agile BA role e tends to supporting the project level roles of the Agile project. he Agile BA
also has a responsibility to the organisation outside of the project, keeping the end to end, value focused view of
the changes being developed and supporting senior business anage ent in linking the project to the strategic
direction which it has been co issioned to i ple ent.
2.10 Conclusion
is a leading and proven Agile fra ework for all types of projects. is free to view and free to use in
your own organisation. Because it allows scope for the Agile BA to work with the rest of an Agile tea , it is the
fra ework used to give conte t within this book.
The Agile BA role has a threefold focus: within the Agile Solution Development Team, supporting and facilitating
co unication and aking visible the effects on value of changes proposed to the project level roles, supporting
the Business ponsor, Business isionary, echnical o ordinator and roject anager to the organisation, linking the
project to the strategic direction of the organisation.
n the rest of this andbook, we shall e plore the role, skills and practices of the Agile BA.
38
3. The Agile Business
Case
391
1 1
The Agile Business Case
AgileBA Handbook
3.1 Introduction
his chapter considers how business change projects arise and how changes link to the corporate ission and
goals. t shows how the Business ase provides the driver and continued justification for a project and follows the
production and use of a Business ase for an Agile project through the phases of its lifecycle, fro re roject to
ost roject. his includes benefits realisation and the assess ent of benefits e pected in the Business ase.
The chapter shows how an Agile Business Case may be different from a traditional Business Case and describes the
involvement of the DSDM roles, particularly that of the Agile BA, in the production of, and continued focus on, the
Business ase within a project.
Finally, it identifies how Agile practices can help to for ulate and clarify a Business ase how they can pro ote
buy-in and a shared vision; how they can be used in the presentation of the Business Case; how they help to keep
focus on the value being delivered throughout the project.
At the start of a project there is so eti es a reluctance to e press uncertainty, especially with the initial high
level Business ase. owever, this uncertainty should be acknowledged. As the project develops, the e tent of
uncertainty should reduce. his leads to increased confidence and credibility a ongst all stakeholders.
3.2 Why do we need a Business Case?

rojects arise to address a need for change. he need ay e erge fro any area of the business, perhaps in
relation to a ajor strategic progra e of work, or si ply to correct operational proble s. ost organisations
will have structures, such as a steering co ittee or a change board, through which re uests for change are filtered
and invest ent decisions for projects are ade.
When a change has been authorised, a budget is usually allocated by senior anage ent budget holders. his
budget will typically be acco panied by allowances and restrictions related to cost, ti e, scope, benefit, uality, risk
and i pact of the change. he approach to anaging the resulting project, whether or not this is an Agile approach,
should be chosen to ini ise the risk of e ceeding cost and ti e, whilst retaining focus on benefit, business value
and uality.
3.2.1 The Project Business Case
he Business ase is the justification for a project. t evolves fro an initial high level outline of the benefits, costs
and ideally the ajor risks, into a ore uantified version, to justify develop ent co encing. t is then used to
onitor progress throughout the project and to infor key decisions regarding its ongoing viability. After delivery
and a period where benefits can accrue fro the solution delivered, the actual benefits realised can be assessed
against the projections in the Business ase.
he project s Business ase is therefore an e tre ely i portant artefact for a project and its governance. t guides
the decision aking processes, prioritisation and budget allocation and is used continually to align the project s
progress to the business objectives. Business ases represent the infor ation needed by the anage ent of the
organisation to justify the co it ent of oney and resources. herefore, Business ases vary considerably fro
one organisation to another and depend on the nature, si e and risk of the project. he Agile BA s first step in
developing a Business ase is to seek guidance fro the decision akers or decision aking body to understand
their needs: what information do they require to enable them to make comparative investment decisions about
which projects to initiate What ongoing infor ation will they ask for to help the to continually assess the
project s viability What evidence will they need of benefits realised fro that invest ent
o e Business ases re uire significant effort in their develop ent and approval, because the project is a ajor
invest ent and will have a significant i pact on the organisation. thers re uire less effort and detail. f the
project is self contained and has ini al i pact on other parts of the organisation, a for al Business ase ay be
si ple or ay not be re uired at all.
40
3.2.2 Business Strategy and the Business Case
he Business ase for a project is linked to organisational strategic needs. A corporate business plan or business
concept docu ent ay precede the project s Business ase. t is essential to have continuity between this and the
view taken forward by the project. f the project is part of a progra e, a progra e business case will infor or
define a project s Business ase.
3.2.3 The small change or a pipeline of changes
o eti es work is initiated to enact a uick fi or a inor odification. hese changes are usually classified as
s all changes because they are below a certain cost and ti e threshold. any organisations have a separate
procedure to allow s all changes to be grouped and allocated budget as a part of a pipeline of changes. uch
s all changes need to be classified on the basis of ti e to fi , cost to fi , benefit and or value e pected and risk.
hese pieces of work will not usually have a for al Business ase. hey ay re uire no ore than a brief i pact
analysis and classification of their i portance and benefit to infor a decision to accept or reject the . owever,
they still need business analysis to ensure that their cu ulative effect is beneficial and their interrelationships are
identified. his re uires a clear focus on business processes, end to end business value, business goals and the
organisation s overall ission.
3.3 When is a project Business Case Created and How

Does it Evolve?
Detailed requirements emerging

Timebox
imeb Timebox Timebox Timebox Timebox
• Feasibility study
• Outline business case • Timebox plans
• Key stakeholders • Completed product
• Outline plan
• Feasibility prototype
• Prioritised high level requirements
• Full business case
• Key stakeholders, roles and empowerment
• Project plan
• First increment plan
• Solution prototype
Figure 3a: BA involvement in a DSDM project
3.3.1 Pre-Project
f the project is triggered by organisational strategic needs, a progra e business case or business concept
docu ent ay already e ist. hese will be used to for ulate the er s of eference for the project, and
will be brought into the project by its Business ponsor. he will contain an e bryonic Business ase, in that
it describes the business driver and top level objectives for the proposed project.
41
AgileBA Handbook
3.3.2 Feasibility
uring Feasibility, an outline Business ase will be created, in line with the and included as part of the
Feasibility Assess ent . he Business ponsor, Business isionary, echnical oordinator, roject anager, Agile BA
and other key stakeholders should be involved in its creation. he Agile BA is responsible for its production and
ay have a role in any workshops to develop and gain consensus and approval for the outline Business ase.
he Agile BA for the project ay have been involved before the project, in the strategic level analysis fro which
the idea for a project ay have e erged. o eti es, this re roject work ay have been carried out by a
different, strategic Business Analyst. he project s Agile BA should liaise with the strategic BA on the underlying
purpose and objectives of the project, bringing the into the project s initial ick off and vision sharing Facilitated
Workshops where possible hapter 7 .
ery high level re uire ents for the project will be captured in the rioritised e uire ents ist during Feasibility.
he Agile BA will work with stakeholders to identify and prioritise these and group the as the ajor the es
to be addressed by the project. hey will be further defined at this point with high level, easurable objectives
Acceptance riteria . A high level prototype ay be de onstrated to illustrate the intended direction for the
solution to be developed or procured. his de onstration could be a part of a Workshop hapter 7 .
3.3.3 Foundations
his is where the project s Business ase will be evolved to the level needed for the project. n an Agile project,
this should be to a level which is just sufficient for the decision aking process, and to guide the project in the right
direction. here is always a te ptation to go into too uch detail at this point and this should be avoided, because
low level, solution oriented detail is likely to change as the Agile project progresses. he project Business ase
should be at a level which is likely to re ain relatively stable during the project, to act as a good resource against
which to easure achieve ent of benefits.
The Agile BA facilitates the development of the Business Case, which is agreed and authorised by the Business
ponsor. eveloping the Business ase is a collaborative process, involving key stakeholders and roject evel
roles, supported by the planning and esti ating activities of the olution evelop ent ea .
Benefits ealisation should be considered during the creation of the Business ase. etrics to allow benefits
assess ent should be deter ined at an early point, and their easure ent planned. he etrics should be kept
si ple and be carefully chosen to give a clear view of the benefits directly attributable to this particular project s
outputs and outco e.
he Agile BA will work with all other roles during Foundations, helping to keep focus on planning for the early
delivery of business value, and delivering the ost valuable features first, consistent with appropriate consideration
of risk and uality.
The Agile BA will follow a best-practice requirements lifecycle, to elicit, analyse and validate requirements,
asse bling these into a rioritised e uire ents ist . his process will re uire collaboration with the
roject evel roles, olution evelop ent ea roles and other stakeholders. he will typically be a i ture
of pic tories and ser tories hapter 5 and will incorporate high level acceptance criteria for these, in line
with the benefits outlined in the Business ase. he Agile BA will also work with the Business isionary to ensure
that business value is considered for each re uire ent or group of re uire ents. hey will also ake sure that
the traceability from the Business Case to each requirement remains visible, through the changing levels of detail of
these re uire ents, to the eventual i ple entation, or possibly descoping, of these re uire ents.
uality eview eetings hapter 11 are a useful way to establish an agreed baseline for the at the end of
Foundations. his is not to prevent change to the re uire ents, but to define an agreed starting point to clarify the
project scope, in ter s of breadth, for planning purposes. t is recognised that re uire ents detail will e erge after
this point. f and when re uire ents change during the project s life, it will be easier to assess the i pact of the
change if the starting point was known and agreed.
42
3.3.4 Evolutionary Development
he Business ase, drawn up and agreed during Foundations, is the basis for justifying project activities and
deliverables throughout the re ainder of the project and its guidance should be visible to the whole olution
evelop ent ea , in addition to the project level roles, as they evolve and test the solution. he high level
at which the Business ase presents benefits, costs and plans should be sufficient to allow e ibility during
volutionary evelop ent.
uring volutionary evelop ent, the Agile BA works as a e ber of the olution evelop ent ea , helping to
aintain the tea s focus on the business need and Business ase as the lower level detail e erges. he Agile BA
is responsible for ensuring that the detail of the lower level re uire ents is captured and docu ented in the .
The Solution Development Team ensures that the appropriate solution emerges, that the product is built correctly
and that it also keeps its focus on the business need for which the project was initiated.
he Agile BA has the odelling skills hapter 8 to analyse both current and future situations As s and o Be
and to keep these visible to the project stakeholders. ence, an additional area of work for the Agile BA during
volutionary evelop ent is involve ent in the evolution of the elivery lan. his will be infor ed by the
Business ase, which will have identified risks and i pacts associated with the business change.
3.3.5 Deployment
During Deployment, the Agile BA will work with the Business Visionary and Technical Co-ordinator to ensure
that, as incre ental ele ents of the solution are deployed, the focus on cost and realising the e pected benefits
is aintained. he Agile BA ay also help to ensure that the changes for people and processes are facilitated
s oothly, and that etrics are captured before and after eploy ent, for later use in assessing the benefits realised.
3.3.6 Post-Project
After a period of use of increments of the solution, the Agile BA may work with the Business Sponsor and Business
isionary in particular, to establish what actual benefits have been realised, using previously established etrics.
3.4 What should an Agile Business Case Contain?

he purpose of the Agile Business ase is to co unicate predicted costs, benefits, risks and i pacts of a
proposed change and to act as a co pass for the project during its course.
he Business ase provides a vision and a justification for the project fro a business perspective. t is an
evolutionary product, evolving fro an e bryonic vision in the er s of eference, through to an outline Business
ase by the end of Feasibility, which can consider several options in outline and reco ends a way forward. t is
then elaborated during Foundations, in relation to the chosen option.
Baselines of the Business ase are typically created as an outline at the end of Feasibility, then as a basis for approval
of develop ent by the end of Foundations. t is for ally reviewed at the end of each roject ncre ent in order
to deter ine whether further work is justified.
uring Feasibility, the Business ase will often identify a range of possible solutions and reco end the best option
or occasionally options for further, ore detailed evaluation. An option not to continue with the project should
nor ally also be presented. uring Foundations, it will evolve to fully justify the project, and beyond Foundations it
should be just enough to guide the project s direction in relation to the chosen option. he si e and for at of the
Business ase will be appropriate to the level of invest ent and the perceived risk. t does not need to be a huge
docu ent, and so eti es a single page of infor ation ay be sufficient.
n so e situations it ay not be possible, or even desirable, to tie down the detail of costs, benefits, risks or
i pacts and the project ay need to take a ore e pirical, e ploratory approach to both the Business ase and
project planning. Fle ibility is re uired within the Business ase to acco odate this, where necessary, allowing
for change and reprioritisation during the course of the project. owever, using an Agile approach, the apparent
risk associated with a lack of certainty early on is balanced by reduced financial risk, as business value begins to
accrue earlier in line with incre ental delivery of the solution the project ay start to pay for itself during its
lifeti e. Additionally, because progress is highly visible in an Agile project, it is easily onitored. f the project is not
delivering as e pected in the early stages, action can be taken to correct this.
43
AgileBA Handbook
Where we are now Where we want to be
The
Business
Case
How can we get there?
Option 3
Option 1 Option 2
Figure 3b: Business Case and options
he Business ase ust contain just sufficient anage ent infor ation for a funding decision to be ade to
initiate the project. t ust be in a for which is useful throughout the project as a eans of checking whether the
project is giving the appropriate return on invest ent. ypically, the Business ase will contain the infor ation listed
below.
3.4.1 Contents of an Agile Business Case
he following sections are nor ally useful.
Business Vision
This is a short description of:
• The reasons and drivers for the proposed change
• he business, as it will be after the project has co pleted project objective
• he bigger picture and any wider i pact of the project, including links with other initiatives
t is not intended that re uire ents are stated here, although a high level pic ay be included, together with key
objectives. A conte t or scoping diagra illustrating the As s and o Be situation ay be useful.
This is the most stable section of the Business Case as, whatever solution option is chosen, this is the overall reason
and intent for the project.
Options
ifferent options business, technical and financial to achieve the Business ision will have been discussed, especially
during Feasibility. ere each of these options is brie y outlined, along with their costs, benefits, ti escale, key risks,
i pacts and any i portant assu ptions. epending on the scale of the project, its potential business i pact and
investment, each option may need to consider the following, in a way which allows comparison between options:
44
Solution Overview an outline of the proposed solution. he best way to do this is often through diagra s
describing the solution fro a user perspective and or a high level architectural perspective. ey co ponents of
the solution should be distinguished fro optional co ponents, where possible.
Strategic Alignment - the ways in which this solution supports or complies with stated corporate strategies or
progra e level objectives.
osts an ene ts uantitative esti ates of the costs and benefits associated with each of the ajor
deliverables. osts and benefits can be e pressed in ranges based on best case, worst case and e pected case
scenarios, to re ect priorities. Where benefits and costs are not easily uantifiable, these should still be included
and efforts ade to e press the in financial ter s e.g. added job satisfaction ay be uantified by assessing
the reduced recruit ent costs which ay accrue .
At the end of Feasibility, the esti ates for each option need only to be sufficient to allow decision aking and to
justify further investigation of a particular option during Foundations. uring Foundations, the focus will be on
the chosen option, and then ay need to justify the full project or perhaps just a first incre ent.
Investment Appraisal this illustrates likely develop ent costs of the project, and the ongoing costs of running
the resulting product or service, including operational, aintenance and support costs. hese are apped
against the financial value of the benefits which are e pected to accrue, over a period of ti e.
Investment Risk Assessment -The investment risk assessment is focussed on the risk associated with achieving
the return on invest ent. hese risks ay lie beyond the boundaries of the project.
Key Assumptions, Risks and Dependencies for the Project so e of these ay be specific to particular
options. thers ay be irrespective of which option is chosen.
3.4.2 The Proposed Solution
he option which stands out as the best should be clearly identified, with reasons and reco endations and any
additional infor ation needed to infor decision aking. After Feasibility, the focus will usually ove to the chosen
option. he above infor ation will typically be elaborated further for just the chosen option, for the full project or
perhaps just a first incre ent.
3.5 Involvement of the Agile Roles in the Business Case

he roles discussed below are e plained in hapter 2, along with their position and responsibilities within the
project.
3.5.1 Business Sponsor
he Business ponsor is responsible for the project budget and ensures that the project s objectives are correctly
aligned with strategic objectives. he Business ponsor will approve the project s Business ase and will onitor
the project s continued justification throughout the project, and through to Benefits Assess ent after eploy ent.
3.5.2 Business Visionary
he Business isionary has overall responsibility for the benefits of the project being delivered and is the final
arbiter for prioritisation of the re uire ents. he data upon which the Business ase is developed will largely
be provided by the Business isionary, supported by the Business A bassador s and echnical oordinator. t is
collated and analysed by the Agile BA. he Business isionary can then be seen as al ost a walking Business ase
throughout the project, able to advise on where the best business value is to be found. hey will also be involved
in benefits realisation and assess ent. f their view differs fro the docu ented Business ase, it is likely that the
Business ase needs a review in line with changes in the business environ ent.
3.5.3 Technical Coordinator
The Technical Coordinator is responsible for the technical aspects of the solution architecture, integrity and
feasibility of the volving olution and should be involved in the production of the roject Business ase, supported
by the olution evelop ent ea roles. Although solution architecture is not necessarily described in detail in
the Business ase, a high level structure is often an i portant prere uisite. he echnical oordinator will be
45
AgileBA Handbook
involved in scoping the solution alongside the Business Analyst and providing an initial vision for the architecture and
incre ents of delivery for the product. he technical infrastructure ay also follow a phased approach, based on
the technical infrastructure needed to support the high level re uire ents planned. he echnical oordinator will
also be able to infor the high level cost projections early in the project.
3.5.4 Project Manager
he roject anager , supported by the olution evelop ent ea and project level roles, is responsible for
facilitating the planning of the project and its incre ents, in collaboration with the tea . hese are the high level
plans against which the costs within the Business ase are calculated.
ulated. he is then responsible for facilitating
activity to enable the project to deliver the solution, within the cost and risk para eters outlined.
3.5.5 Agile BA
he Agile BA works closely with the and the whole project tea at all levels. hey will use their process and
data analysis skills to link e pected benefits with re uire ents at all levels throughout the project. hey will work
collaboratively, with the Business isionary in particular, to attach business value to the re uire ents. hey will also
facilitate the prioritisation of the requirements by the business, with appropriate input and advice from the technical
and solution develop ent roles.
he Agile BA ay be involved in the benefits realisation and benefits assess ent activities and ay actively facilitate
these. As the Business ase is being constructed, thought should be given to how benefits will be easured. his
will include the taking of baseline measurements before changing the current processes, so that a “before and after”
co parison is possible.
3.6 Agile Practices and the Business Case

3.6.1 Prioritisation
he Business ase ay e hibit a degree of prioritisation. he business roles can reasonably e pect ore than just
the ust ave re uire ents to be delivered, e cept under the ost challenging of circu stances.
A Business ase is often e pressed in ter s of best case , e pected case and worst case scenarios.
Although a project ay deliver the best case outco e, it is ore realistic to base any uantified invest ent
appraisal on the e pected case, whilst clearly acknowledging that both best and worst case scenarios ay occur. n
reality, what is delivered will typically be so ewhere between best and worst cases. As the project progresses, the
e pected outco e will beco e clearer, allowing the Business ponsor and Business isionary, supported by the
roject anager and the Agile BA, to keep the viability of the project under continual review.
uring the project, both the olution evelop ent ea and those they are delivering to, can be confident that
the ini u sable ubse , at least, will be delivered because of the contingency available fro the
prioritisation of re uire ents. f ust ave re uire ents do not e ceed 6 of the total esti ated effort, the
available contingency should be sufficient to account for the likely degree of inaccuracy of high level esti ates. he
ould aves in particular are seen as contingency, since they are not needed to achieve the e pected level of the
Business ase. reco ends that ust aves do not e ceed 6 of total esti ated effort and that
ould aves constitute about 2 of the total effort.
o oW prioritisation, co bined with i ebo ing, leads to predictability of delivery and therefore greater
confidence in the success of the project. his will either reinforce confidence, if things are going well, or provide an
early warning that so e i portant but not critical re uire ents ay not be et if proble s arise. t can even
ag a failing project early.
he Agile BA should structure the re uire ents to show their priorities, in line with the benefits identified in the
Business ase. By defining re uire ents fro a user perspective, as ser tories hapter 5 and by apping the
stories into hierarchies related to their business value, the effects of descoping any re uire ents can be seen.
3.6.2 Facilitated Workshops
An Agile, collaborative way to build and evolve a Business ase is through the use of Facilitated Workshops
hapter 7 . hese can help to establish a shared vision and to work on the risk, esti ating, planning and benefits
46
realisation with an appropriate group of stakeholders. uring Foundations, participants will be drawn fro project
level roles, olution evelop ent ea roles, and other key stakeholders fro the business and technical areas. t
is also essential to gain input fro those to who the product or service will be delivered consu ers, end users
and those who will support the product of the project in live use service transition and service operation . f
the project is part of a strategic change progra e, and or a business concept docu ent preceded the roject
Business ase, it is essential to have continuity between these and the view to be taken forward by the project.
he Facilitated Workshops needed to build the Business ase ay include isioning and ick off Workshops,
isk dentification, e uire ents efinition and e uire ents rioritisation Workshops. he de onstration of a
olution rototype ay also be the subject of Facilitated Workshops.
ypical techni ues used at these workshops include W and analysis to clarify the vision and identify the
drivers and risks as discussed in hapter 1 .
ich ictures hapter 8 and Futurespectives hapter 7 help stakeholders to visualise the desired outco e and
goals of the project. hey can also be used when planning at a high level to identify incre ental ilestones, risks
and barriers to success.
3.6.3 Modelling and Prototyping
ffective co unication and sharing of the key ele ents of the Business ase are essential for the success of the
project. odelling hapter 8 is i portant in achieving this. A onte t iagra or coping iagra will help
to clarify what is within the scope of the project. i ple but powerful Agile techni ues for establishing ele ents
of a Business ase and creating a shared vision are the ean anvas and the roduct ision Bo respectively
hapter 8 . his ay be done at Feasibility, and again in ore detail during Foundations. pectations need to be
managed with care as the eventual solution may vary considerably from early prototypes, as iterative development
progresses during the project. owever, a prototype can prove a useful basis for discussion and for identification of
needs.
3.6.4 Iterative Development
terative evelop ent allows evolution of the solution, whilst keeping focus on the business benefits e pected
within the Business ase. he iterative approach e tends to the Business ase itself, in that it is allowed to evolve.
bjectives will be stated up front, with detail e erging later rather than sooner. Additionally, the accrual of benefits
ay be planned to be incre ental, with accrued benefits being incorporated into the invest ent appraisal. arly
benefits realised ay be used to help to pay for later solution develop ent incre ents.
3.7 Summary
A clear and shared Business ase is an i portant guiding in uence for any change project. A visible and
collaboratively produced Business ase is the driver for the Agile project. t should follow a defined for at which
will best support the decision makers, presenting them with measurable recommendations, whilst leaving low-level
detail to evolve as the project progresses. All parties, including those decision akers who will not be an integral
part of the project, need to be aware of the Business ase.
he Business ase should define when and how benefits will be easured and should identify actions re uired
during the project to support the delivery of those benefits.
he Business ase needs to re ain active and visible to both project level and olution evelop ent ea
roles regularly throughout the project, giving focus to each i ebo planning session and acting as a guide to
eploy ent. t also needs to e body sufficient e ibility to enable learning and acco odate a changing business
environ ent.
he Business ase is the bench ark against which the success of the project is easured and is used at key points
to justify whether the project should continue or be closed.
he roles and key practices support the develop ent of a robust, e ible and visible Business ase, to
gain buy in and to create a shared vision which will benefit the project throughout its life and through to benefits
realisation.
47
AgileBA Handbook
48
4. Stakeholders in
the Agile Project
491
1 1
Stakeholders in the Agile Project
AgileBA Handbook
4.1 Introduction
eople working together effectively are the basis of any successful project. n an Agile project, the business interests
and end user needs are fully represented within the project tea , alongside the technical and solution develop ent
skills. Work is carried out as a cross functional tea and gives clear role definitions for this tea . hese
roles have specific project responsibilities and need to have ti e allocated as resources of the project. ually,
those who will deploy and support the solution after deployment need to understand the Agile approach and be
available within specified i ebo es, to support the Agile tea .
The engagement of a cross-functional team is fundamental to the Agile approaches and built into the Agile
Manifesto, in the principles:
• ur highest priority is to satisfy the custo er through early and continuous delivery of valuable incre ents of
the solution]
• Business people and developers ust work together daily throughout the project
It supports the DSDM principles:
• Focus on the business need
• Collaborate
• Communicate continuously and clearly
his chapter looks at what stakeholders are and how they are affected by an Agile project. t identifies different
categories of stakeholder, how to work with stakeholders in an Agile project and the Agile behaviours e pected
fro the in support of the project. Finally, it considers the Agile BA s role in interacting with stakeholders both
within, and e ternal to, the Agile tea . he Agile practices that can help with this are described.
4.2 What is a Stakeholder?

A takeholder is an individual, or a group, with a stake or vested interest in the success or failure of an activity in
this case, a project . his includes anyone, or any group, that is potentially i pacted by the outco e of the project
or its activities. ence stakeholders include the holders of the roles within the project, as well as the wider group
affected by it.
he stakeholders of a project can be broadly categorised as
Project Stakeholders those specifically engaged within the project, for e a ple roject anager, Agile BA,
Business Ambassador, Solution Developer, Solution Tester, Team Leader, Technical Advisor, Business Advisor,
Business Sponsor, Business Visionary and Technical Coordinator
Business Stakeholders those working within the organisation sponsoring the project, for e a ple corporate
anage ent, subject atter e perts, depart ental anagers, end users, auditors, business relationship
anagers, custo er account anagers and service anagers. hese include Business A bassadors, Business
Advisors, Business ponsors and Business isionaries who are also roject takeholders
External Stakeholders those outside the boundaries of the organisation sponsoring the project, but affected by
or able to affect the project or its outco e for e a ple custo ers, suppliers, co petitors, partners, industry
regulators, e ternal auditors, industry professional bodies, trade associations. o e of these ay be roject
takeholders too, for e a ple suppliers who are also olution evelopers or olution esters.
identifies the key roject takeholders and the responsibilities of those ost closely associated with the
project. hapter 2 discusses the roles and responsibilities within a Agile project in ore detail.
n an Agile project, it is reco ended that all roles in the structure are covered, although it is not
necessary for each to be held by a different individual. ertain roles which ay, prior to Agile working, have been
considered in our earlier definitions to be ternal or Business takeholders ay now be found to be also roject
takeholders, thereby beco ing part of the one tea culture of the Agile project.
50
4.3 Agile Culture and Stakeholder Engagement
Agile is a culture of trust and partnership. his is often a significant change of indset for stakeholders who have
previously e perienced a traditional, and particularly waterfall, environ ent. n an Agile project, stakeholders will
find
• More transparency of process; less physical documentation
• More frequent delivery of working product; less detailed analysis up front
• More facilitated workshops, iterative development and demonstrations of the product; fewer large, unstructured
meetings
• ore face to face co unication, odelling and prototyping less detailed, te tual docu entation
• A different empowerment level for the Solution Development Team; different levels of engagement with the
project level, senior roles
• A different way of engaging with a wider group of stakeholders
With Agile, detailed re uire ents e erge as the project progresses. he project tea learns as it goes and
e braces change. o acco odate this, low level re uire ents detail is not specified up front, but later, just before
the re uire ent is built into the solution.
Stakeholders also need to understand that not all of their envisaged requirements will necessarily be delivered
in the first incre ent, and that prioritisation and e ibility is e pected fro the . his deal is brokered by the
pro ise that an agreed ini u sable ubse will be delivered by an agreed date and that business value will be
realised as early and fre uently as possible. his can be uite a culture change for so e stakeholders to accept, but
the benefits to the of working this way should far outweigh any perceived disadvantages.
o e of this culture change re uires a very high level of trust. With reduced docu entation, there ay be
uncertainty that people will do what they have pro ised. Will the olution evelop ent ea only do the
ini u rust ust be earned by the acknowledge ent and acceptance of personal responsibility by project
personnel, to ensure the right project outco e. he early delivery of incre ents of business valuable product
should build confidence by showing that real progress is being ade. he Agile tea delivers value early. he risk
of delivering the wrong solution, or of late delivery, is lower than in a traditional, waterfall style approach. f they fail,
the failure is visible early, which eans the organisation has greater control over invest ent. he early recognition
of potential failure also gives the opportunity to discover a way to change course and turn potential failure into
success.
he Agile way of working will be a challenge to the culture of any organisations. he Agile BA needs to
acknowledge this change of culture, prepare people for it and guide stakeholders through the new territory.
51
AgileBA Handbook
4.4 Working with Project Stakeholders (the Agile Roles)

he Agile BA role works at both the roject evel and the olution evelop ent ea level, facilitating
co unications and anaging the re uire ents process.
Business
Sponsor
Project Level
Business Project Technical

Visionary Manager Coordinator
Technical Business Business

Advisor Analyst Advisor
Solution Development Team
ti n g
Team
S u p p o rti n
Business Solution
Ambassador Leader Developer
Sup p or
g
Solution
Tester
Workshop DSDM
Facilitator Coach
Figure 4a: The DSDM tea
4.4.1 The project-level roles

4.4.1.1 Business Sponsor and Business Visionary
he Business ponsor assures the continued justification for the project, via the Business ase. he Business
isionary ensures appropriate re uire ents prioritisation and the delivery of business value. he evolving nature of
the re uire ents detail, plus the prioritisation of re uire ents will i pact the Business ase. he Agile BA works
with the Business Visionary to ensure that the impact of the continued evolution of requirements on the Business
ase is fully appreciated.
52
he Agile BA is one of the project s ain links to the organisation and business as usual , providing support to
the Business Sponsor and Business Visionary by applying their skills in business analysis such as business process
odelling, value chain apping hapter 1 and Business o ain odelling hapter 8 as well as facilitation skills.
For the Business ponsor and Business isionary, the key essages that the Agile BA needs to co unicate to
the relate to prioritisation and, alongside the roject anager, to planning and e power ent
• hey need to understand the benefits, i plications and i pacts of o oW prioritisation. lear prioritisation
of the essential features will protect these and help to ensure that they are delivered within a given timeframe
• he idea of planning in detail just one incre ent ahead, rather than the whole project plan being presented in
detail at the start, ay see risky to senior anage ent. t needs to be de onstrated to the that fre uent
deliveries and close business involve ent itigate this risk, and the e ibility they gain is a positive for the
• They need to appreciate the effectiveness of empowering Business Ambassadors and indeed all of the Solution
Development Team roles in producing a timely and effective solution
he Business ponsor will find they need to truly cha pion the Agile project, and be appropriately available and
supportive. he nature of issues brought to the eans that any link with the Agile BA is usually in conjunction
with the roject anager.
he Business isionary will find that they are e pected to participate regularly in the project, in any workshops,
de onstrations and reviews and to ake key decisions about priorities. ence the Agile BA will liaise regularly
with the Business isionary.
4.4.1.2 Technical Coordinator
The Agile BA will work closely with the Technical Coordinator to turn the business requirements into solution
re uire ents, both in Foundations and during the i ebo es. he re uire ents specified in the rioritised
e uire ents ist will be business re uire ents, kept at the level of what is re uired rather than how
it will be achieved as far as possible, to allow a i u e ibility and creativity when entering i ebo es.
owever, esti ates need to be infor ed by knowledge of the intended or e pected solution. hus, the echnical
oordinator will work with the Agile BA to create and evolve the olution Architecture efinition based on the
business re uire ents.
At both Feasibility and Foundations, prototypes ay be built to indicate the vision of the future solution. nce
again, this re uires collaboration of both Agile BA and echnical oordinator.
4.4.1.3 The Project Manager
he roject anager and Agile BA work closely together to enable effective stakeholder analysis and engage ent.
heir indsets are so ewhat different the roject anager is focused on anaging the working environ ent to
deliver on ti e and on budget, whilst the Agile BA s ain focus is on the enable ent of business value. f these
two roles work well together, they address all facets of the triangle features, cost, ti e and uality.
The Agile BA will:
• se business analysis techni ues to aid the roject anager and the project level roles in the identification of
stakeholders, analysis of their roles and the design of appropriate co unications with the which ay be
infor al as well as for al, and will not necessarily be achieved by docu ents
• nsure that the Business ase accounts for changing re uire ents, prioritisation and incre ental delivery. hey
will also identify how benefits can be achieved, easured and assessed incre entally. ost project, they typically
have an involve ent in evaluating the benefits as they are realised
4.4.2 The Solution Development Team Roles

4.4.2.1 The Business Ambassador
Business A bassadors are the e powered day to day representatives of a business area. n a tea , they
will find that they are e pected to participate actively and regularly, as e powered e bers of the tea . heir
co it ent to the project is i perative and has any i plications
53
AgileBA Handbook
• They have regular, day-to-day contact with the development and testing of their emerging product, throughout
the project
• They have control over the prioritisation of features for their area and level of empowerment, from a business
point of view
• hey will collaborate on, and in uence the design, appearance and perfor ance of their product
• hey have a role in anaging the e pectations of their peer group in their business areas, and also ensuring their
peers are trained and prepared for the deploy ent, in incre ents, of the volving olution
• hey will be e pected to give significant ti e to the project and be ready to ake decisions on behalf of their
area. n order to achieve this, they need to be correctly e powered by their line anagers to carry out the
project role. hey also need to be consistently resourced to the project i.e. not issing fro the project, or
substituted when the day job is prioritised . o enable this, their business as usual role ay periodically need to
be covered back filled by others, to allow ti e for their project role to be sustained
• he e power ent of the Business A bassador s and their changed way of working throughout the project
re uires a significant co it ent of business ti e fro so eone who is, by definition, a very valuable person
in the day to day work of the business. he benefits to the business of providing the right person is that they
will deliver greater business value fro the project and aintain business control over what is delivered and the
sequence of delivery
he Agile BA will give significant support to the Business A bassador s in the fulfil ent of their responsibilities
and facilitate co unication within the olution evelop ent ea .
4.4.2.2 Team Leader
he Agile BA works with the ea eader to facilitate the work of the olution evelop ent ea . t ay be that,
in so e i ebo es, the Agile BA is a good choice for the role of ea eader.
The Team Leader will:
• Be involved in i ebo planning sessions, keeping the olution evelop ent ea focused on delivering
business value in every i ebo
• nsure that i ebo planning allows for reviews, de onstrations and active, hands on prototyping within
the i ebo es, and involves a wider group of stakeholders beyond the olution evelop ent ea , when
appropriate
• Facilitate aily tand ups, i ebo planning and possibly the i ebo etrospectives
If the Agile BA is not the Team Leader, they will need to support the person who holds that role in maintaining the
tea s focus on the business need.
4.4.2.3 Solution Developers
The Solution Developer works closely with the Agile BA, Business Ambassador and Solution Tester roles within the
olution evelop ent ea . ogether they evolve the detail of the solution in line with the high level re uire ents
of the rioritised e uire ents ist established during Foundations.
4.4.2.4 Solution Testers
The Solution Tester is an active member of the Solution Development Team, working collaboratively with Solution
eveloper, Agile BA and Business A bassador. n an Agile project, testing is throughout the lifecycle. he Agile
BA will work closely with the olution ester during i ebo es, assisting the through the detailed re uire ents
elicitation, analysis and validation activity as re uired. he olution ester, Agile BA and Business A bassador will
work to establish clear Acceptance riteria for the re uire ents. he olution ester will work alongside the other
Solution Development Team members, designing the tests whilst development of a particular feature is occurring
and testing the e erging ele ents as soon as possible.
54
4.4.2.5 Working together
All of the olution evelop ent ea roles need to work together collaboratively throughout the i ebo es.
The Solution Tester and Agile BA will help the Business Ambassador to identify Acceptance Criteria for each of the
requirements; the Solution Developer will work with the Business Ambassador and Agile BA on the emerging detail
of the solution the Agile BA will highlight the i plications of solution choices and work to a i ise the business
value being delivered.
Business Sponsor Business Ambassador

Business Visionary (Marketing)
Technical Coordinator Business Ambassador
(Accounts)
working together
Solution
Developer(s)
Project Manager /
Team Leader
Agile BA
Solution Tester(s)
Technical Advisor
(Release Management)
Figure 4b: An example of a DSDM team working together
4.4.3 Supporting Roles

4.4.3.1 Business Advisors
Many Business Stakeholders who are not empowered members of the Solution Development Team, will be asked
to give ti e to the Agile project. hese are the Business Advisors. hey ay 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 volving olution. his has several i plications.
The Agile BA may:
• elp to anage the e pectations of the Business Advisors regarding their level of e power ent and what the
solution will be. hey will support the Business A bassadors decisions, which ay so eti es differ fro the
opinions of individual Business Advisors
• rganise, and often facilitate, workshops to gather wider input and pro ote collaboration. Business Advisors
may be participants in these workshops
• rganise presentations, prototype de onstrations and reviews of the e erging product, engaging the wider
group of stakeholders
• Work with Business Advisors, engaged for particular purposes and often short periods, in the work of the
Solution Development Team and in the team conversations as appropriate
he Agile BA will liaise closely with the Business isionary, roject anager and ea eader regarding the
involve ent of the wider stakeholder group.
55
AgileBA Handbook
4.4.3.2 Technical Advisors

Many technical stakeholders who are not empowered members of the Solution Development Team, may be asked
to give ti e to the Agile project. hese ay provide specific technical e pertise, for e a ple, or ay represent the
support of the product or service once it is in operation e.g. ervice ransition, elease anage ent and ervice
peration. he Agile BA should engage with these echnical Advisors and ensure their collaborative input. he
Agile BA understands both the “As Is” and “To Be” situations, and can bridge the gap between the current systems
and the new.
4.4.3.3 Facilitator and DSDM Coach
wo additional supporting roles are specified Facilitator and oach. he Agile BA ay cover the role of
Facilitator so e of the ti e. 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 ay be needed. his ay be covered by a colleague Agile BA with no involve ent in content, or by an
e ternal facilitator as appropriate.
he oach facilitates the project in the effective application of the Fra ework. he Agile BA ay
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 e pected ways of working within a project.
4.5 Working with a Wider Group of Stakeholders

he fact that key stakeholders fro the business and end user co unities will be actively engaged in project
roles means that communication with those roles is good, and they, in turn, can communicate well with those they
represent.
Additionally, and as appropriate, de onstrations, presentations and reviews are organised during i ebo es to
keep the wider co unity of stakeholders infor ed and engaged.
uring develop ent, the definition of ersonas and usto er ourneys hapter 8 keeps the olution
evelop ent ea focused on their target stakeholders for the end product.
he Agile BA has a significant role in pro oting understanding a ongst stakeholders of the Agile way of working.
They may need to handle the risk involved in stakeholders being shown solution prototypes at an early stage of
the project, when they are neither co plete nor robust. pectations need to be anaged and the benefit of
seeing these early prototypes appreciated, whilst understanding that much work needs to be done to complete the
prototyped ele ents.
4.6 Key Elements of the Agile BA’s Work with

Stakeholders
he Agile BA assists in the education of all stakeholders in their new Agile roles, supporting the roject anager,
ea eader and oach in this. hey also need to ensure that senior anage ent is aware of the
i plications of Agile. At all ti es, the Agile BA is not a sole conduit of infor ation but they will facilitate
conversations between different stakeholders. hey strengthen the link between the project world and the
organisation s ongoing business as usual activities. n doing this, the Agile BA assists the project in re aining
focused on current and e erging strategic needs of the organisation.
56
4.7 Stakeholder Analysis Techniques
4.7.1 RACI and RASCI Matrices
A traditional stakeholder analysis will often analyse the type and depth of involve ent of stakeholders, using A
or A atrices, to record those esponsible, Accountable, upporting , onsulted and nfor ed within the
project. hese ay still be valuable in an Agile project, but care ust be e ercised, as the different levels of
e power ent, and the collaborative nature of working need to be recognised.
Stakeholders
Branch Manager
Identity Service
Credit Agency
Head Office
Customer
Teller
Task
Pay in cash R A C I
Open Account R A C I
Close Account R A C I
Settle Transactions I A R
Agree Loan R A C C
Do Credit Check C A I I R
Reconcile Transactions I A R
Check Identity C A I I R
R Responsible A Accountable C Consulted I Informed
Figure 4c: RACI matrix
57
AgileBA Handbook
4.7.2 Power/interest grid

his techni ue aps stakeholder interest and power or in uence in a 2 2 grid. his helps to ensure that
the importance of different stakeholders is appreciated and that stakeholders are appropriately involved and
co unicated with during a project. By identifying the levels of power and interest, we ay uncover potential
difficulties, or potential opportunities which ay e ist and re ain unrealised without involve ent of those
stakeholders.
i
eep satis ied losely en a e

n luen e
o er
onitor
eep in ormed
(minimum e ort)
o
nterest
o i
Figure 4d: Power/interest grid
4.8 Communication Planning

he roject anager, in collaboration with the Agile BA, will deter ine strategies for co unicating with
stakeholders and anaging their involve ent throughout the project.
he key factors in co unicating with stakeholders within an Agile project, are
• he types and ti ing of co unication. Agile co unications will typically use the naturally occurring artefacts
of the project and rely less on the production of for al reports. his includes using Workshops, aily tand up
eetings, rototyping, e onstrations and etrospectives plus the ea Boards also known as nfor ation
adiators, anban Boards or Big isible harts B s used by the olution evelop ent ea . Any interested
stakeholder is encouraged to attend the Solution Development Team’s Daily Stand-up meetings to observe
project progress rather than e pect to receive written progress reports
• he types and levels of involve ent e pected fro so e stakeholders are different, as described earlier. he
significant ti e co it ent, particularly for the Business A bassador role needs to be e plained and agreed
and their ode of working with the olution evelop ent ea e plained
• The levels of empowerment of stakeholders, particularly the roles within the Solution Development Team, are
typically greater than in other approaches
58
4.9 Successful Agile Stakeholder Engagement
Stakeholders new to the Agile way of working will need education, training and ongoing support, at a level
appropriate to their role and involve ent in the project.
roject stakeholders need to understand their level of e power ent and they need to know that the environ ent
is safe to e ercise this e power ent.
roject stakeholders ust be properly assigned to the Agile project for an appropriate proportion of their ti e
and, if this is significant, their involve ent should be re ected in their perfor ance targets. he ti e re uired on
Agile projects for user representatives cannot be just fitted in .
roject takeholders need trust and support fro their anagers and fro peers on whose behalf they operate.
All stakeholders need to know the importance of giving time for reviews, demonstrations, workshops and
uestions.
The Business Advisor and Business Ambassador roles in particular need to be understood widely by the rest of the
olution evelop ent ea , and the wider stakeholder group.
Within the Solution Development Team, the stakeholders, including the Agile BA, need to respect each other's
professional skills. he different skills represented in the tea ust work very closely together, with no us and
the attitudes all skills need to work towards a one tea success culture. his i plies true partnership and
collaboration, even between different organisations, custo ers and suppliers. here needs to be a supportive
co ercial relationship and any contracts, internal or e ternal to the business, ust be built to support this.
4.10 Summary
ffective stakeholder engage ent is an essential part of any project, and can ake a significant difference to the
success of the project. takeholders should be identified as early as possible in the project.
takeholders can be identified fro inside the organisation or e ternal to it. hey can then be classified according
to their involve ent in the project and assessed according to their interest and willingness to engage in the project,
and on their potential in uence power over it.
takeholders fro the business will find the Agile project a very different e perience fro the involve ent they
ay have had in traditional projects in the past. t will also be a very different way of working for so e developers
and testers.
Stakeholders may require education, training, support and coaching to enable them to work together effectively as
a tea . he Agile BA can be the facilitator of effective co unication in all of these areas.
59
AgileBA Handbook
60
5. Requirements and
User Stories
611
1 1
Requirements and User Stories
AgileBA Handbook
5.1 Introduction
his chapter defines what re uire ents are, distinguishes between different categories of re uire ent and
describes the widely used Agile techni ue of ser tories. e uire ents are traced through the project life cycle
fro high level he es and pics to the ore detailed ser tories. he chapter ends with so e re uire ents
tips for the Agile BA.
5.2 The Problem of Requirements

efining a full and detailed set of re uire ents too early in a project often proves to be restrictive and wasteful. A
project tea cannot know all of the detail at the outset. hey learn as they go. oreover, the business environ ent
ay change as ti e progresses new re uire ents and opportunities ay present the selves.
he Agile approach to re uire ents acknowledges this dile a and proposes a better way of working.
advises the capture of re uire ents at a high level, early in the project. Further detail is gradually elicited as
the project progresses, deliberately leaving the finer details until as late as practicable, i.e. until volutionary
evelop ent.
5.3 What is a Requirement?

At its si plest, a re uire ent is a service, function or feature that so eone needs. e uire ents can also be
constraints, business rules or other ele ents that ust be present to achieve its intended purpose.
For e a ple, in a training co pany with its own training centre
• The Course Manager has a requirement to schedule training courses and reserve rooms, in order to make
available courses visible and to ensure courses run effectively
• The Training Centre Manager has a requirement to keep track of what training is running, in order to ensure
appropriate allocation of trainers to courses
• he Financial Accountant has a re uire ent to a i ise the a ount of ti e that the training roo s are in use,
in order to a i ise revenue fro the roo s
If the product to be delivered is a custom-built car, the requirements which led to this would have been more
feature-based:
A means of propulsion
A maintainable steering capability
A comfortable place to sit
owever, it should be noted that the following are not re uire ents, but solutions
• An engine
• A steering wheel
• Bucket seats
he ai of the Agile BA should be to ensure that re uire ents are e pressed in a anner which avoids tying the
to a particular solution for as long as possible. his is because ore e ibility can be retained in how a solution
is eventually provided if re uire ents are e pressed as what needs to be achieved, rather than how they will be
technically et e.g. a eans of propulsion , rather than an engine . A solution e pressed too early ay beco e
a constraint on what can be achieved within ti e and budget.
5.3.1 Categories of requirement
e uire ents are often classified into four categories
• eneral Business e uire ents B s
• echnical olicy e uire ents s
62
• Functional e uire ents F s
• on functional e uire ents F s
Business Solution
General Functional
RULES (Solution) WHAT?
(Business)
Technical Non-functional HOW

CONSTRAINTS (Business) (Solution) WELL?
Figure 5a: Categor
eneral Business and echnical olicy re uire ents are co pany wide and in uence all projects as constraints and
rules. Functional and non functional re uire ents relate to the solution which is to be created and are within a
particular project.
enera usiness e uire ents ( s)
eneral Business e uire ents are the rules that all projects ust adhere to e.g. business policies, legal constraints,
regulatory guidelines.
echnica Po ic e uire ents ( P s)
echnical olicy e uire ents are the technical and infrastructure policies and standards that any solution proposed
ust adhere to e.g. hardware and software platfor , network conventions, service strategy and design.
unctiona e uire ents ( s)
un tional requirement
WHAT?  at t e requirement ill do
or t e usiness
on un tional requirement
HOW
WELL?  onstraints on t e system
 er orman e measures
63
AgileBA Handbook
Functional e uire ents e press function or feature and define what is re uired e.g.
• R1 “Visit customer site”
• R2 “Obtain conference venue”
The requirements do not state how
ow a solution will be physically achieved, such as:
• “Drive to customer site”
• “Build conference centre”
“Drive to customer site” is one possible solution. owever, y to customer site or “travel by train” are possible
alternative solutions which ay be worth consideration. For “Build a conference centre”, “Hire a hotel room” is an
alternative solution which ay be ore cost effective. tating re uire ents as what rather than how ow early in the
project allows roo for e ibility and innovation later.
on unctiona e uire ents ( s)
on functional e uire ents define how well, or to what level, perfor ance needs to be provided. hey describe
solution attributes such as security, reliability, aintainability, availability and any other ...ilities , perfor ance and
response ti e, e.g.
• Responds within 2 seconds
• Available 24 hours per day, every day
hese F s ay be
• solution wide or ay i pact a group of functional re uire ents e.g.
- “all customer facing functionality must carry the company logo”
- “all customer-facing functionality must respond within 2 seconds to requests”
• related to a particular functional re uire ent. e.g.
- “hire Conference Venue” ight have F s of Accessibility, ecurity, and Availability
5.4 User Stories

5.4.1 What is a User Story?
A ser tory is a re uire ent e pressed fro the perspective of an end user goal. here is a hierarchy of these
stories as he es, pics and ser tories.
As a.... <role>
I need.... <requirement>
so that.... ene t
Figure 5c: User Story
A ser tory is really just a well e pressed re uire ent. he ser tory for at has beco e the ost popular way
of e pressing re uire ents in Agile for a nu ber of reasons
• it focuses on the viewpoint of a role that will use or be impacted by the solution
• t defines the re uire ent in language that has eaning for that role
• t helps to clarify the true reason for the re uire ent.
• t helps define high level re uire ents without necessarily going into low level detail too early
64
ser goals are identified and the business value of each re uire ent is i ediately considered within the ser
tory. ser stories work well with ersonas , a techni ue described in hapter 8.
ser tories are often dee ed to co prise 3 ele ents he 3 s.
• Card
• Conversation
• onfir ation
The User Story format
A typical for at for the ser tory is as follows
As a <user role>
I need <requirement or feature>
So that goal value
eople will vary this and the advice within the Agile world varies of the for at so eti es the ser tory ay be
e pressed as
• want ... rather than need ...
• need the ability to ...
• the user can ...
ou should choose whichever for at best fits the language of your organisation. ather than worrying too uch
about the specific wording, the focus should be on ensuring that
• it is a real re uire ent that so eone, within the scope of the project, needs
• it is clearly stated in terms that are not too solution-focused and not too vague
• it is clear what business benefit and value it ai s to give
hese two e a ples de onstrate ser tories at different levels, but using the sa e for at
At a project level
As a Marketing Director
I need to improve customer service
So that we retain our customers
At a detailed level:
As an Investor
I need to see a summary of my investment accounts
So that can decide where to focus y attention to a i ise profit.
here is another powerful essage of ser tories. hoosing ser tories to define re uire ents de onstrates
an intention to work collaboratively with the users to discover what they really need. he ser tory is brief and
intended to be so. t is a placeholder for a ore detailed discussion later the onversation. uch of the detail of
ser tories e erges during i ebo es. igh level ser tories pics are broken down into ore detailed ser
tories just before develop ent co ences on that group of stories. ven then, the ser tories are not intended
to be full specifications of the re uire ents. Fine detail of re uire ents ay not need to be written down at all,
but ay si ply be incorporated directly into the solution as part of the work within a i ebo .
he ser tory for at helps to ensure that each re uire ent is captured in a feature oriented, value oriented way,
rather than a solution oriented way.
n projects, ser tories are recorded in a rioritised e uire ents ist . his is the e uivalent of a
roduct Backlog in other Agile approaches. he level of detail held here begins at a high level and increases as the
solution evolves.
65
AgileBA Handbook
Req id Req/Story Req/Story Pry Confirmation Acc Criteria Source Owner Size Business
Short Name Description M, S, S,M, Value
“As a... I need C, W L,XL HML
...so that
STK001 Customer As a M Scenario 1: Security: no Order Order S H
Order Customer, I Customer has unauthorised Clerk Manager
need to place ordered previously: person can place
an order so Given an existing an order at any
that I can customer account, time (24 hours per
have food When Customer day or 24/7/365);
delivered to confirms an order,
my house. Then: can place the
Either: Account order at any time
credit is good, (24 hours per day
Conversation: The order scheduled or 24/7/365);up to
Order Office Manager for delivery and including
emphasised the need Or: Account credit delivery
for secure day and bad, Order is
night ordering rejected and
customer notified.
Figure 5d: A Prioritised Requirements List (PRL)
5.4.2 User Story - the Card

ser tories are often dee ed to co prise 3 ele ents he 3 s.
• Card
• Conversation
• onfir ation
Fro the , ser tories are often printed onto physical cards, for planning purposes and to help the olution
evelop ent ea onitor progress.
he ser tory card has a front and back, as illustrated below.
Project id: Story Story short name: Priority:

number:
Business value:
Story description:
sa
need
n order to
Story size: Conversation: Source:
Related requirements: Owner:
Figure 5e: Front of user story card
66
5.4.2.1 The front of the card

n the front of the card, the following infor ation is typically displayed
• A uni ue tory dentifier , usually a nu ber or reference. his is purely to avoid confusion when there are
many user stories
• A clear, e plicit, short na e or title. his is to ake referencing less a biguous, when the tea discuss a story.
• he ser tory in the for at
- As a <user role>
- I need <requirement>
o that business reason value
• This section states:
who the pri ary stakeholder is the role that derives business benefit fro the story
- what effect the stakeholder wants the story to have
- what business value the stakeholder will derive from this effect
he front of the card ay also have a space for the onversation . his ay include notes, a diagra or
picture, and details fro live discussions. owever, is not intended to record every conversation within the
olution evelop ent ea regarding the ser tory. t can include cross references to other docu ents, if
appropriate, but conversation may not all need to be documented, and face-to-face discussion is the key to good
co unication, not e cessive docu entation.
5.4.2.2 The back of the card
n the back, the onfir ation area contains
• Acceptance riteria the test criteria
Acceptance Criteria
hese are used, after develop ent, to check that the re uire ent represented by the ser tory has been
co pleted satisfactorily. hey define, at a high level, the test criteria which will confir that the ser tory is
Scenarios
working as re uired. hey are not intended to be full test scripts but will be used to e pand into the appropriate
test scenarios and test scripts during i ebo es, as necessary.
Project Id: Story Story Short Name: Event:

• Number:
•
• Confirmation:
AcceptanceCriteria:
unctiona and on unctiona

INVEST
i en When Then
Failure Actions:
Figure 5f: Back of user story card
68 67
AgileBA Handbook
Story Card Example:

tor Identi er STK001
Story Name: Customer Order
Description: As a Customer,
I need to place an order,
So that I can have food delivered to my house.
Conversation: he rder ffice anager emphasised the need for secure day and night ordering
on rmation Acceptance Criteria Examples:
Functional:
- Can I save my order and come back to it later?
- Can I change my order before I pay for it?
- Can I see a running total of the cost of what I have chosen so far?
Non-Functional: availability:
- Can I place an order at any time (24 hours per day or 24/7/365)
- Can I view the order at any time (24 hours per day or 24/7/365) up to and
including delivery?
Non-Functional: security:
- Are unauthorised persons and other customers prevented from viewing my order?
Scenarios
he Acceptance riteria for a ser tory can be e panded to enco pass scenarios, if this is useful, although
the e pansion should not take place until the point in the lifecycle when a greater level of detail is appropriate.
A scenario is a description of a specific case of the ser tory. his techni ue is fro an approach known as
Behaviour riven evelop ent B . ach scenario has the following structure
• i en the initial condition or conditions assu ed to be true at the beginning of the scenario
• When: the event which triggers the start of the scenario
• Then: the e pected outco e, in one or ore clauses
Scenarios are ideally phrased in business language, with no reference to elements of the technical solution
environ ent.
68
Story Card Example, showing 2 Scenarios
tor Identi er STK001
Story Name: Customer Order
Description: As a Customer,
I need to place an order,
So that I can have food delivered to my house
Conversation: he rder ffice anager emphasised the need for secure day and night ordering
on rmation
Scenario 1: Customer has ordered previously:
Given an existing customer account, When ustomer confirms an order, Then:
Either: Account credit is good, order is scheduled for delivery
r ccount credit bad, rder is re ected and customer notified
Scenario 2: other scenarios specified, as re uired.
Acceptance Criteria:
Availability:
- can place an order at any time (24 hours per day or 24/7/365)
- can view the order at any time (24 hours per day or 24/7/365) up to and
including delivery.
Security:
- no unauthorised person or other customer can view the order
5.4.3 Well-constructed User Stories

A good way to write a ser tory is to follow Bill Wake s INVEST odel. tories should be
Independent ser tories should be as independent as possible fro other stories, to allow the to be oved
around with ini al i pact. f user stories are tightly dependent, consider co bining the into a
single user story
Negotiable ser tories are not a contract. hey are placeholders for features which the tea will discuss and
clarify near to the time of development
Valuable ser tories should represent features which are of clear business value to the user or owner of
the solution and should be written in their language. hey should be features, not tasks
Esti able ser tories need to be clear enough to esti ate, without being too detailed
S all ser tories should be s all enough to be esti ated. arger pic stories should be broken down
into s aller user stories as the project progresses. he s all aspect drives the splitting of large
stories into s aller ones. he stories after splitting still follow the criteria
Testable ser tories need to be worded clearly and specifically enough to be testable
A well written ser tory will be clear, concise and co plete. o e si ple checks are
• t does not co bine with, overlap nor con ict with other ser tories
• t confor s to organisational and project standards and policies where applicable
• t is traceable back to the business needs e pressed in the Business ase and project objectives
69
AgileBA Handbook
Where several ser tories relate to the sa e feature, but for different users, they should be cross referenced to
each other.
Where it is useful, the format can be tailored to include:
• ni ue identifier
• Name
• Description
• ource person who identified it
• wner person with responsibility for it
• Business value
• Function process of which the ser tory is a part
• Priority
• ie
• tatus draft, agreed, in progress, done, tested etc
• ependency between ser tories
• ign off responsibility who, how
ot all of this infor ation would typically be printed onto a card, but ay be held in the . preadsheets or
o puter Aided e uire ents ngineering A tools are available to hold the detail of such re uire ents
electronically and to e tract the printed cards for planning.
ertain additional infor ation is useful to hold. For e a ple, it can be invaluable to know the source of the
ser tory which ay be different fro the user stated on the ard . t can be i portant to know the status
whether this story is currently under develop ent, has not been started or has already been i ple ented.
owever, the essage is to keep ser tories as light and si ple as possible, avoiding e cessive docu entation
which beco es out of date and gives no benefit.
5.4.4 Considering the requirements list as a whole
he Agile BA needs to look not just at individual stories, but at the whole set of re uire ents. By doing this,
and with the help of business process odelling and data odelling hapter 8 , they can identify areas where
re uire ents ay have been issed, ay con ict or overlap. hey can work with the Business isionary to
in uence the delivery of groups of re uire ents that give the highest business value early. hey can assist the
olution evelop ent ea and the roject anager to see dependencies, for planning purposes.
n , the is the central record of re uire ents ser tories, together with their priorities and e pected
value. he is an integral planning tool which allows the tea to
• stablish the basis for agree ent between the custo ers and the suppliers on what the outco e of each
incre ent of the project is to be
• Provide a basis for estimating costs and schedules
• rovide a baseline for validation and verification
• Facilitate transfer fro old to new ways of working
• Control and enhance the requirements
• ndicate which re uire ents are anticipated to be handled in which i ebo
he records each re uire ent, e pressed as a ser tory. t holds all re uire ents for the project and the
current incre ent, and the Agile BA will aintain this list, at a level of detail which is useful, but not e cessive, as
further detail e erges.
70
5.5 The Hierarchy of User Stories: Themes, EPICS and User
Stories
n an Agile project, re uire ents evolve. At first, they are very high level state ents of objectives, functions and
areas for investigation. At this point they are classified as he es and pics. ater they are deco posed into the
ore detailed ser tories. he definitions between these levels of ser tory are e plained below.
Business Strategy
Business
Objectives and Themes
Objectives / Goals
Business
Requirements Epic Stories
User
Requirements User Stories
Solution Detailed
Requirements User Stories
Solution
Figure 5g: Hierarchy of requirements from strategy to solution
5.5.1 Themes
he es are a collection of related ser tories and or pics. he es are not, in the selves, ser tories. hey are
categories or headings that can be used to organise stories into any kind of useful, related groupings. For e a ple,
there ay be ser tories which are all part of a particular value strea there ay be groups of ser tories
which together provide the functionality for a release of the solution. t ay be useful to define he es to organise
ser tories for work to be undertaken by different tea s.
a ples of he es could be
• Customer Service
• ser nterface
• Management Information
71
AgileBA Handbook
5.5.2 Epics
When ser tories first begin to e erge early in a project, they are usually large and not well defined. hese
are often ter ed pics . An pic is si ply a story that it is too large to fit into one i ebo for develop ent.
owever, even at this high level, it is still useful to use the for at As a ..., need ..., so that .... because it helps to
keep the focus fro a user point of view and brings out discussion of the e pected benefit.
he Business ision itself for s the first pic story.
For example:
Business Vision:
As a Marketing Director
I need to improve customer service
So that we retain our customers
igh level key Acceptance riteria can also be for ulated for an pic level, to clarify eaning.
For example:
Project Acceptance Criteria:
- Customer retention improved by 20% within two years
- Product range increased by 10% within 5 years
- Speed of dispatch improved to within24 hours of time of order for 99% of in-stock items within 6
months
5.5.3 User Stories

ser tories defined by the end of Foundations in a project ust be specific enough to esti ate and s all
enough to fit into a i ebo typically 2 4 weeks work, or e ceptionally 6 weeks . hey ay then be further sub
divided during development, perhaps to split work between resources, or to allow for estimating, or to facilitate
easure ent of progress or to enable planning. ne danger is that this ay erely beco e a breakdown into
tasks. Where such low level deco position is necessary, the link to the original ser tory should not be lost. t
is best if the link to the original ser tory is visually presented, so that the user perspective and focus on business
benefit is not lost. his can be achieved by using tory aps.
5.5.4 Story Maps and the hierarchy of requirements
ser tories are captured at different levels of detail. As the ser tories are broken down, the hierarchy needs to
be kept visible, to ensure that their relationships to each other and with the Business ision are clear. he Agile BA
can do this by building a tory ap. his is a visible odel of the whole re uire ents set, usually for one incre ent
of develop ent at a ti e. t is achieved by displaying individual story cards in groups, preferably on a wall, in a way
which is visible to the whole tea .
his techni ue is further described in hapter 8.
72
Manage Manage
Epics Provide Provide
Payments House-
Room Meals
and Debts keeping
User
Stories
Detailed
User
Stories
Figure 5h: Story ma
5.5.5 Impact Mapping

Another powerful way of visualising the whole set of ser tories is to build an pact ap. his visually presents
ser tories fro the highest to the lowest level and is si ilar to a tory ap, but with a value i pact focus. he
advice for building an Impact Map is:
• tart with the project s goal, and ap pic stories to it
• ap lower level ser tories to the pics to which they contribute
• alidate e erging ser tories against the project goal. Ask whether they add value to it, and if not, should they
be descoped nsure that the focus is on those ser tories that contribute to the project goal
• stablish easurable etrics for ser tories at all levels, to easure progress and success
his techni ue is also included in hapter 8.
Increase the number of

paying delegates on courses Business Goal
by 100% within 1 year Why
Individuals;
Training Managers Actors
Who
People will book

Other Actors more courses Impacts
Ho eha iour i change
Better course booking Deliverables

Other ways to system on website What
change the behaviour?
Figure 5i: Impact mapping
73
AgileBA Handbook
5.6 Requirements through the DSDM Lifecycle

rojects need
• A clear project objective
• A statement of the Business Vision
• A Business Case, agreed with key stakeholders
These form the anchor for the deliberate evolution of the more detailed requirements, iteratively and incrementally,
as the project progresses. As the hierarchy of re uire ents e erges in e panding detail, as the project unfolds,
each re uire ent ser tory can always be traced back to this original vision, as it evolves to eet the real and
current business needs.
ery i evel
Requirements
re ro e t
( e tives and emes)
i evel rioritised
easi ility Requirements
(Epi s and User Stories)
oundations
Evolutionary
Development
ssem le
Revie
Deploy
Deployment
Detailed Requirements ost ro e t

(Detailed User Stories)
Figure 5j: The DSDM process showing requirements evolving
5.6.1 Requirements Activity during Feasibility

All projects begin with an idea and an e pectation of benefits to give a return on invest ent. he Agile BA ensures
that the er s of eference which is so eti es vague and unclear is e panded to provide a clear project
objective, a Business ision and an utline Business ase. he project vision is clarified and key project objectives
are defined. he highest level pic ser tory is the objective of the project. he ser tory for at can be
effectively used to clarify:
• Who needs this o we have the right Business ponsor
• Why do they need it What is the key business value e pected or needed
• What are their e pectations What are the high level acceptance criteria
he ser tory for at also helps to identify the key stakeholders with who to gain agree ent for the
re uire ents.
n Feasibility, the ser tories e pressed as pics or he es should constitute a s all nu ber of clear state ents
that are just sufficient to scope the project, to identify whether it is worth proceeding further and to establish likely
costs and benefits achievable. reco ends typically less than 1 re uire ents ser stories at this point.
74
on functional re uire ents perfor ance attributes and constraints ay also e erge at this point, but these are
e pected to beco e clearer and ore detailed throughout the project. ject. o e of the ore critical ones ay be
evident from the outset, when the Business Vision is established, and these need to be captured because they may
constrain so e of the choices for the project. .
ven at this high level, ser tories help to focus on the value of what is re uired. onsider the following pic.
For example:
“As a Human Resources Manager, I need a better way to deal with employee records, so that employee
history can be tracked including their training and career moves.”
This is more effective than the business-vague, but technically constraining statement:
“The organisation will implement a human resources system.”
he ser tory for at helps to bring out the real objectives of a ajor change.
5.6.2 Requirements activity during Foundations
uring Foundations, ore understanding of the re uire ents is needed, sufficient to clarify the scope of the
project, prioritise, esti ate and for ulate a realistic elivery lan.
ser tories defined by the end of Foundations ust be specific enough to esti ate and s all enough to fit
several ser tories into a i ebo typically 2 4 weeks . his is not the lowest level of breakdown that the project
will achieve, but by the end of Foundations, ser tories need to be just sufficient to allow for esti ates of work to
be done and to plan a schedule of i ebo es for the roject ncre ent .
At Foundations, ser tories are asse bled into a rioritised e uire ents ist . he focus should be on
describing the business need e bodied in each ser tory, in a way which does not constrain unnecessarily how
the re uire ent will be achieved.
ey non functional, general and technical re uire ents see earlier should also be considered and docu ented
during Foundations. t ay be difficult or i possible to acco odate such re uire ents, if they are discovered too
late in the project.
he is baselined at Foundations, to give a clear checkpoint for the set of re uire ents which was used for
planning. n this way, new re uire ents which e erge during develop ent are clearly identified, and their i pact
can be assessed.
uring Foundations, the Agile BA ay establish a high level odel for the structure of the business processes and
data see odelling hapter 8 and use this to create tory aps and pact aps and to group ser tories into
he es, where these are helpful.
5.6.3 Requirements Activity during Evolutionary Development
At the outset of each i ebo , the ser tories allocated to that i ebo during Foundations will be further
investigated. he ser tories fro the are broken down into ore detailed ser tories which are s all
and clear enough for the tea to work fro . he detail is only elaborated one i ebo at a ti e, and thus the
co ple ity of the re uire ents is anaged. Also, the fine detail is only elicited i ediately before that ele ent
of the solution is created. his avoids ti e being wasted on developing all areas of detail up front, only to find that
so e are de scoped or subject to change as the project progresses.
esses.
uring i ebo es, the detailed re uire ents ser tories e erge iteratively. he Agile BA captures the
appropriate levels of e erging detail within the , where not ade uately captured within test criteria, prototypes
and the volving olution itself. he Agile BA also works collaboratively with both olution evelop ent ea and
project level roles to retain the project s focus on value and priorities.
ew re uire ents ay e erge which were not identified during Foundations. he Agile BA facilitates the
consideration and i pact analysis of these and records their inclusion or otherwise in the project based on
75
AgileBA Handbook
discussions with the Business A bassador, the rest of the olution evelop ent ea and or Business isionary.
The Agile BA will record details of, and reasons for, any lower priority requirements which are descoped by team
agree ent during volutionary evelop ent.
5.7 The Agile BA and the PRL

he Agile BA evolves the , working closely with the Business isionary and Business A bassadors throughout
the project. Although the Agile BA typically produces the , the re uire ents it contains are approved by the
Business isionary, in line with the Business ision. he business analysis skills of the Agile BA are key in aintaining
the uality, co pleteness and consistency of the , keeping it up to date throughout the project. he should
contain all re uire ents that the project needs to address, capturing detail as it e erges and deepens. t needs to
be reviewed and updated throughout the project and possibly reprioritised .
At the end of Foundations, the re uire ents ser tories in the should be baselined agreed . his
agreement, and possibly a formal sign-off, is facilitated by the Agile BA and involves the Business Visionary, Solution
evelop ent ea and other appropriate stakeholders fro the business. his is an i portant echanis to
identify scope creep when new re uire ents e erge during the project. his does not i ply that re uire ents
cannot e erge, or be changed later in the project, but it does ean that any change to the breadth of the
re uire ents is visible and that change can be kept under control.
5.8 Techniques for Eliciting Requirements

n an Agile project, re uire ents can be obtained through a i of techni ues facilitated workshops to gather and
prioritise re uire ents and to conduct odel building sessions happen throughout the project, as re uire ents
evolve fro high level to detailed re uire ents. Focus groups of end users can supple ent this work. licitation
of re uire ents during i ebo es can be achieved by prototyping sessions, to de onstrate potential options and
to clarify the business rules and re uired functionality. As ele ents of the solution e erge iteratively, prototyping
allows usability and perfor ance to be tested and refined, along with other non functional re uire ents.
5.9 The Agile BA Role and Communication of

Requirements
The Agile BA is responsible for ensuring the clarity and completeness of the requirements, individually and as a
whole set, and docu enting these at an appropriate level. Although Agile approaches achieve real benefit by
bringing the business and technical roles closer together, often there remains a communications gap between
the . his ay be due to differences in language and culture or to the viewpoints of individuals, who see their
own area, but not the end to end business process. he Agile BA has business analytical skills, which enable a view
of the i pact of change fro a wider business perspective. nd users ay not have such skills, and ay lack the
perspective within the organisation fro which to view a process end to end.
The Agile BA can:
• Facilitate co unication between the stakeholders at all levels within the project. t is i portant that the BA
does not replace or act as a surrogate for the Business Visionary, Business Ambassadors and other true business
roles, nor act as a barrier to direct communication between them
• Facilitate the co unication of the technical and business roles within the olution evelop ent ea , to
enable all areas to see the full implications of their requirements and highlight dependencies, overlaps and
con icts between re uire ents
• nsure the align ent of e erging re uire ents with both the Business ision for the project and corporate
strategic direction
76
5.10 Hints and Tips for the Agile BA
Since this chapter represents the core of the role of the Agile BA, a collection of some of the key points has been
ade, as a useful checklist when gathering re uire ents.
• enti the ri ht peop e ith ho to co a orate on the capture an c ari cation o re uire ents
the Business isionary ensures that the re uire ents for the project contribute appropriately to the
realisation of the Business Vision and will normally be the best person to clearly articulate the high-
level re uire ents and the benefits e pected
the Business A bassador s and the Business Advisor s are the voices of the real end users of the
solution, and should accurately be able to supply the more detailed requirements
• Focus on the Business Vision and the objective of each increment
ake the Business ision and the objective of each incre ent clearly visible to all of those working
within the project, at all levels
if the objective is rovide day to day re ote support for sales operatives in the field , then speeding
up invoicing is not likely to be important, but information on customers’ past payment records
probably is
• Produce something visible early and keep visibility of the objectives and requirements live, up to date and
clear throughout the project
- produce pictures, diagrams and models to engage all key stakeholders within, and associated with, the
project. se these to help illustrate, co unicate and give conte t to the re uire ents listed in the
- facilitate the running of demonstrations and hands-on prototyping sessions as soon as practicable
• Facilitate and negotiate the prioritisation of all categories of requirements, at all levels as they emerge during
the project
it is never too early or too late to consider and reconsider the priorities
help the tea to define o oW and challenge the priorities to ensure true prioritisation
• Educate the user representatives in the power and practice of User Stories
gain their involve ent in the creation of their own ser tories. se their skills and facilitate the
process. on t leave it to the but e ually, do not do it all on their behalf
- enable the Business Ambassadors and Business Visionary to fully engage in their role with respect to
requirements
• n uence the p annin at a e e s to e i er so ethin o a ue to the usiness ear an incre enta
the ser tory for at will encourage this. he Agile BA s perspective of value chains will infor the
of where value can be added
• Be prepared to iterate
new re uire ents ay need to be incorporated into the solution or the throughout
• Use Facilitated Workshops to gather, prioritise and gain agreement on requirements
- workshops will enable stakeholders to appreciate each other's views and aid in agreement on the
requirements and also their priority
- when initially gathering requirements, it is usually more effective to capture some requirements by
talking with people individually and in s all groups before the first workshop, rather than starting a
workshop from a blank sheet
• Keep a good, consistent record of requirements at the level which is just enough
the includes all re uire ents functions, features, constraints, priorities and acceptance criteria
keep the in a for that is useful for both business and technical staff and ensure that the olution
evelop ent ea and roject evel roles have appropriate access
77
AgileBA Handbook
• Recognise that the apparent composition of the PRL as “All Must Haves” may show the need to decompose
re uire ents urther to isco er their e i i it
for e a ple, a ust ave re uire ent o allow lectronic ay ents ay be deco posed into
various supported payment types and methods, each of which may have a different priority
- when prioritising requirements, be alert to the possibility that a higher level requirement which is
apparently a hould ave or ould ave re uire ent ay have lower level ust ave aspects
which need to be delivered if the higher level requirement is to be realised in a solution
- consider recording different levels of priority against requirements, to indicate their priority for the
project, incre ent and i ebo
• Docu entation shou a a s e ept to the ini u su cient to ena e the re uire ents to e
understood
test acceptance criteria should be defined as each re uire ent is established. o achieve this, the
Agile BA works closely with the Solution Tester, Solution Developer and Business Ambassador
• Documentation needs to be appropriate and accessible
it can be in several for s ser tories, structured te t pictures diagra s odels and also
prototypes
it needs to be anaged throughout the project and cross referenced to allow understanding of
dependencies and links
in larger projects especially, it ay need to be supported by an appropriate specialised software tool.
uch tools are often referred to as o puter Aided e uire ents ngineering A or o puter
Aided oftware ngineering A tools
5.11 Conclusion
This chapter considered the meaning of “requirement”, and the nature of the possible business problems they
address. here are different categories of re uire ent. he Agile techni ue of ser tories provides a useful way
to capture re uire ents and e plore their real eaning in addition to being a convenient and effective way to
break re uire ents down for planning.
e uire ents e erge in increasing detail as the project progresses. ifferent levels of ser tories for a hierarchy
of he es, pics, and ser tories. e uire ents should be e pressed along with their acceptance criteria fro the
outset.
e uire ents ust be focused on the Business ision and that linkage aintained throughout the hierarchy of
e erging re uire ents as they are elicited, further analysed and validated during the project.
e uire ents evolve and e erge in an Agile project. Analysis of the detailed re uire ents is deliberately left as
late as is sensible, to avoid unnecessary rework and to anage co ple ity. Because of this, it is i portant to obtain
agree ent to a high level baselined set of prioritised re uire ents in the . his gives scope, direction and an
appropriate degree of control for the project whilst allowing change to be e braced and controlled.
he Agile BA does not personally generate re uire ents, and is not a substitute or pro y for the real users.
owever, the Agile BA is the ain editor and facilitator of the capture of the right level of clear and appropriate
re uire ents. hey ensure that these are recorded, analysed and prioritised to eet the current business need and
Business ase at all ti es.
78
6. Prioritisation
791
1 1
Prioritisation
AgileBA Handbook
6.1 Introduction
Delivering an agreed outcome by an agreed date without compromising quality may mean that some of the
scope originally envisaged ay have to be left until a later ti e, or even left out co pletely. t is i portant that
the essential features are co pleted, and that they are co pleted to the right uality. owever, delivering late
ay under ine the very rationale of the project, fro a business point of view. t is also essential that if vital
re uire ents e erge late in the project, they can be incorporated without co pro ising the project s ability to
deliver on time, and without forcing the Solution Development Team into an unsustainable pace of work, which in
turn could co pro ise uality. Any descoping or rescoping of the product ust be done with both business and
technical involvement and approval at the right level, and in line with the highest delivery of business value that can
be obtained in the ti e and with the resources available.
hus, effective prioritisation and reprioritisation during a project are key to delivering what is needed within ti e
and cost, and keeping the e ibility to change, without co pro ising uality.
This chapter describes why prioritisation is important and how to achieve it, including using MoSCoW prioritisation,
which was first proposed by as a way of focusing on the ini u sable ubse of re uire ents
whilst planning to deliver considerably ore than just that ini u . ust ave re uire ents can differ depending
upon the objective of the project and ini u does not necessarily ean a bare bones solution. he chapter
includes so e hints and tips for prioritisation.
6.2 What Drives Prioritisation?

e uire ents represent features, functionality or i prove ents that the business really wants. hey ay be
e pressed as ser tories, se ases or ore traditional state ents of re uire ents. owever, as projects are
always under budgetary pressure, it is al ost inevitable that so e re uire ents will not be able to be satisfied
within a specific ti e and budget. ndeed, so e re uire ents ay be inco patible with others and cannot
co e ist. t is part of the Agile BA s role to help the holders of business roles in the project to recognise the
relative importance of their requirements and those of others and to help to establish and maintain a compatible,
achievable and evolving set of re uire ents.
he fact that not all re uire ents identified ay be achievable within a specified ti e and budget re uires a
echanis for establishing, as objectively as possible, the relative i portance of re uire ents and the relative levels
of urgency.
The importance of requirements can be assessed in relation to their contribution to the Business Vision and the
objective of the current incre ent and to the Business ase, while ensuring that they are ulti ately in line with the
organisation s ission and strategy.
The urgency
gency of requirements is also a critical consideration for determining what will be delivered in a current
incre ent and what will be left until a later incre ent. For e a ple, in a project related to a co pany s accounting
syste s, the ability to produce the annual financial reports is a very i portant re uire ent. owever, in a planned
uarterly set of deliveries fro the project, if the co pany s financial year end is ece ber, these reports are
not essential for the arch delivery, nor the ay delivery. hey ay be considered critical in the August delivery,
to ensure ti e to e bed the for the end of the year. he potential business value to be delivered by each
re uire ent ust be taken into account to assess the relative i portance of re uire ents.
6.3 Prioritising Requirements

here are any ways in which prioritisation can be considered. ere are a few co on e a ples
• Assign numbers from 1-5, with 1 being the most important and 5 being the least important
• Assign High, Medium, Low categories
• Assign howstopper, ighly esirable, esirable categories
• ave a list in priority order, with a cut off line below which re uire ents are not scheduled to be addressed
within a current timeframe
80
• o oW prioritisation, representing the categories ust ave, hould ave, ould ave and Won t ave this
time, where the ust have re uire ents represent the ini u sable ubse of re uire ents that would
satisfy the Business Case
A proble e erges with the first four of these prioritisation approaches, in defining what the categories really
ean. What is the difference between a category 1 and a category 2 re uire ent What is the i plication if a
re uire ent categorised as igh is not i ple ented by a certain date oes this ean disappoint ent or is it a
disaster What defines a ighly esirable re uire ent f it is left out, does this only cause disappoint ent or will
the product be unviable without it Will the Business ase be unachievable without it
o avoid a biguity, reco ends o oW prioritisation, representing the categories ust ave, hould
ave, ould ave and Won t ave this time.
6.3.1 Prioritising using MoSCoW
o oW prioritisation is a powerful techni ue for helping stakeholders to understand and clearly define priorities,
with a shared understanding of what the priorities ean. he letters stand for
• Must ave
• Should ave
• Could ave
• Won t ave this ti e
he use of o oW works particularly well on projects. t also overco es the proble s associated with si pler
prioritisation approaches which are on relative priorities.
he specific use of ust ave, hould ave, ould ave and Won t ave this time provides a clear indication of
the i portance of an ite and the e pectations for its co pletion. t is i portant to agree the definitions with
the stakeholders, preferably before re uire ents capture begins, so that decisions can be ade objectively. he
definitions of the levels of o oW should be clarified in relation to each project, to ensure that they ake sense
in conte t. owever, the descriptions below are a good starting point.
6.3.1.1 Must Have
ust ave re uire ents co prise the ini u sable ubse often referred to as the or the of
re uire ents which the project has to deliver to be worthwhile.
he o ission of even one ust ave re uire ent eans that the project has failed to eet its ini u level. n
The reasons for this may be one of the following:
• No point in delivering on the target date without this; if this were not delivered, there would be no point in
deploying the solution on the intended date
• Not legal without it
• nsafe without it
• Cannot deliver a viable solution without it
The Agile BA should ask: “What happens if this requirement is not met?” If the answer is “cancel the project - there is
no point in implementing a solution that does not meet this requirement” then it is a ust ave re uire ent. f there
is some way of delivering an acceptable, viable solution without this requirement, even if it is by providing a manual
and painful workaround, then it is a hould ave or ould ave re uire ent. ategorising a re uire ent as a
hould ave or ould ave does not ean that it won t be delivered si ply that delivery is not guaranteed.
6.3.1.2 Should Have
hould ave re uire ents are defined as
• Important, but not vital
• May be painful to leave out, but the solution is still be viable
• ay need so e kind of workaround, e.g. anage ent of e pectations, so e inefficiency, an e isting solution,
paperwork etc. he workaround ay just be a te porary one
81
Prioritisation
AgileBA Handbook
ne way of differentiating a hould fro a ould ave is by reviewing the degree of pain caused by the
re uire ent not being et, easured in ter s of business value or nu bers of people affected.
6.3.1.3 Could Have
A ould ave re uire ent is defined as
• Wanted or desirable, but less i portant than re uire ents classified as ust ave and hould ave
• ess i pact on the product being delivered if it is left out, co pared with a hould ave or ust ave
These are the requirements that provide the main pool of contingency, since they will only be delivered in their
entirety in the best case scenario. When a proble occurs and the deadline is at risk, one or ore of the ould
aves provide the first choice of what is to be dropped fro this ti efra e.
6.3.1.4 Won’t Have this time
hese are re uire ents which the project tea has agreed will not be delivered as part of this ti efra e .
hey are recorded in the where they help clarify the scope of the project. his avoids the being infor ally
reintroduced at a later date. his also helps to anage e pectations that so e re uire ents will si ply not ake
it into the eployed olution, at least not this ti e around. Won t aves can be very powerful in keeping the focus
at a point in ti e on the ore i portant ould aves, hould aves and particularly the ust aves.
he Agile BA should not si ply delete any re uire ents that were captured and recorded in the at so e
point in the project these should be retained as Won t ave re uire ents and annotated with the reason why they
have been descoped or parked.
6.3.1.5 Business value of Must Have, Should Have and Could Have requirements
he assess ent of business value against ust ave re uire ents is straightforward. By definition, they are
priceless as far as the project is concerned. f they are o itted, the project fails.
Business value starts to have real eaning when considering hould ave and ould ave re uire ents. Whilst
these re uire ents can, by definition, be worked around and o itted fro the current incre ent of the solution,
the negative impact on the people continuing to work without support for them will help to determine their
relative business value. t will also help to deter ine the se uence in which they are addressed, ost i portant
beneficial first although other factors such as dependency will i pact this se uence . he techni ue of pact
apping described in hapter 8 is useful here.
6.3.2 What will be delivered?
t should be clear to all in the project that the intent of prioritisation is to deliver ore than just the ust aves
ini u sable ubse .
A project must deliver all of the ust aves, and then it should plan to deliver as any of the hould ave and
ould ave re uire ents as possible, to the right uality. owever, in the worst possible circu stances, only the
ust aves ay be delivered.
he o oW approach is intended to allow a high degree of confidence in the delivery of at least the ini u
sable ubse of re uire ents. reco ends that ust ave re uire ents should not e ceed 6 of the
esti ated effort, with hould ave and ould ave re uire ents aking up the other 4 .
82
Prioritisation
6.3.1.3 Could Have In scope Out of scope

for this timeframe for this timeframe
•
•
(Project / Increment / Timebox)
Must Have Won’t Have this time
Typically
6.3.1.4 Won’t Have this time no more
than
60% effort
Should Have
6.3.1.5 Business value of Must Have, Should Have and Could Have requirements
Could Have
Typically
around
20% effort
Figure 6a: MoSCoW - balancing priorities
he Business ponsor can reasonably e pect ore than just the ust aves to be delivered, e cept under the
6.3.2 ostWhat
challenging
will of
becircu stances. f hould aves and ould aves are split evenly, then the ust ave and
delivered?
hould aves in co bination, would represent no ore than 8 of the total effort. his allows a good level
of contingency. hus, o oW prioritisation, co bined with retrospection of achieve ent at the end of every
i ebo , allows better predictability of delivery and therefore greater confidence. eeping project etrics to show
the percentage of hould aves and ould aves delivered on each incre ent or i ebo will either reinforce this
confidence, if things are going well, or provide an early warning that so e i portant re uire ents ay not be et.
he Agile BA will work with the rest of the tea to capture appropriate etrics.
82 83
Prioritisation
AgileBA Handbook
6.4 Dependencies Between Requirements

Another di ension which is also i portant is that of grouped and interacting re uire ents. he Agile BA has a
responsibility to ensure that, whilst others in the tea ay beco e very focused on individual re uire ents ser
tories , analysis is carried out for the whole group of re uire ents. o e re uire ents are interdependent, and
so e ay con ict. he techni ue of tory apping, e plained in hapter 8 is useful in bringing together these
related and interdependent re uire ents.
he ust ave re uire ents need to for a coherent solution, even without any of the lower priority
re uire ents. owever, the Agile BA ust deter ine dependencies between the lower priority re uire ents and
the ust ave re uire ents. o eti es a lower priority re uire ent ay need to be included to enable a ust
ave re uire ent to function.
For e ample in a hotel oo in s stem the chec -in process has een classi ed as a M st ave
However, the oom n uiry feature has been classified as a Should Have, since this was deemed
to be a marketing feature which could wait until later.
However, on closer inspection, the room enquiry feature is also integral to allocating rooms on
check-in and so is a Must Have for this purpose..
e uire ents which, on first inspection, see ed to be lower priority ay need to be reclassified as ust aves, to
avoid co pro ising the ust ave re uire ent. rocess apping techni ues using swi lanes show the end to
end ow of the process and can be useful here to highlight such dependencies hapter 8 .
6.5 Prioritisation Using the Kano Model

he Agile BA ust take care when asking people to prioritise. o eti es, the si plest, ini al product is just not
good enough. he Business ase should clearly state the benefits needed fro the project. owever, what is the
ini u acceptable level for a drea house What is needed to ake a top level co puter ga e or a state of
the art perfor ance car
he level of e pectation of the end custo er or user will affect what is acceptable. he following perspectives,
based on the odel proposed by oriaki ano, are useful here.
6.5.1 Will, Want and Wow!
he ano odel takes account of three distinct types of custo er need
• pected which we shall refer to as Will
• or al things people just Want
• citers which give the Wow factor
and two dimensions of value:
• eality this ranges fro a product which does not address the need at all , to a product which addresses
the need well 1
• erception his ranges fro total dissatisfaction negative perception shown as ve on the graph below to
total satisfaction positive perception, shown as ve
ften value to the custo er is as uch about their perception as it is about the reality of the product.
84
Perception (customer satisfaction)
+ve
WOW
Delighters / exciters
Reality (customer expectation)

WANT
0% 100%
Satisfiers
WILL
Dissatisfiers
-ve
Figure 6b: The Kano model
pecte eatures ( i )
custo ers that they will be included. f they are not present in the product, it will cause dissatisfaction and non
acceptance.
owever, they will typically only evoke indifference when they are actually et he custo er s response will be,
“Well, that’s what is expected. It wouldn’t even be a viable product without that.”
hese needs are often just assu ed, and ay be so obvious that they are not even stated. owever, they are
critical to the acceptance of the product. Without the it will be rejected.
Example:
The car will have an engine. It will start.
or a eatures ( ant)
hese are the satisfiers features that need to be present, but they can only satisfy or dissatisfy the custo er with
their presence or absence they cannot be e pected to thrill the custo er.
hese are usually stated by the custo er rather than taken for granted. f they were not stated, their absence will
be recognised the first ti e the custo er sees the product.
Examples:
I want a car with 4 doors, not just two
I want a car with average fuel consumption
85
Prioritisation
AgileBA Handbook
citers ( o )
hese features evoke the highest level of custo er satisfaction and are ter ed elighters or citers . hey
ay not be e pressly stated by the custo er at first, but are ways of thrilling the custo er. hey ay be the very
features which result in the custo er s decision to buy the product.
Examples:
“This car will not need re-fuelling - ever? Wow!”
“This car will never break down? Wow!”
he Agile BA ust be careful in interpreting such re uire ents, as what a a es and delights one custo er ay
leave another co pletely indifferent or even dissatisfied.
Example:
“This car has a speed-limiter for safety, which means it can never be driven faster than the national speed
limit.”
In addition, over time and with the maturity of a product, wows become wants, and wants eventually become wills.
For e a ple, a obile telephone was once a a ing just because it allowed the aking of calls without a wired
connection. As ti e passes, this is just taken for granted, and what were once wow
w features, such as a touch screen,
have beco e nor al.
he ano odel s perspectives can be used very effectively alongside o oW prioritisation, to help to define
what are the real ust ave, hould ave and ould ave re uire ents in relation to the Business ision and the
objective of the incre ent.
6.6 Effective Prioritisation

Priorities should always be decided by the collaboration of appropriate, empowered stakeholders, with reference
to the project s Business ase. he Agile BA does not set the priorities, but is e powered to ask the stakeholders
to e plain their reasons for the priorities they have assigned. Business A bassadors have the e power ent to
decide on the priorities for the areas they represent. he ulti ate decision on priorities lies with the Business
isionary. owever, prioritisation also re uires input fro technical roles, to ensure that the technical i plications
and dependencies are understood.
he o oW priorities provide the basis on which decisions are ade during the whole project and during any
incre ent and any i ebo within the project. igh level re uire ents and their priorities are agreed during
Foundations, and baselined by the end of the Foundations phase. riorities ay need to be reassessed as the
project progresses, based on an increased understanding and the changing business environ ent. herefore,
priorities ust re ain under review throughout the project, to confir that they are still valid. As new
re uire ents arise or as e isting re uire ents are deco posed and defined in ore detail, then o oW
prioritisation of the new and detailed ele ents will be needed. he Agile BA needs to keep a record of both
the changing priorities and reasons for the changes and the hierarchy of priorities which e erges, related to
i ebo es, within an incre ent and within the project.
t is i portant that there is an ongoing and visible high level road ap for develop ent beyond just the current
i ebo and incre ent. t is very hard to obtain any e ibility in prioritisation when a project has budget for only
one incre ent at a ti e. owever, it is sensible to negotiate an incre ental drawdown against an agreed project
budget.
t is essential that not every feature is a ust ave. f everything to be achieved within the project, within an
incre ent or within any i ebo , is a ust ave, there is no e ibility to bring the project back on track if
proble s arise. t is the descoping of these lower priority re uire ents that enables tea s to deliver on ti e even
when proble s arise.
86
etrics should be kept for each i ebo , regarding the proportion of hould ave and ould ave re uire ents
being delivered, in order to have an ongoing predictive estimate of the likely percentage delivery for the whole
project.
It is important to clarify and agree escalation or decision-making processes for prioritisation issues and to agree
the level of e power ent around decision aking about priorities at each level. he olution evelop ent ea
typically has the authority to descope ould ave re uire ents, by agree ent of the tea . owever, the change
of priority of a ust ave re uire ent, or the likelihood of non delivery of ust ave and if necessary hould
ave re uire ents is typically treated as a project escalation issue and has to be referred to the Business isionary
and potentially a wider group of stakeholders for approval.
6.7 Prioritisation throughout the DSDM Lifecycle

6.7.1 Feasibility and Foundations
he gathering of re uire ents starts during Feasibility and Foundations in order to for the that is agreed and
baselined by the end of Foundations, but subject to enhance ent, e pansion of detail and review throughout the
project.
he for s the high level baseline of agreed re uire ents, fro which the project s i ebo es are planned.
f all re uire ents captured and prioritised by the end of Foundations see to be ust aves , the e ibility
afforded by prioritisation is missing: there are no lower priority requirements that can be descoped later in order
to bring the project back on ti e and budget. owever the assertion that all re uire ents are ust aves often
highlights the need for further deco position of the higher level re uire ents to find the e ibility.
6.7.2 Prioritisation during a Timebox
By their very nature, i ebo es are short typically 2 4 weeks, e ceptionally 6 weeks and so it is a reasonable
e pectation that the priorities set for re uire ents during a i ebo should re ain fi ed for the duration of the
i ebo . he only e ception to this should be in response to so e une pected event or an urgent need to
deliver a new requirement, in which case it may be worth considering the following:
• an the new re uire ent wait until the end of the i ebo and be considered for inclusion in the ne t
i ebo
• s addressing the re uire ent within the current i ebo practical
- This may depend on the maturity of the requirement and the understanding of the solution required
to satisfy it
• ow far has the i ebo progressed
• What is the i pact on the project and the Business ase of addressing the new re uire ent now
• Would it be better to stop the current i ebo and plan a new one
he last two options should only be considered in e ceptional circu stances. ubstitution of one re uire ent
for another in a i ebo ay be acceptable at any ti e, provided that the tea is co fortable that it does not
jeopardise the i ebo outco e, end date or uality.
6.8 Top Prioritisation Tips for the Agile BA

• Agree what the priorities ean early in the project
• se all of the o oW priorities
• hallenge the ust aves, but trust the right business representatives to know their business
• ontrol the nu ber of ust aves by facilitating sensible prioritisation and scheduling
• Prioritise everything - it helps the concept become deeply ingrained in the team’s approach
• Constantly review the appropriateness of the priorities and highlight the situation if they change
• eep the hierarchy of priorities clear and visible, so that confusion does not arise regarding the ti efra e in
which the priorities are meaningful
87
Prioritisation
AgileBA Handbook
6.9 Conclusion
rioritisation is the way to keep a project on ti e and on budget in a changing environ ent, without losing
uality. he o oW techni ue is reco ended by as the best approach for establishing a co on
understanding about the relative i portance and status of re uire ents, in ter s of their inclusion in the final
product. o oW is used to prioritise what is to be delivered. he ust aves together will for a coherent
ini u sable ubse of the solution.
are ust be taken to avoid the perception that only ust aves are scheduled to be co pleted. he Agile BA
ust help the project personnel and a wider group of stakeholders to understand that, whilst a ini u sable
ubse is identified, this does not ean that the Agile project will only a deliver the bare ini u solution. he
perspectives provided by the ano odel can give insight into the appropriate o oW levels and help to avoid
this perception.
In addition to MoSCoW prioritisation, sequencing the requirements in terms of value and risk can protect value for
oney and reduce the risk of failure.
he holds the agreed priorities, for s a baseline for project scope and for s the central repository for
infor ation about re uire ents it is aintained and enhanced throughout the project by the Agile BA.
88
7. Workshops
891
1 1
Workshops
AgileBA Handbook
7.1 Introduction
Workshops are a key Agile practice. hey are a specialised type of eeting with
• lear objective deliverables
• A set of people articipants specifically chosen and e powered to deliver the re uired outco e
• An independent person Workshop Facilitator , to enable the effective achieve ent of the objective
Facilitated Workshops are a proven techni ue to ensure collaboration, rich co unication and the achieve ent of
results with speed, co it ent and buy in.
n a Facilitated Workshop, a neutral Facilitator is responsible for the structure and conte t of the event. hey guide
the group through a process which enables the to work together effectively, to achieve an agreed goal.
his chapter focusses on the Facilitated Workshop within Agile projects, and identifies the ore co on types of
Workshops in which the Agile BA ay be involved during a project.
7.2 When Should Facilitated Workshops be Used?

Facilitated Workshops are a powerful way to achieve a particular purpose uickly, effectively, collaboratively and
with the right e power ent to ensure that the result is likely to be accepted after the Workshop. hey involve
the appropriate stakeholders to achieve the Workshop objective business representatives, solution develop ent
personnel, specialists, decision akers etc.
he Workshop objective ay be, for e a ple, to
• Gather ideas
• btain decisions
• tract infor ation
• Agree requirements, priorities, dates
• Design aspects of a system
• Create a plan
• btain agree ent
• stablish co it ent
• Secure approval
A Facilitated Workshop is often the best techni ue for eliciting a key business or technical decision and to gain
consensus from a group of people, either within one organisation, or in some cases between customers and
suppliers. t is also an effective way to prioritise re uire ents and actions.
90
A team-based information gathering A place where a specific job of work is done …
and decision making technique and a product produced.
Interactive communication
Empowered personnel
Independent facilitator
exchange
views
consensus decisions
deliverables
Figure 7a: What is a Facilitated Workshop
7.3 The Agile BA Role in a Facilitated Workshop

Facilitation is a core skill for the Agile BA. hey are often a trained facilitator, so they ay facilitate any of the
project s Workshops. his will only be appropriate if the BA does not also need to contribute to the content of the
particular Workshop they are being asked to facilitate. here are any reasons why the BA cannot effectively both
facilitate a Workshop and fully participate in the content of that sa e Workshop. For e a ple
• Facilitation and participation re uire two co pletely different ind sets. t is difficult to both focus on keeping
people on track, and simultaneously to be thinking deeply in analytical mode as an Agile BA, negotiating with
other participants from that role
• The Agile BA’s facilitation may not be accepted as impartial by the other participants, as the Agile BA may seem
to be driving the Workshop towards their own point of view
he Facilitator should be focused on the conte t and not the content of the Workshop. he Agile BA should
assess their independence carefully and avoid facilitating Workshops where they are re uired to have significant
participation. ne solution to this is a utual support group of Facilitators, where the Agile BA of one project or
incre ent ay facilitate for another project or incre ent in which they are not involved. Whether the Facilitator is
another Agile BA or so e other independent person, the Agile BA within the project should collaborate with the
Facilitator to ensure that there are clear objectives and a clear defined outco e for Workshops within the project.
91
Workshops
AgileBA Handbook
7.4 Facilitated Workshops within the Project

t is up to the project level roles, or the olution evelop ent ea e bers, to decide whether a Workshop
is the best technique to use for a particular purpose, or whether another method of communication and
collaboration is ore applicable.
7.5 Workshop Roles

The typical roles in a Workshop are:
7.5.1 Workshop Owner
his person owns the objective that the Workshop is ai ing to achieve or the proble that the Workshop is set
to solve they are usually also the budget holder for the Workshop. his could be any of the project or olution
evelop ent ea roles, depending upon the nature of the Workshop. t is up to the Workshop wner to set the
objectives and deliverables of the Workshop, although the Facilitator should help the owner in clarifying and scoping
these.
7.5.2 Workshop Facilitator
This person manages the process and dynamic of the Workshop, enabling Participants to concentrate on
the content and deliverables. hey should be neutral in relation to the Workshop objectives, deliverables and
articipants. deally they should co e fro outside the project to ensure, and signify, neutrality. f the Workshop
Facilitator is fro within the project, it is i portant that their behaviour is also seen by the group as re aining
independent of the outco e. hey are the i partial leader and enabler, with no involve ent in producing the
content towards the outco es of the Workshop.
7.5.3 Scribe (Co-facilitator)
he Workshop Facilitator ay engage a cribe also often acting as a supporting facilitator . o support or speed
up the process, there ay be ore than one person allocated to this role in a Workshop for e a ple a echnical
cribe ay be used where odels and docu entation are to be created directly into a specific toolset. sually the
cribe is not a articipant, since it is difficult to participate fully at the sa e ti e as scribing. his role will support
the Workshop Facilitator and record the e erging results of the Workshop, plus any actions, decisions and or issues
that need to be taken forward as a part of the Workshop outco es. his role ay be taken on by the Facilitator
the selves in so e Workshops.
7.5.4 Participant
A articipant is chosen because they are needed to produce the deliverables or achieve the objectives of the
Workshop. articipants ust add value to the Workshop. o do this they need to have the knowledge, skills and
e perience to be able to contribute to the objective of the Workshop and be e powered to ake decisions.
roup facilitation is a ean process, so only the people essential to achieving the objectives and deliverables
should be there. tra uninvited participants should be avoided, as larger groups increase the nu ber of possible
co unication channels and ake group dyna ics ore difficult.
7.5.5 Observer (optional)
ccasionally, so eone who is not directly a participant in the Workshop ay be present typically anage ent
audit trainees . hey are in a non contributing role with respect to the Workshop process and outco es and
should have no direct input to the production of the Workshop s i ediate deliverables. he bserver gains
fro attending and hearing the discussions but should re ain silent and have no in uence on or input into these
discussions. ypically, the bserver sits outside the articipant groups so that they do not distract the active
participants.
bserver is not a re uired role of a Facilitated Workshop but ay so eti es be present. n such cases, the
reason for their presence ust be clarified between the Facilitator, Workshop wner and the bserver, and this
should be e plained to the rest of the group of Workshop articipants. he presence of an bserver will change
the dyna ic of the Workshop and the Facilitator should watch for this change having a negative effect on the
participants and the evolving outco e of the Workshop.
92
Workshop
Observer(s)
Owner
Participants
Workshop Workshop
Facilitator Scribe(s)
Workshop
Co-facilitator
Figure 7b: Workshop Participants
7.6 Typical Types of Workshops within an Agile Project

A Facilitated Workshop is rather like an Agile project in iniature it has defined outco es, a tight, fi ed i ebo ,
e powered, collaborating articipants, on ti e delivery, and a focus on the uality of the result.
Workshops early in a project can help to build the fir foundations which continue throughout the project. o e
types of Workshop ay need to be repeated, rather than only occur once, for e a ple, isk Workshops and
lanning Workshops.
he list below gives so e of the types of Workshop that ay be run during an Agile project. o e of these
ay be co bined and beco e sessions within a longer Workshop. thers ay be split into several Workshops.
A Workshop ay not always need to be facilitated. Workshop techni ues are so eti es used in an infor al,
interactive session. Whether or not a Facilitator is needed is often deter ined by the si e and criticality of the
Workshop, and so eti es the difficulty or contentiousness of the e pected outco e. he duration of Workshops
varies, depending upon the outcome to be produced and the necessary number of participants, but a Workshop of
ore than a couple of hours need careful planning of structure to re ain effective.
he table below shows so e of the co only used Workshop types. t is not intended to be an e haustive or
definitive list but ay be helpful in deciding where workshops are appropriate in a project.
ore detailed consideration is given to so e of the Workshops below, in Appendi to this andbook
DSDM Lifecycle Phase Typical Workshop Types
Feasibility roble definition

any of these ay be run in ore isioning Futurespective isk Benefits
detail during Foundations olution options evaluation
roject approach uestionnaire
utline planning, including risk and esti ating
Feasibility rototype design review
93
Workshops
AgileBA Handbook
DSDM Lifecycle Phase Typical Workshop Types
Foundations roject Foundations

takeholder identification ser classes definition
oles and esponsibilities definition
Business Case building
e uire ents gathering prioritisation
rocess data odelling
esign prototyping olution Architecture efinition
olution rototyping and eview
est strategy definition
Delivery planning
isk identification, analysis and itigation planning
perational readiness criteria definition
etrospective
Evolutionary Development i ebo planning

Feature odelling
rocess data scenario odelling
Prototype design
Problem resolution
isk itigation planning
eview
i ebo lose ut e onstrations, how and ell
Data conversion requirements
Business readiness training planning
Deployment planning
est planning and e ecution
etrospectives
Daily Stand-ups
ser support docu entation planning and definition
Cutover planning
upport level definition
Deployment Problem resolution

ncre ent project review
etrospective
Post Project Benefits realisation assess ent
94
7.7 Features of Agile Facilitated Workshops
he following are co on features of Facilitated Workshops
• The right, empowered people, arriving prepared to produce the outcome
• Active participation encouraged by collaborative group activity within the Workshop
• A trained, independent Facilitator
• Visible recording of the Workshop results as they emerge during the event
• Workshop results available without delay after the Workshop
The right,
empowered
people, arriving
prepared to
produce the
product
Circulation Active participa-
within 24 to 48 tion encouraged
hours of the by collaborative
workshop results group exercises
to all within the
participants workshop
Visible recording
of the workshop A trained,
results as they independent
emerge during facilitator
the event
Figure 7c: Features of Facilitated Workshops
7.8 How to Achieve Successful Facilitated Workshops

7.8.1 A good Facilitator
A Workshop should be run by a skilled Facilitator. he Facilitator should be i partial to the issues under discussion
with no stake in the outco e of the Workshop. Facilitation is a highly skilled role re uiring sensitivity, diplo acy,
uick thinking and highly developed co unication skills. he role is instru ental in ensuring that a Workshop is
successful. he Facilitator will anage the Workshop process so that all participants have an e ual opportunity to
contribute and are able to work as a tea .
he Facilitator ensures that there is sufficient capture of the results and decisions fro the Workshop, often
working with a cribe or o facilitator to provide a sufficent group e ory of the event.
A good Workshop Facilitator will be aware of the group dyna ics. hey will ensure that all attendees are able to
contribute by creating the right at osphere, as well as by challenging the assu ptions of the group.
95
Workshops
AgileBA Handbook
7.8.2 Clear objectives

bjectives should be set for the Workshop and checked for their align ent with the scope of the project.
hey should be set by the Workshop wner and agreed by articipants, but the Facilitator should check for
easurability and priority.
7.8.3 Clear scope
Along with the objectives, the scope of the Workshop should be defined. his could be described in ter s of
business functions, organisational lines or other defining li its.
7.8.4 Appropriate, empowered, prepared participants
Without the right people present for the Workshop, a solution of the right uality cannot be reached. he
Workshop wner will reco end who the articipants should be, but this should be reviewed by the articipants
the selves and checked for reasonableness by the Facilitator. articipants need to be co itted to the success
of the Workshop, know their level of e power ent and arrive appropriately prepared.
7.8.5 Intermediate deliverables and a clear agenda
f the Workshop has a clear agenda and is structured, the route, possibly via inter ediate deliverables, to the final
deliverable, should be clear. his will ake it easier to review progress during the Workshop.
7.8.6 Workshop outputs/outcomes
Workshop outputs and outcomes should be kept visible during the event and be available to Participants as soon
as possible after the event.
7.9 Facilitated Workshop Activities

he activities associated with a Facilitated Workshop are
• efine and plan the Workshop
• Prepare for the Workshop
• Facilitate the Workshop
• un the Workshop
• Workshop etrospective
• Document the outcome
• Workshop Follow up
hese are e plained below.
7.9.1 Define and plan the Workshop
he Workshop wner, with support fro the Workshop Facilitator, defines the objectives of the Workshop ,
no inates the articipants and agrees, in outline, the for that the Workshop should take. t ay so eti es be
necessary to define several Workshops to achieve the objectives. Workshops can be effective with any nu ber of
people, fro 4 to 1 . owever, significant planning and structure will be re uired for larger workshops, which
ay include the use of o facilitators and possibly splitting the articipants into roups.
7.9.2 Prepare for the Workshop
n preparation for the Workshop, the Workshop Facilitator circulates infor ation to the participants in advance,
so that they fully understand the objective of the Workshop and the background to it and have ti e to prepare.
An agenda detailing when and where the Workshop will take place, who will be attending and the order of
proceedings, will be sent out, together with any pre Workshop reading or preparation. n particular, individuals
should be advised of what input to the Workshop is needed from them so that they can prepare the information
beforehand that they need to make an effective contribution and, where necessary, collect the views of those they
are representing.
n addition to preparing for the content of the Workshop, the Facilitator ust oversee the preparations for venue
and logistics this includes refresh ents, roo si e, the need for break out areas and all other physical arrange ents
which are necessary to the success of the event.
96
7.9.3 Facilitate the Workshop - run the Workshop
roun ru es
t is useful, at the start of the Workshop, to agree a few basic guidelines for interaction ground rules that the
group are co fortable with, to enable effective and collaborative working. etting agree ent on these and aking
them visible throughout the Workshop will help everyone to stay on track, work as a team and should reduce the
potential for con ict.
o e typical ground rules ite s would cover ti ekeeping dealing with different views decision aking
confidentiality participation use of obile devices.
Some sample guidelines are:
• Please be on time - as timescales are constrained
• espect the views of others
• ne conversation at a ti e
• ach individual in the group has a responsibility to aintain focus
• hones technology off silent
To ensure everyone’s buy-in, the following questions can be asked:
• What will ake this Workshop a success
• What responsibility will you take to ake this happen
• ow do you want to work behave treat one another
• ow do you want to work with the Facilitator
7.9.3.2 Focusing the Workshop
he Facilitator is there to ensure that the Workshop is clearly focused. he agenda for the Workshop is sent out
beforehand and should be kept visible throughout the Workshop. uring the Workshop, an agenda will act as a
road ap, providing checkpoints for progress.
7.9.4 Facilitate the Workshop - Workshop retrospective
he effectiveness of every Workshop should be e a ined just before the end, and any lessons learnt fed back into
the operation of future workshops. n particular, did the Workshop eet its objectives fully or only partially did all
articipants contribute to the process did it run to ti e
7.9.5 Document the Workshop
ne of the risks to the success of workshops is that, after the event, people s e ories of what was agreed often
differ. t is good practice to ensure that workshop outco es are kept visible during the Workshop, and are available
to all i ediately after the Workshop. his ay be in the for of a Workshop eport, or ay just co prise
photographs of workshop artefacts taken at the end of the Workshop, as appropriate to the purpose, risk and
objectives of the Workshop. he cribe typically ensures that this happens. he report should faithfully re ect
what the articipants have seen and agreed during the Workshop. ne of the best ways to do this is to take
photographs of the Workshop artefacts, as they appear in the participants own handwriting.
A Workshop eport should not be inutes of the eeting . t should re ect decisions, actions, and the artefacts
on which the articipants have worked. t should typically contain
• Participants, date, time, location
• he outco e and objective of the Workshop
• Decisions
• Actions and owners to whom they are assigned
• Any open issues
• he output of the Workshop itself as appropriate
• he process used as appropriate
97
Workshops
AgileBA Handbook
7.9.6 Workshop Follow-up

he satisfaction of the Workshop wner with the Workshop s results should be confir ed. All actions arked for
follow up activity outside the Workshop foru ust be addressed and not just docu ented he responsibility for
taking the actions lies with the articipants and the Workshop wner.
7.10 Benefits of Facilitated Workshops

Facilitated Workshops are a uick and effective way of eliciting infor ation and provide a foru for the resolution
of con ict and differences of opinion. hey give a sense of involve ent to articipants and gain ownership for the
outco e. owever, it is essential that the key decision akers are involved and that the Workshop articipants are
e powered to ake decisions about the direction of the developing syste , otherwise progress will be ha pered.
By bringing people together fro a nu ber of business areas in a Workshop, a broader perspective of the project
is created. nderstanding is therefore i proved and better decisions can be ade for the business. lear workshop
ground rules and a clear decision aking fra ework will help to ensure workshop effectiveness.
7.11 Facilitated Workshops in a Distributed Team

Environment
Sometimes, the required Participants for a Workshop may not be co-located, which may seem to be a barrier
to running a Workshop at all. owever, with the use of online, collaborative tools, it is possible to run effective
workshops using desktop sharing and ulti user editing of working docu ents. istributed workshops re uire
additional preparation by the Facilitator, ensuring access to tools and environ ents is available to all collaborative
docu ents need to be prepared in advance and voice and video facilities need to be tested. Facilitation of a
distributed group has its own particular challenges, and good facilitation is needed for success.
7.12 Conclusion
Facilitated Workshops are a particularly effective way to engage a group of people to achieve a particular purpose
uickly. hey need to involve the appropriate e powered articipants to eet the Workshop s objectives.
For success, a Facilitated Workshop should have
• A trained and skilled Facilitator
• A format suited to the culture of the organisation
• A clear, agreed agenda, allowing e ibility in the for at of the Workshop, but with clearly defined objectives
• Preparation before the Workshop by all parties
• A mechanism for ensuring that previous Workshop results are built in
• A solution or agree ent which is not forced. f the Workshop articipants cannot agree on a point perhaps
due to lack of infor ation within the Workshop, the Facilitator should seek a solution fro the group to
remedy the shortfall
• Appropriate recording and timely distribution of the Workshop outputs
• A review at the end of each Workshop, to check that it et its objectives
98
8. Modelling
991
1 1
Modelling
AgileBA Handbook
8.1 Introduction
Modelling refers to the diagrams, sketches, illustrations, built artefacts and prototypes, which make visible a situation
we want to co unicate to others. hey ay show a current situation, a proposed option for change, or
so ething that has been developed for future use. hey provide an early eans of checking that a desired solution
is being developed as re uired. hey assist analysis and re uire ents definition. hey ay be used to aid the
support of the solution once it has been delivered. o e odels will also be useful as input to future projects.
The purpose of modelling is typically to:
• Improve visibility
• Create transparency
• Generate questions
• efine business rules
• Check completeness
• Crosscheck consistency
any industries benefit fro the use of odels, prototypes and ock ups to establish re uire ents, confir
e pectations and test the achievability of objectives. he odelling approaches used can be as different as
• A storyboard to represent a television advertisement
• An architectural blueprint to define a housing develop ent
• An artist’s impression of a landscaped park
• A scale model of a car to be built
• A business process diagra to establish the current As s situation or define the re uired functionality of a
future o Be solution
For e a ple, in a software related project, diagra s ay be drawn to establish processes and their dependencies.
Later, screens may be presented as “mock-ups” with no real functionality yet built, in order to check understanding
of the re uire ent these screens ay then be refined and agreed with those who will use the . he screens ay
evolve into the real screens of the final solution.
This chapter describes some of the different types of model and diagram that are commonly used, with a bias
towards projects with a software ele ent.
8.2 What is a Model?

A odel can be defined as
• A description or analogy used to help visualise something that cannot be directly observed
• A s all but e act copy of so ething
• A pattern or figure of so ething to be ade
A odel should have content and eaning. t is always
• reated by so eone sender
• For so eone receiver
• For a specific purpose usage, conte t
odels ay be a prototype, i.e. so ething physical often a solid, constructed version of so e part of the solution
or ay be e pressed in a language, for e a ple, a diagra ing convention, with its own rules and sy bols.
odelling is often used to help people to visualise co ple things
ngs odels can help to
• clarify the overall picture at a high level
• aid analysis of co ple ity and highlight o issions
• break down a project into cohesive blocks of work, often as a basis for planning
• aid communication at all levels
100
8.3 Target Audience for Models
he target audience for our co unications in an Agile project includes
• he project level roles
• The Solution Development Team
• A wider group of stakeholders affected by the project and the eployed olution
hese people will co e fro a wide range of technical and business disciplines.
specifically advocates that we co unicate continuously and clearly, using visual co unication. he
Agile BA will do this and also go beyond, encouraging “rich communication”, which takes account of people’s
different co unication styles visual, auditory and kinaesthetic ore about these in hapter 9 . An essential
part of co unication is the process of sending and receiving infor ation effectively. Awareness of different
co unication styles allows us to co unicate with people ore successfully. f we send infor ation to people
in a way that does not suit their style for receiving it, we may not communicate at all, or worse, we may only
co unicate part of what we believe we have conveyed.
If you have ever heard anyone say:
• t was all in the docu ent. t see s she didn t bother to read it
• e just didn t listen
• hey ve seen those screens five ti es in de onstrations and said they were fine. ow they ve had their hands
on a prototype, they’re spotting all sorts of errors”
• f people just tried to do it, they d see why it s a proble
...then the co unication was probably being atte pted in just one style, or in the wrong style for the receiver.
o achieve effective co unication, any odes of co unication ay need to be used. odelling is one of
these, and ay be shared by the Agile BA and other disciplines within the project.
It is important that the level of detail and the language used in any models is appropriate for the target audience
and the disciplines they represent, as Agile works with tea s of i ed specialis s and e perience. he
effectiveness of any particular odelling approach for its different receivers ust be considered. he a ount of
ti e and effort put into odelling should be onitored, and should be just enough to satisfy the purpose of the
odel and achieve the necessary co unication.
8.4 Modelling and Abstraction

odels deal incre entally with co ple ity by oving fro an abstract view of the solution down to progressively
ore detailed views.
odelling usually incorporates a degree of abstraction. n other words, a particular odel will focus on a particular
perspective e.g. the business processes , and deliberately o it other aspects of detail fro the odel e.g. the data
structures , to allow clearer focus upon the particular aspect chosen.
For e a ple, the traveller s ap of the nderground etro syste in a city typically shows just what it needs
to in order to co unicate specific infor ation to its target audience the traveller . ts ai is to help travellers
to ove fro tation A to tation B. o do this, it shows just the stations and the links between the . t o its
the power cables, the echanis s to change tracks and the signals followed by the driver, etc. as this odel is
specifically for the traveller. t does not even show distances between stations it does not need to convey this
infor ation to achieve its ai . Another diagra , for a different purpose and target audience ay actually add the
other features.
It is essential when communicating in any form to answer the questions:
• Who is it for
• What do they need it for
101
Modelling
AgileBA Handbook
odels are used to aid co unication and are not an end in the selves.
When docu enting odels, a photograph of a sketch on a whiteboard ay be fit for purpose and does not always
need to be converted into so ething elaborate or auto ated.
8.5 Modelling and Prototyping

odelling and prototyping are linked concepts a prototype is a kind of odel. For e a ple, a odel could be
a diagram, a picture, a sketch, a clay construction of a new car design, a set of functional screens for a computer
application, a ock up of a screen on paper. Any of these could also be considered to be a prototype. We can
odel an e isting situation a building, a staffing structure, a database structure as a diagra . A prototype usually
i plies a new structure. rototypes are typically illustrations of how the solution or a part of it will look, feel,
behave or perfor .
8.5.1 What is a prototype?
A prototype is a kind of odel. t is typically so ething that serves to illustrate the typical ualities of the eventual
solution. t ay be
• an evolutionary prototype e.g. screens for an solution which are built to evolve into the eventual solution
• a disposable prototype e.g. a clay odel of a car, which was always be intended to be an e peri ental, throw
away odel, to de onstrate or e plore specific features
rototypes ay be used to test any concepts e.g. feasibility, usability, perfor ance related ualities such as speed
and capacity.
8.5.2 Benefits of prototyping
rototyping is one of the any ways to achieve effective co unication between stakeholders. advocates
the use of odels and prototypes to i prove co unication and to ake ideas and the volving olution visible.
rototypes are linked with the process of terative evelop ent see hapter 9 . hey ake ele ents of the
volving olution visible and engage representatives of the business end user population in hands on e perience of
the e erging solution as soon as possible.
8.6 “As Is” and “To Be” Modelling
AS IS The Gap TO BE
what
when
where
how
who
why
PHYSICAL
CONCEPTUAL
what
why
Figure 8a: As Is and To Be
102
When analysing a business area, the Agile BA needs to lead the team in discovering the gap between the current
situation As s and the desired future situation o Be . he objective is a solution to satisfy re uire ents and
fulfil the project s Business ase. odels can be powerful in pro oting a co on understanding of the current
situation and allowing visualisation of the proposed solution, including various options for this. hese perspectives
are often a way of e pressing the voice of the custo er and the custo er journey. ee below the use of
storyboards for e pressing the custo er journey.
odels are often developed during a series of Facilitated Workshops, in order to gain input fro appropriate
stakeholders and to achieve buy in.
any odelling approaches are available, and so e of the ore co on ones are outlined below. he sa e
odels ay be appropriate for both the As s and o Be . A project seldo relates to a first ti e change where
no odelling has gone before. odelling should be viewed with the prospect that so e o Be odels will be
useful as the As s situation for subse uent develop ents. When a si ple As s diagra is in place, further detail
can be added to describe the changes re uired for the o Be situation.
8.7 Modelling Perspectives

8.7.1 Six perspectives for modelling
Whether for the “As Is” or the “To Be” situation, a coherent picture of a solution area can be gained by considering
si perspectives what, how, where, who, when why. his follows a structure initially proposed by ohn ach an.
onsidering the relationships between these perspectives can be used to crosscheck for issing infor ation.
atrices can be helpful in visualising these relationships.
The list below shows an interpretation of these perspectives from an Information Systems related point of view, but
parallels can easily be drawn for other types of project.
W A The information within the solution area, data, relationships and

business rules
W The functions, features and processes within the solution area
W The locations in which the solution operates
W The people - customers, users, stakeholders, suppliers
W he events of i portance to the business ti es and scheduling
W he business need, business objectives business value and strategy as

related to the project
he Agile BA ay choose to create odels fro so e or all of these perspectives, if it is useful to do so. t is
worth checking during a project whether any perspective has been issed as this ay indicate an area that
re uires further analysis.
103
Modelling
AgileBA Handbook
WHY
WHERE
WHO
WHAT HOW
WHEN
Figure 8b: Modelling perspectives
8.7.2 Modelling the big picture

A set of odels should be considered in two di ensions breadth first the big picture and then depth the detail .
t is essential to understand the breadth of the solution area at a high level early in the project. his is an aid to
defining the scope, fra ing the boundaries of the project and setting stakeholder e pectations. odelling the
breadth of requirements is a much smaller investment of time than dealing with an entire deep dive into detailed
odels.
nce the breadth has been established the Agile BA can incre entally odel the depth, focusing on how the
solution needs to behave.
8.7.3 Modelling from a single user role perspective
ather than odel the entire business area at once, it is so eti es better to focus on the aspects of the solution
needed for a particular user role to carry out a specific task. his approach is likely to achieve individual user buy in,
because users can readily see the purpose of the odel. ach user is able to focus on the areas of ost interest to
the selves, and in which they have the ost knowledge and e perience to contribute.
he user centred view cuts across the above si perspectives. t can provide answers to all si uestions for a
specific user, responding to a specific business event.
odelling can help the tea and other stakeholders to understand how the business works. his involves
looking at the detail of the procedures perfor ed, and typically analysing the nor al happy path scenario first
and capturing e ceptions later. able 8a shows a nu ber of techni ues fro which the Agile BA can select, as
appropriate.
8.7.4 Defined modelling languages
n business projects and in particular those involving software, the ter odel has traditionally been used to refer
to a set of diagra s which interrelate. hese ay be for ulated in a defined language. wo such languages are
• Business rocess odelling otation B
• nified odelling anguage
hese are described only brie y here, and further study would be needed to e plore their full richness.
104
usiness Process Mo e an otation ( PM )
he Business rocess odel and otation B was developed by Business rocess anage ent nitiative
B and is aintained by the bject anage ent roup . t supports business process anage ent
for technical and business users and bridges the communication gap between business process design and
i ple entation.
ts diagra s are si ilar in appearance to owcharts and Activity diagra s, showing the ow of activities within
business processes. t is appropriate to odelling business process and enabling business process i prove ent. t
offers a way to create blueprints, including components such as:
• he people involved with the business processes actors
• The processes and activities
• The locations where the process will be operated
he Business rocess odelling with swi lanes, described later in this chapter, is an ele ent of this language.
ni e Mo e in an ua e ( M )
he nified odelling anguage is used to specify, visualise, construct and docu ent particularly the
artefacts of a software intensive develop ent project. owever, it is also possible to use it at a high level to odel
business processes, to enable business process i prove ent, even without software develop ent. offers a
standard way to create blueprints, including components such as:
• eople involved with the product actors
• Processes
• Data
• Locations where the product will be operated
• Infrastructure that the product will be run on
Four basic principles of odelling underpin
• very odel ay be e pressed at different levels of precision
• The best models are connected to reality
• o single odel is sufficient
• very non trivial solution is best approached through a s all set of independent odels
diagra s can be used to gain an understanding of a business area and the features re uired. t can then
be used to guide the creation of other artefacts, such as software co ponents. hese ay first be presented as
working prototypes which, when refined and tested, will evolve into the eventual solution.
Business rocess odelling, Business o ain odelling and se ases, shown later, use ele ents of this language.
8.8 Modelling in the Agile Lifecycle

he level of odelling throughout the lifecycle ust be appropriate to the level of co ple ity and
characteristics of the project progra e in uestion.
Working with the project level roles and the whole of the olution evelop ent ea , the Agile BA facilitates
co unication, collaboration and analysis by the use of appropriate odelling techni ues throughout.
A table, showing some key Modelling techniques and where they are most useful in the lifecycle is given in
Appendi B.
8.8.1 Pre-Project
n re roject, the organisation s strategic planners have identified an opportunity or need and are considering
setting up a project to address this. he Business ponsor will be identified and er s of eference will be laid out,
sufficient to obtain agree ent to start the project.
105
Modelling
AgileBA Handbook
he definition of why business objectives and rationale for the idea for s the er s of eference for the
project. he Agile BA will clarify the scope of the project, often by drawing a high level diagra conte t diagra .
he style of this diagra ay be a ich icture, which also helps to identify potential stakeholder groups. At this
point, models from a previous solution in the same business area may be a useful shortcut to understanding the
proble and clarifying the objective. A very rough, high level prototype of the initial ideas ay be used, to help
stakeholders to understand what is being proposed.
8.8.2 Feasibility
n Feasibility, odels are likely to support a relatively si ple, big picture view of what is being proposed, to
e plore possibilities and help co unicate options. Feasibility prototypes ay be used to help establish what is
possible from a technical perspective, as well as helping to visualise what a solution might look like from a business
perspective.
Communication is mostly with the organisation’s strategic planners, the Business Sponsor and key stakeholders
here, and any odels prototypes or diagra s intended to infor or engage the ust be in the right business
focussed language and presentation.
A high level diagra onte t iagra ich icture ay be useful here, to clarify the scope and boundaries of the
project. A nu ber of solution options are usually being considered, and ay result in several sets of very high level
odels. hese ay be fro a conceptual perspective, initially o itting the how, when, where and who perspectives.
ater odels will show the different physical perspectives of proposed o Be solution options.
A Feasibility prototype ay illustrate potential solutions or ay act as a roof of oncept. his could include
diagra s and or working prototypes to convey the different options being considered.
8.8.3 Foundations
uring Foundations, ore precise and elaborate odels ay be created. hese odels will help co unicate
plans and intentions to a variety of audiences. odels of business process and business organisation as they are
today and as they are proposed for the future ay be valuable as ight high level designs of technical solutions
such as syste architecture odels and data odels. At this point, odels and prototypes can be used to clarify
scope and support high level planning by revealing o issions, inconsistencies and dependencies.
Good communication is still essential with the organisation’s strategic planners, the Business Sponsor and key
stakeholders. Any odels prototypes or diagra s intended for the ust continue be in the appropriate
language and presentation.
he cross functional olution evelop ent ea is now beginning to work on the definition and prioritisation of
the high level re uire ents. odelling here can help to structure the rioritised e uire ents ist and give an
understanding of the structure of the project s outline design.
Modelling from all of the perspectives: what, where, when, how, who, why is useful here. igh level solution odels
will be sufficient to e plore dependencies and to enable esti ates to be ade for planning. A onte t iagra
evolving fro Feasibility, and now concentrated on the chosen solution option will help to co unicate the
scope of the solution and highlight areas out of scope.
igh level odels should be used to analyse the whole breadth of the proposed solution, but not in too uch
detail at this point. nd to end process diagra s of the solution will often be useful. he current situation ay also
be odelled. odels drawn here will be invaluable as a guide for the incre ental delivery of the solution and as an
aid to eploy ent. owever, the te ptation to dive deep into the fine details of the solution should be avoided,
leaving the detail until i ebo es during volutionary evelop ent.
A solution prototype ay also be constructed here, often as a disposable prototype. e uire ents and processes
ay be odelled, in diagra s, to show the dependencies between the .
uring volutionary evelop ent, it is likely that, where they add on going value, high level odels will continue
to be evolved in ter s of depth and detail as a way of helping to e plore the detail of re uire ents and ways that
these ay be et as part of the volving olution. Where appropriate, odels ay be developed that will help
106
with eploy ent and with on going operation and support of the solution in live use.
he cross functional olution evelop ent ea is now working on the detailed evolution of the solution. odels
fro Foundations and the rioritised e uire ents ist help to retain focus on the overall structure of the project.
iagra s illustrating the end to end process, and single user perspectives ay be evolved here.
volving technical detail ust be presented clearly to aid solution develop ent. odels here often need to be
technical, precise and detailed, and are intended for a technical audience only.
With DSDM, there will usually be many increments to be deployed, and therefore many elements of the models
will evolve fro previous odels.
8.8.5 Deployment
In Deployment, it is unlikely that many new models will be created but some that were created to help with
eploy ent will be used at this ti e and ay be refined for future project incre ents where applicable. n
addition, odels created to help operate and support the solution ay be refined as it transitions into live use.
o ponent odels of the e isting situation As s will be usef
useful along with the ore detailed odels of the
eployable olution o Be . odels fro the user perspectives of how the solution will be used are helpful in
linking users to the ele ents of the solution related to the . he eployed olution is the working, i ple ented
version of what is, effectively the final prototype. on i ple entable odels, such as diagra s, can provide user
and support aintenance docu entation.
8.8.6 Post-Project
n ost roject, the odels used to help to operate and support the solution will continue to be refined in line
with any changes to the eployed olution over ti e.
It should be emphasised here that the above phases are not always serial. Also, none of the models are mandatory, but
should be used when they are an aid to understanding and communication, or where they support evolution of a solution.
Additionally, models should not replace face-to-face communication.
8.9 An Overview of Some Key Best Practice Modelling

Techniques for the Agile BA
he following is not an e haustive list of the techni ues available to the Agile BA. owever, it ai s to give a useful
toolkit of techni ues fro each of the si perspectives, and at different levels of detail. t ai s to highlight a few key
techni ues for each life cycle area which are particularly suited to the Agile way of working.
8.9.1 Useful modelling techniques
The following table summarises a selection of useful modelling approaches for the Agile BA, in alphabetical order
for ease of reference. hese are further outlined below. his table is e panded in Appendi B to show lifecycle
coverage, odelling perspective and level of detail of each techni ue.
Modelling Technique Main focus
1 Business anvas ean anvas Stakeholders, Goals
2 Business o ain odel lass iagra ata, Business ules
3 Business rocess iagra s using wi anes Process, Locations, Actors
4 onte t coping iagra Scope of study or change
5 Customer Journey Mapping vents
107
Modelling
AgileBA Handbook
Modelling Technique Main focus
6 Impact Mapping Benefit, oal
7 Personas People
8 roduct ision Bo Whole product
9 ich icture Any
10 pecification by a ple ser nterface
11 toryboards Wirefra es ser nterface, vents
12 se ases Actors, Process
13 ser tory apping Planning
14 Value Chain Mapping Process improvement
ach of the techni ues in the above table is outlined below. t is beyond the scope of this book to give full detail of
every techni ue. owever, it is intended to give sufficient detail to allow the Agile BA to identify techni ues which
ay be useful to the , for further study.
8.9.1.1 Business Canvas/Lean Canvas
A Business Canvas, or Lean Canvas, is a template that allows the consideration of the big picture of a business, or
business area, on a single page. As a ean anvas, it can be used to look at the big picture for a product or service
and for a project to create or enhance this. t pro pts the Agile BA to identify and list the key aspects of the
business area under study his techni ue is attributed to Ash aurya Ale sterwalder .
For a ean anvas, the usual headings are
• Problem - Top 3 problems your idea will solve
• Solution op 3 Features
• Metrics ey easures of the features
• Unique Value Proposition - Single clear message - why your product is different and worth buying
• Unfair Advantage - What can’t be easily bought or copied about your idea
• Customer Segments - Target customer groups
• Channels - The ways you get your product to customers
• Costs ey ele ents of cost of production, arketing etc.
• Revenue Streams nvest ent Appraisal ow does the occur, when and how uch
his odel assists in the production of the Business ase and clarification of the Business ision. t helps to define
the product or service which the project is to produce and includes a high level stakeholder analysis.
108
The Lean Canvas
PROBLEM SOLUTION UNIQUE VALUE UNFAIR CUSTOMER
Top 3 problems your Top 3 Features PROPOSITION ADVANTAGE SEGMENTS
idea will solve Single clear message -‐ What can’t be Target customer
why your product is easily bought or groups
diﬀerent and worth copied about your
buying idea
METRICS CHANNELS
Key measures of The ways you get
the features your product to
customers
COSTS REVENUE STREAMS

Key elements of cost Investment Appraisal – How does the ROI
of produc@on, marke@ng etc. occur, when and how much?
AMer Ash Maurya, Alex Osterwalder
Figure 8c: Lean Canvas
usiness Do ain Mo e ( ass Mo e )
ustomer
 ustomer um er
 ustomer ame
 ustomer ddress
 ustomer elep one um er
rder rder tem
 rder o  rder o ine num er

 rder Date  rodu t ode
 Delivery ddress  ty rdered
 Spe ial Requirements  alue
Figure 8d: Business domain model (class model)
109
Modelling
AgileBA Handbook
e uire ents investigation should incorporate so e for of Business o ain odelling to study the underlying
data structure of the area of the business under investigation. his could typically be represented in the for of a
lass odel, as shown above, or an ntity elationship iagra .
The Business Domain Model shows the groups of data which the business recognises as important in the area of
study, and the relationships associations between the . he lass odelling notation used here is also used in
a ore detailed way in a software develop ent environ ent, to describe aspects of the database of a solution.
owever, the Agile BA can use this techni ue at a higher level, in order to investigate the relationships between
data recognised at a business level, and to uncover business rules.
The Business Domain Model below shows:
• Classes groupings of data which belong together, for e a ple, groups of custo ers, orders, order ite s, etc.
hey are represented by rectangles, co prising three areas lass a e, Attributes and perations specific to
that particular class. he Agile BA would be ostly concerned with lass and Attributes during Business o ain
Modelling
• Associations hese are the relationships between the groups of data, and are represented by lines joining the
• Multiplicities hese are the nu bers on the lines, see graphic below and show how any ite s in each lass
ay be associated with ite s in another lass. For e a ple, one custo er ay have any orders. ne order
ay have any order ite s. he nu bers represent the ini u and a i u nu ber of one ite in a lass
that can be associated with ite s in another lass. f there is no li it, this is represented by an asterisk
The power of the Business Domain Model for the Agile BA is in uncovering business rules and constraints related
to the data, in relation to already-discovered, necessary processes and events, to ensure that data is present to
service these and that processes are available to aintain the integrity of the data.
110
usiness Process Dia ra s (usin s i anes)
Customer starts to Deposit Cash

ustomer
Prepare Docket Customer starts to Deposit Cash
Docket Cash Receipt
Scan OCR Docket Enter Amount Verify Details

Teller
Send Transaction Details
Teller Completed
Transaction
Transaction Details
Central System
Receive Transaction Details
Overnight
Archive Transactions
ustomer
Docket and Receipt and

Cash Original Docket
Teller
Scan OCR Docket

Verify Details
and enter amount
Docket and Printed

Cash Received Receipt
Bank
Central System
Transaction
Details
Archive Transactions
Overnight
Figure 8e: Business Process Model using swimlanes
111
Modelling
AgileBA Handbook
A graphical format for presentation and analysis of scenarios of working in the business is the Business Process
iagra so eti es called a Business rocess Flow iagra . hese diagra s use a owcharting notation and
swi lanes to odel the ow of processes activities and tasks across different business areas and or job roles. he
swi lanes show by who or where the individual activities are perfor ed, in an overall, end to end, process.
At a high level, these diagra s ay just include the key processes, and the swi lanes in which they occur. At a
more detailed level, they can show the event which triggers the process, and the detailed actors, tasks, decisions and
ti elines. As with the other techni ues, the Agile BA can use these in a hierarchical way, starting with a high level
view and then breaking that down to lower levels, as ore detail e erges. he diagra above shows a high level
Business rocess iagra , with tasks in a ti e se uence.
The value of the Business Process Diagram to the Agile BA is its ability to clearly show the processes involved,
across several business areas or job roles. hey are useful for describing both As s and o Be processes.
he As s Business rocess odel can give insight into where effort is being wasted. rocesses can then be
redesigned for greater value.
onte t (Scopin ) Dia ra
A onte t diagra is a si ple picture of the scope of the study or change, with focus on showing the interfaces,
rather than the detail within the area of change. t typically shows an e pty bo , with just a na e for the area
under study, as the boundary of the area under study, and the e ternal entities as as shown below.
his odel assists in the setting and co unication of scope and the identification of stakeholders, especially those
interfacing with the area of change.
Publisher
Book
Author Ordering Customer
System
Courier
Figure 8f: Context diagram
112
8.9.1.5 Customer Journey Mapping
usto er ourney apping is the odelling of a possible journey through an e isting or proposed service fro the
custo er s perspective. A blank journey worksheet and a set of cards representing the touchpoints are needed.
he apping usually starts by asking the participants to choose a custo er persona. hen they define a goal for
this persona and identify the touchpoints that persona has with the organisation’s service that allows the goal to be
reached. he custo er s e perience across the different touchpoints can then be analysed.
usto er ourney apping is ideal for a Facilitated Workshop, and ay use storyboards, rich pictures or large scale
graphical presentations of a journey to facilitate the capture of the se uence of activities and touchpoints that are
part of the custo er s e perience.
nce the journey has been apped, the resulting picture can be used to highlight the gaps, issues and
opportunities, both fro the perspective of the custo er and the provider.
Home
Return To the Airport
Destination
Customer
Before Customs
Airport
Experience
Behind Customs
Behind Customs
In Flight
Boarding
Figure 8g: Customer journey mapping
8.9.1.6 Impact Mapping

pact apping, proposed by ojko Ad ic, is a techni ue designed to help organisations to build products and
deliver projects that focus clearly on delivering value to the business, in line with its strategic objectives.
verything we work on as a solution ust cause a change in the behaviour of so e person or group. pact
apping focuses the project by aligning it to the strategic goals.
he diagra below shows the structure of an pact ap, and the uestions it pro pts. For e a ple, in an
insurance clai s syste , we have been asked to undertake a project to replace the clai s syste and speed up the
processing of clai s. Beginning at the botto of the pact ap, the reasoning is
WHAT: f we treat the clai s syste as What we are being asked to do i.e. a solution , the ne t uestion is
HOW: ow do you want this to change the behaviour of so eone associated with the solution his
describes the Impact which is the desired outcome of the change
he i pact of the new syste answer to W could be We want custo ers to register fewer
113
Modelling
AgileBA Handbook
co plaints , then the ne t level of uestion is

WHO: Whose behaviour are we trying to change ne aspect of this is the usto er. aybe another is the
lai s rocessor. ow do we want their behaviour to change ould a change in their behaviour
achieve our strategic objective without developing a new clai s syste s there a better solution his
brings the questioning to the top level of the Impact Map, which is
WHY: Why are we aking this change What benefit are we really trying to achieve f this benefit can be
described in measurable terms, we can clarify the level of Impact needed and ensure that the best
solution to address the desired impact is chosen
The Agile BA can use Impact Maps to question the solution requested and clarify the real business goal for the
project, and any particular re uire ents within it.
Increase the number of

paying delegates on courses Business Goal
by 100% within 1 year Why
Individuals;
Training Managers Actors
Who
People will book

Other Actors more courses Impacts
Ho eha iour i change
Better course booking Deliverables

Other ways to system on website What
change the behaviour?
Figure 8h: Impact map
8.9.1.7 Personas
A ersona is the hu an role of an actor in our solution. ser tories and se ases can be linked together into
usage scenarios which describe real world e a ples of one or ore of the typical people who will interact with
the solution. hese representations of typical people are called ersonas .
Creating a Persona involves identifying each potential user of the solution, and considering them as a real person, or
category of person, including their likes, dislikes, concerns and needs.
ersona descriptions can be high level or very detailed. hey will use real na es rather than just the user role e.g.
ales lerk . ather than choosing na es at rando , it ay be helpful to use alliteration for the personas e.g.
ynthia lerk i on tudent o y utor so that it is easier to understand and re e ber their role.
ersonas should see real, and should include a photograph, a brief biography, profile, likes and dislikes.
114
For example:
in relation to a course-booking
Persona: Fiona Fresher
Fiona is a 17 year old student, just starting university. She still lives locally with her parents. She is
feeling worried about finding the courses for which she has previously registered, and arriving on
campus but not being able to find the right room or building. She has a computer, and is studying
English. She would prefer courses with an appealing content and is particularly interested in drama
and media studies as subsidiary subjects. She spends her spare time reading books. She loves
Twitter and Facebook and has many friends
When considering Personas, it is good to also include “anti-Personas” and “mis-use cases” to model threats and risks
to the syste e.g. a kiver .
For example:
Persona: Sam Skiver
Sam is an 18 year old student in his first year at university. He likes to drink bottled lager, and play
computer games on the internet until the early hours of the morning. He can’t cook and although
he lives in catered student accommodation, he has never been up in time for breakfast. Sam has
few friends, other than his followers on Twitter and those he has met in a virtual reality role-playing
games. Ideally, he would not register for any course that started before midday. He would prefer
courses with the least amount of course work and the maximum amount of credits so that he can
do the bare minimum to get his degree
he benefit of ersonas is the realis of developing and testing re uire ents fro ultiple different perspectives.
he Agile BA is responsible for facilitating the involve ent of the right people. aving identified ersonas, it ay
be useful to formulate focus groups of real users, covering the different personas, to review and test the solution
during its develop ent.
Persona: Fiona Fresher Persona: Sam Skiver
17 year old student, just starting university 18 year old student in his first year at university
lives locally with her parents e likes to drink beer
has a computer few friends
many friends Plays computer games until late
Figure 8i: Personas
8.9.1.8 Product Vision Box

he roduct ision Bo , first proposed by Bill hackleford, is a useful techni ue when starting a project, to help
to create a shared vision of the objectives and e pected outco e of the project between key stakeholders. t is
usually a Workshop based techni ue, involving the tea responsible for designing and building the product.
The stakeholders work together in small groups to create a visual, concrete image of the software, product or
service which they are about to develop. he final result is always a single bo , although several inter ediate bo es
ay e erge during the Workshop, as the group converges on a co on understanding of their goal.
115
Modelling
AgileBA Handbook
he bo can be odelled on the actual sales packaging of other products, si ilar or even dissi ilar to create
variety and sti ulate creativity .
For the bo , the group will usually consider
• Front
- Name
- Picture or drawing
A slogan or strap line for the product e.g. oca ola, the real thing
ni ue selling points
• Back, sides, top, bottom:
- A more detailed view
- Pre-requisites
Benefits
- Warranty
- Cost
- Version number
Warnings and constraints e.g. ell by date
- Instructions:
ow to use
ow to store
ow to get support
- Legal aspects
he techni ue and the Workshop environ ent pro ote discussion and collaboration and help to set priorities.
at s on t e rodu t o
 ame  arnin s onstraints
 ene its (Sell y)
 arranty  nstru tions
 ost  o to use
 ersion num er  o to store
 e al aspe ts
 et
Figure 8j: Product box
116
8.9.1.9 Rich Picture
A ich icture is a si ple way of co unicating ideas, or e pressing issues or proble s visually. he idea was first
used by eter heckland. When developing a solution to a business proble , it is essential to understand its vital
co ponents. hese ay be fro any or all of the si perspectives above why, what, when, where, how, who.
ich pictures typically co unicate not only the objective infor ation such as actors, data, processes and their
dependencies, but also softer infor ation about relationship proble s and potential con icts.
he picture is typically structured rather like a ind ap, but with no for al synta . he Agile BA ay start with
a short problem statement and then to place all the relevant components of the problem around it, pictorially, with
arrows to link related or connected co ponents and keywords to highlight particular ele ents.
he benefit of the ich icture is its e ibility of for at that allows it to be designed to co unicate best with its
chosen target audience.
ro essional So iety o e Desi ners
ld ers
e o
E
pe
Sta ed Desi n n
ta
tio
o
ns
e t
St
rofit
ives
an
Long term
dar
reputation
ds
eed more
time
otential lients Res

Data our
Dire tor es
on
tin
ern
s
ar e
ents
Strate y
ar et
dministration
Do um
Resear er
or
inte
don t ha e
f on y ra
ompetitor enough time to
had more tion
ompanies ta to users
po erfu too s s
tin
ar e
ood o
on epts
irt Cheap
ro lems
tion
s e oder
Solu nalyst ocus
ias
urrent lients ro e t eam
nalysis
Figure 8k: Rich Picture
Speci cation e a p e
t is often difficult for the intended users of a solution to specify what they need precisely, in words and pictures,
before they have any ental i age of how the solution ight look or work. pecification by a ple is intended to
facilitate the process of arriving at a solution by illustrating the options for a solution as prototypes. hese ay be as
si ple as a spreadsheet ock up of a report. hey enable the user and the Agile BA to work with developers to
understand the proble and produce a solution which best fits the real business need. ojko Ad ic has identified
seven process patterns followed by co panies that continuously deliver valuable software. hese are
• Deriving scope from goals the Agile BA works within the olution evelop ent ea to define the
re uire ent by e a ple, starting fro the desired business effect
• Specifying collaboratively - the Agile BA as part of the Solution Development Team discovers the detail of the
solution collaboratively, by e a ple
117
Modelling
AgileBA Handbook
• Illustrating using examples - the Agile BA and the rest of the Solution Development Team clarify the detailed
solution during i ebo es, using e a ples to define what the solution needs to do. hese e a ples can replace
a fuller re uire ents specification
• e nin the speci cations discussion of key e a ples within the olution evelop ent ea builds a shared
understanding of the requirement and its acceptance criteria
• Auto atin a i ation ithout chan in speci cations - the Solution Tester can build tests based on the
agreed, refined e a ples. he key e a ples can be used to validate the product and aid deploy ent
• Validating the system frequently the syste can be validated fre uently, based on the e a ples. uality is
therefore built-in
• Evolving living documentation specification by e a ple provides key e a ples, which evolve with the solution
and are understandable to all team members
8.9.1.11 Storyboards/Wireframes
A storyboard is a series of pictures, a si ple fra e by fra e illustration of a scenario or series of actions.
Storyboards are similar in style to comic strips and are powerful because they are an accessible and straightforward
eans of co unication. hey can also use visual language in sophisticated and subtle ways, offering different
viewpoints, or showing e otions e.g. the angry, co plaining custo er the happy holiday aker .
hose involved in creating fil s will often use this techni ue to illustrate the se uence of actions within a scene.
In business, storyboards are a useful tool for getting people to plan and visualise ideas, and for communicating a
new way of working. hey are often used to e press the custo er journey, either for the As s situation or o
Be . usto er journeys cut across functions and incorporate touch points with any processes.
There are two main types of storyboard:
• Presentation storyboards these are useful for showing a process se uence to a custo er or end user. hey
are typically a fra e by fra e presentation of each step. resentation storyboards can be useful as a ore
for al ich icture, to illustrate an intended solution, in a non technical way
• Solution Storyboards these are a ore detailed view of the solution being developed, but at a high level. n
an solution, working storyboards ay co prise Wirefra e iagra s of screen layouts. hey ay be used,
for e a ple, for planning and co unicating the se uence and layout of screens in a solution. his ay be done
before a working prototype is built. Wirefra es can be useful to illustrate the shape of a solution, before the
final aspects of the solution are co plete, as a confir ation of the functional aspects of each screen
he Agile BA can use storyboards to bring a solution to life, and to check the structure before significant work is
e pended on the solution.
118
Company Logo Company Logo
Home roducts Widget eatures
Main Advert Space
Main
Side
Side Product Information Advert
Main Content Menu
Menu Space
Company Logo Company Logo
Home roducts Widget eatures Your Basket
Basket Summary (Including VAT Details)

Product Summary Information
ift Wrap ayment Option

O er ie Specifications rice Main
Side
Advert
Menu Chec out o
Space
Related Product Information Adverts

uy o
Figure 8l: Wireframes
8.9.1.12 Use Cases

se ases were initially proposed by var acobson and are a part of the referred to earlier. hey consist of
a si ple diagra , supported by a specification. hey can be used at a high level scoping or conte t diagra or at
a ore detailed level. hey show user roles Actors associated with particular processes se ases . se ases
can be elaborated to show the detailed interactions for an solution.
The diagram shows:
• tick people Actors user roles associated with the individual use cases
• vals these are the individual use cases processes, functions
• Association ines these lines show which actors will use which se ases
• A bounding bo this represents the solution boundary
he techni ue co prises a diagra which shows the individual se ases and a set of ore detailed written
specifications, one for each se ase oval on the diagra . he diagra is the high level overview of functionality
the se ase specification is a ore detailed definition of how the user needs to interact with the syste to
perfor that functionality. hese are not intended to docu ent how the syste will carry out the task, but what
will be the interaction between the user and the syste , fro that user s perspective.
he se ase specification typically contains
• vent the trigger for this processing to begin
• ser goal the purpose of this processing
• Pre-conditions - the state of the solution before the processing
119
Modelling
AgileBA Handbook
• Post conditions - the state of the solution after the processing

• escription nor al or happy path the e pected se uence of steps the user will follow
• Alternate Flows ows different fro the nor al or happy path
• ceptions or e tensions to the nor al processing how to deal with non standard situations
he detail of what goes on inside each se ase can be docu ented in the te tual se ase specification.
Book Course
place
Admin. Clerk
Enter new
client details
Marketing manager Schedule

courses
Maintain
course details
Course Director
Run course
Course Tutor
Figure 8m: Use Case diagram
Fro the Agile BA s perspective, se ases provide a convenient visual techni ue to show the scope of what will
be in a develop ent, and provide a powerful aid to understanding and structuring re uire ents. hey can be used
to structure ser tory apping e plained below .
8.9.1.13 User Story Mapping
ser tories were described fully in hapter 5. hey are a useful approach to re uire ents because they address
re uire ents fro the perspective of the user role or roles which need the . owever, there can be a large
nu ber of ser tories for any one develop ent. his leads to the danger that they represent a disorganised
heap of work they need to be structured in so e way. A ser tory ap is a visual way of showing the links and
relationships between the individual user stories. t allows a focus on the bigger picture and provides a structure
within which to group the individual user stories. t helps to show priorities and dependencies, which do not stand
out in a pure te tual list of re uire ents.
ser tory aps help to visibly define the content of planned releases of a solution, to confir that the end to
end functionality is delivered coherently. his helps to ensures that the functionality delivered incre entally will
provide groups of features which together provide real business value for the users represented by identifying
the ini u sable ubse also known as the ini u arketable Features F or ini u iable
roduct , as identified fro the ser tory ap .
ser tory aps can be used to depict the end to end functionality of a he e. hey can be odelled alongside
the high level se ase iagra s, using se ases as the top level structure for the ser tory ap.
120
number:
Manage Manage
Payments House-
Room Meals
and Debts keeping
User
Stories
Detailed
User
Stories
Figure 8n: Story map
121
Modelling
AgileBA Handbook
8.9.1.14 Value Chains/Value Streams

A alue trea or alue hain analysis e a ines the ow of organisational activity fro the upplier to the
usto er, through the nputs, rocesses and utputs which occur within the organisation. hese can be used along
with other techni ues at the organisation and strategy level. odelling the processes which ake up a value chain
can be powerful in highlighting where processes do not add value: where they represent waste, and should be
re oved or redesigned.
So ial Re ulatory Environment
Resources An Organisation
ana ement
Labour
Markets
Engineering Production Finance Marketing Sales and
Support
alue Stream ( ore usiness ro ess)
Customers & market

Capital
Markets
Research
Community
Se ond alue Stream
Vendors
(Suppliers)
ompetition
Figure 8o: Value stream mapping
8.10 The Agile BA Role in Modelling

he Agile BA works e tensively with the other roles within the project, so eti es leading, and always collaborating
in their odelling activity. he Agile BA will often use odels infor ally, as part of their own analysis.
The Agile BA:
• dentifies which of their toolkit of odelling techni ues are ost
st helpful ffor the business analysis aspects of the
project, for both analysis and co unication
• Determines the level of detail required from each model at various points in the lifecycle, from conceptual to
granular
• nows when enough is enough in ter s of producing odels with which to support the project
• s able to build odels in a variety of ways ranging fro sticky notes, inde cards, whiteboards and ipcharts to
office software, specialist applications and integrated develop ent suites, where these are appropriate
• ollaborates with both business users and other e bers of the project tea in producing odels, and
obtaining review and refine ent of these
122
• o unicates the various levels of detail appropriate to business users, project level and olution evelop ent
ea roles and the wider group of stakeholders.
• olds the overall role of uardian of those odels that persist and beco e the delivered solution, to act as
the “As Is” models for subsequent developments and to support post-implementation enhancements in an Agile
way
8.11 Modelling and the DSDM Principles

he use of odelling fully supports the rinciples.
Focus
ocus on the business need odelling business processes helps to clarify the business need and define what is in
and out of scope. his allows the tea to focus on what is i portant to the business.
Deliver on time the odel is typically not the end deliverable of the project. he Agile BA should do enough to
ove on, and no ore. i e should not be wasted in creating or aintaining odels unless this is clearly valuable.
The Agile BA should determine what needs to be modelled, and the appropriate level of detail at any point in time,
so that the model is of use to the rest of the team and is created in a timely manner - not too early and not too
late.
Collaborate odelling should never be undertaken in isolation. t should be used as a collaboration tool. arly
iterations of odels will often be created in Workshops.
omise quality the Agile BA will understand that the odels ay be disposable. he level of uality
Never compromise
re uired depends on how the odel is to be used. he Agile BA should not get bogged down trying to apply strict
odelling rules and standards. hey should concentrate on odelling the right thing, to a level which is useful.
ild incrementall rom rm o ndations odels for part of the Foundations, identifying what needs to be built.
he Agile BA should not be te pted to try and odel the world in detail. hey should focus on the i portant,
high priority and risky areas and odel those first.
Develop iteratively
atively odels do not need to be perfect to be of value. he Agile BA should ai to develop the
models iteratively and collaboratively, using them to foster a better understanding of the problem and to inform
terative evelop ent of the solution. etailed odels of a particular feature ay be created, if useful, during the
i ebo , helping the olution evelop ent ea to visualise what needs to be delivered.
Communicate continuously and clearly
learly odels are an aid to co unication. he right odels at the right level will
significantly aid co unication between e bers of the tea .
Demonstrate
ate control - models help to demonstrate control because they can be used to demonstrate what the
tea are intending to deliver and how it is progressing towards its goal, for e a ple by use of visible displays and
selective use of colour.
8.12 Conclusion
Whatever the product or business solution being developed, DSDM recommends an iterative, incremental and
collaborative approach to odelling, to be adopted by the Agile BA and the other e bers of the project
tea , following the ifecycle. his approach places a high de and on co unication, but also gives great
co unication benefits.
• advocates clear and continuous co unication. he develop ent of odels is a key ele ent of this
and for s a significant part of the Agile BA s skill set. odels should be developed iteratively, taking a top down
approach to detail and odelling fro the si different perspectives
• The Agile BA should bear in mind that models should always be an aid and not a bureaucratic overhead
• There should always be a clear focus on addressing the intended audience, using models which they will
understand
• There must be an emphasis on using models to enhance the effectiveness of communication for all team
members and users at all levels of the development process
123
Modelling
AgileBA Handbook
• The use of models, and the formality with which they are created and reviewed, will depend on the nature
of the project in ter s of overall co ple ity and on the skills and e perience of the tea and business
representatives such as Business A bassador and Business Advisor. does not specify what odels should
be created, nor which odelling techni ues should be used, although there are so e well defined, standard
odelling approaches. he si plest rules are do what works for the project and the organisation capitalise on
the skills which e ist within the organisation use diagra s and odels to establish a co on language between
the teams; do “enough” modelling and no more
• Models can be used to make visible the overall picture at a high level, and then to help to break down the
project into co prehensible chunks that are easier to anage than the whole and can be handled incre entally.
odelling helps people to visualise co ple things. n , they can then be used as a basis for incre ent and
i ebo planning
• he objective is always the develop ent of a working solution, or part of the solution, as soon as possible.
owever, an appropriate a ount of design up front F in the Feasibility and Foundation phases and a
few well chosen odels and prototypes throughout the project s iterations can save the cost of e pensive
communication errors
124
9. Timeboxing
and Iterative
Development
1
125
1 1
Timeboxing and Iterative Development
AgileBA Handbook
9.1 Introduction
i ebo ing and terative evelop ent are key practices in , and are the way in which work is done in a
project. ogether these practices help to aintain focus on the evolution of the solution in fre uent and
co plete business focused ele ents, whilst delivering on ti e.
This chapter covers:
• he i ebo structure
• terative evelop ent during i ebo es, including working in iterative cycles and incorporating different
perspectives for prototyping
• uality assurance within a i ebo verification and validation
• he types of detailed infor ation and knowledge that the Agile BA has to e pose and capture, especially during
the i ebo e plicit, tacit and se i tacit infor ation.
• ifferent ways of co unicating during a i ebo and the different learning styles visual, auditory and
kinaesthetic, and how to achieve the ost effective co unication. using show, tell and do
The AgileBA works collaboratively with the whole team in evolving the detail of requirements throughout the
i ebo . hey also have a ajor role in enabling co unication a ongst the different disciplines within the tea ,
using their skills in modelling and prototyping, and their knowledge of different types of information and different
co unication learning styles.
9.2 The DSDM Timebox

i ebo ing is one of s key practices and is used in co bination with the practice of o oW prioritisation
to ensure on ti e delivery. A i ebo provides a level of internal control, to prevent ti e fro just
running out and co pro ising the uality.
defines a i ebo as a fi ed period of ti e, at the end of which an objective has been et. he i ebo
objective is usually co pletion of one or ore deliverables. his ensures the focus for a i ebo is on achieving
so ething co plete and eaningful, rather than si ply being busy . At the end of a i ebo , progress and
success is easured by co pletion of products re uire ents or other deliverables rather than co pleting a
series of tasks.
he opti u length for a i ebo is typically between two and four weeks long enough to achieve so ething
useful, short enough to keep the olution evelop ent ea focused. n a very short and rapidly oving project,
it is possible to have a i ebo as short as a day. n e ceptional circu stances, a i ebo ight be as long as si
weeks. he disadvantage of longer i ebo es is that the tea ay lose focus. By evolving the solution through
a series of short i ebo es, the tea is able to ore fre uently assess their true progress What have we
delivered f their progress is not eeting their own e pectations, this provides early warning of proble s, and an
early opportunity to address the proble s.
i ebo ing is ore than just setting short ti e periods and partitioning the develop ent work. t is a well
defined process to support the creation of low level products in an iterative but controlled fashion. i ebo ing
incorporates fre uent review points to ensure the uality of those products and the efficiency of the terative
evelop ent process.
By anaging on ti e on target delivery at the lowest level, on ti e and on target delivery at the higher levels can
be assured. nitial o oW prioritisation of the work for the i ebo and continual re assess ent of what can be
achieved in its agreed ti efra e ensures that ti ebo es finish on ti e ever y ti e and deliver a working solution
to eet business objectives in line with business e pectations o nasty surprises .
he roject ncre ent and the entire project can also be considered as i ebo es, as they share the characteristics
of delivering a fit for purpose solution in a pre set ti efra e. hese higher level i ebo es are anaged through
the control applied at the lower level the i ebo . nless ualified by roject or ncre ent, the word i ebo
will always refer to a i ebo during the volutionary evelop ent of the phase.
126
9.2.1 Timebox options
very i ebo begins with a kick off and ends with a close out. Beyond this, recognises two styles of
i ebo
• A structured i ebo
• A free for at i ebo
he choice of i ebo style ay be driven by factors such as the availability of the Business A bassador and other
business roles or the type of product being developed.
9.2.1.1 A DSDM Structured Timebox
his is the original style i ebo , which provides a standard, repeatable internal structure to a i ebo .
A structured i ebo co prises three ain steps
• Investigation
• efine ent
• Consolidation
ach of these steps ends with a review.
Close-Out
Kick-Off
Investigation Reﬁnement Consolidation
Figure 9a: DSDM structured timebox
Timebox Nature of the work done Suggested timescale
ick off Short session for the Solution Development Team to Appro 1 3 hours for a 2 3
understand the i ebo objectives and accept the as realistic week i ebo
Investigation he nvestigation includes confir ation of the detail of all Appro . 1 2 of i ebo
the requirements and all the products to be delivered by this
i ebo . ncludes agree ent on
• the i ebo deliverables
• the acceptance criteria for the deliverables
• the easures of success for the i ebo
nvestigation ends with a review which infor s efine ent and
may be a valuable governance touch-point
127
AgileBA Handbook
Timebox Nature of the work done Suggested timescale
efine ent nco passes the bulk of the develop ent, addressing Appro . 6 8 of i ebo
re uire ents and testing technical and business the i ebo
products, in line with agreed priorities
efine ent ends with a review which infor s onsolidation
and may be a valuable governance touch-point
Consolidation ies up any loose ends related to volutionary evelop ent Appro . 1 2 of i ebo
and ensures all products meet their previously agreed
acceptance criteria
Consolidation ends with a review, which informs Close-out and
may be a valuable governance touch-point
lose ut For al acceptance of the i ebo deliverables by the Business Appro 1 3 hours for a 2 3
isionary and echnical oordinator. his is followed by a short week i ebo
i ebo retrospective workshop, to learn fro the i ebo
and to take actions to i prove future i ebo es
9.2.1.2 A Free Format Timebox

he free for at i ebo re ects the style used by other popular Agile approaches such as a cru print. A
free for at i ebo ay be effective where the for ality and structure of the structured i ebo is not
possible or helpful.
Typically 2-4 weeks
Close-Out
Kick-Off
Iterative Development
Figure 9b: Free format timebox
128
Timebox Nature of the work done
hort session for the olution evelop ent ea to understand the i ebo
objectives, to agree what work re uire ents and products will be taken
on in this i ebo and agree their i ebo priorities, and to accept this
workload as realistic
Iterative Development terative evelop ent and testing of individual re uire ents ser tories
and other products, as agreed in the ick off and in a se uence driven by the
agreed priorities for this i ebo .
It may still be appropriate to informally adopt the concepts of Investigate,
efine, onsolidate to converge on the accurate solution for each individual
re uire ent ser tory or roduct, for e a ple understanding the
lower level detail and agreeing the acceptance criteria at the start of the
develop ent of a re uire ent ser tory. his use of nvestigate, efine,
onsolidate per re uire ent ser tory helps to itigate the risk of too
many iterations as the product is elaborated
It is still important that reviews are scheduled during the body of the free
for at i ebo , to aintain business focus and stakeholder buy in
lose ut For al acceptance of the i ebo deliverables by the Business isionary

and echnical oordinator. his is followed by a short i ebo retrospective
workshop, to learn fro the i ebo and to take actions to i prove future
i ebo es
9.2.2 The Agile BA’s role in the Timebox

As with all work in the i ebo , this is a collaborative process re uiring input fro all e bers of the olution
evelop ent ea . owever, the Agile BA works particularly closely with the olution ester and Business
A bassador during ick off to clarify the Acceptance riteria for the i ebo .
uring the body of the i ebo , whether structured into nvestigation, efine ent and onsolidation or a free
format, the Agile BA works closely with the Business Ambassador, Solution Tester and Solution Developer to
confir the scope and objectives of the i ebo and to help the define when the work of the i ebo can be
considered to be one .
he Agile BA captures the e panding detail of the re uire ents as it e erges, docu enting where necessary
in the . owever, the te ptation to write down every detail should be te pered by allowing the volving
Solution to be its own documentation, where appropriate, and encouraging prototyping sessions and reviews
fre uently during the i ebo , in addition to a eview for confir ation at the end of the i ebo . he Agile BA
will encourage visibility of the e erging product by odelling rather than just te t.
he work should ow between all roles within the olution evelop ent ea , with daily collaboration of all roles,
and with analysis, design and testing being integrated with develop ent. he tea will self organise to ensure the
best ow of work and the best use of the skills of each tea e ber. his is where a visible planning board ea
Board can be helpful in anaging the work within the i ebo . Burn down or Burn up charts can also be useful
as a continuous, graphical representation of what is still to do and what has been completed at any point during
the i ebo . hese techni ues allow the tea to keep a ow of work visible, not just for the selves but for all
stakeholders, whilst keeping a business perspective by re aining focused on the ser tories rather than just tasks
within the i ebo .
129
AgileBA Handbook
To Do In Progress Done
onta ts rodu t o in Re ister

a e ontent S reen
tem erms uy o
Details onditions eature
rite
andin
ar etin
a e
ontent
Re unds
ptions
Figure 9c: Team board (Kanban)
ar et
ompleted
or
Estimated
ime o len t (Days)
Figure 9d: Burn-down chart
130
he Agile BA s focus should be on doing just enough analysis. hey will be building on high level analysis
perfor ed during Foundations, which ade visible the end to end big picture . ow they will elaborate detail just
in ti e, related to the i ebo in progress. hey should also ai for just enough docu entation to enable work
to ow and to provide support for subse uent i ple entation and live use of the product. rototyping is the
preferred way of sharing infor ation about the detailed re uire ents ee hapter 8 . rototypes are shared
frequently between the members of the Solution Development Team and also demonstrated or shared with a
wider group of business and technical stakeholders, the Business Visionary and Technical Coordinator, as
appropriate, during the i ebo .
A i ebo usually contains several eviews, so e involving a wider group of stakeholders than just the olution
evelop ent ea . t is key that the wider stakeholder group understands and respects the e power ent of the
olution evelop ent ea . he eview is not a chance to second guess the work of the tea , but rather to
validate it fro their wider perspective. he Agile BA can guide and participate in the prototyping activities of the
olution evelop ent ea during the i ebo .
A final eview will acknowledge acceptance sign off of the work of the i ebo . he Agile BA works particularly
with the business roles at all levels to ensure business validation against the Acceptance Criteria, as they have been
elaborated during the i ebo , to confir that Acceptance riteria have been et and that business benefits
e pected are likely to be achieved.
he Agile BA ay facilitate eview sessions, but all olution evelop ent ea roles should be present, and often
the best person to take the wider business co unity through the eview process is the Business A bassador.
At the end of each i ebo , a short etrospective Workshop will be conducted to allow the olution
evelop ent ea to gather feedback and lessons learned for the i ebo and to inspect and adapt their way
of working to allow i prove ent of the process, if necessary. he Agile BA needs to be an e ual participant in this
workshop and ay have ideas for i prove ent of the working process just like any other e ber of the tea .
9.2.2.1 Daily Stand-up meetings
n a daily basis throughout the i ebo , the olution evelop ent ea will get together for a short, focused
eeting, to understand their progress so far. his is usually run by the ea eader and is a useful echanis for
the early e posure of, risks and blockers issues . he Agile BA is an e ual participant in such eetings.
9.2.3 Timeboxes - the wider context
Application of the ti ebo ing practice described above in conjunction with the practice of o oW
prioritisation, ensures each i ebo delivers a fit for purpose product in the agreed ti efra e. As each i ebo
delivers the relevant products on ti e, it beco es clear that the roject ncre ent is on track and thus the project
as a whole is on track.
Project
Increment Increment
Timebox Timebox Timebox Timebox Timebox Timebox
Figure 9e: Timeboxes in the context of increments and project
131
AgileBA Handbook
9.3 What is Iterative Development?

terative evelop ent is a key practice in . t is the process by which the volving olution, or a part of it,
develops fro a high level concept to so ething with acknowledged business value. t is linked with the idea of
prototyping, introduced in hapter 8. rototypes which e erge fro terative evelop ent are de onstrable
ele ents of the volving olution, reviewed during i ebo es.
ach cycle of the process is intended to bring the part of the solution being worked on closer to co pletion and is
always a collaborative process.
ach cycle should
• Be as short as possible, typically taking a day or two, with several cycles happening within a i ebo
• Be only as formal as it needs to be
• nvolve the appropriate e bers of the olution evelop ent ea relevant to the work being done. At its
si plest, this could be, for e a ple, a olution eveloper and a Business A bassador, or the Agile BA and the
Solution Tester, working together on a particular element of the solution, or it could need involvement from the
whole Solution Development Team including several Business Advisors
As Iterative Development proceeds, it is important to keep the agreed acceptance criteria for the solution, or the
feature of it, in clear focus in order to ensure that the re uired uality is achieved.
9.3.1 Quality in Iterative Development
ne of the defining principles of is to never compromise quality. o achieve this we should a ongst other
things define a level of uality in the early lifecycle phases and then ensure that this is achieved. he challenge then
is how to eaningfully define uality and then easure it in an iterative conte t.
9.3.1.1 Quality criteria
uality criteria deal with re uired characteristics of a product or feature, with these being driven by the conte t
in which the product feature is going to be used. hey define, in easurable ter s, what it will take to satisfy a
custo er the characteristics of a product or service that deter ine whether it eets the e press and i plied
re uire ents. hese are usually the high level criteria fro which specific and ore detailed acceptance criteria for
a particular re uire ent or user story are derived.
9.3.1.2 Acceptance criteria
Acceptance criteria are the ore specific and re uire ent linked characteristics that it will take to satisfy the
custo er and produce a product or service which is sufficiently robust, secure, available etc. By the ti e terative
Development of the solution starts, the main deliverables should already have some acceptance criteria associated
with the fro the Foundations phase.
he Agile BA will have helped the business representatives and the olution evelop ent ea to define high
level acceptance criteria alongside the ser tories during Foundations and recorded these in the . hese are
elaborated in volutionary evelop ent an increasing level of detail will e erge, as appropriate, through each
i ebo . Where tructured i ebo es are used, the detailed work on acceptance criteria takes place
during the nvestigation step. n addition to acceptance criteria that are defined against each ser tory, acceptance
criteria ay also need to be applied to groups of re uire ents, as they ake up releasable chunks of the volving
olution. ee hapter 5 for ore detail of ser tories, their acceptance criteria and the hierarchy of re uire ents
which ay e erge.
a i ation an eri cation
he Agile BA is the guardian of the evolving set of re uire ents in the through a re uire ent lifecycle of
elicitation, analysis, validation and anage ent. ee hapter 11 .
here are two clear aspects to the testing which ust be done within i ebo es
• Validation
• erification
132
alidation answers the uestion Are we building the right thing whilst verification asks Are we building the thing
right
n an terative evelop ent conte t, validation does not need to be a separate activity the process of collaborative
design of the solution with direct involvement of Business Ambassador and Business Advisor roles means this
happens naturally during the i ebo , especially via how and ell sessions and reviews. owever, verification
activity still needs to be e plicitly considered, to ensure it is fully integrated within the terative evelop ent cycle.
The key question is whether or not the acceptance criteria have been met in a meaningful way, which meets the
business need and will deliver the e pected benefits.
9.3.2 Testing during Iterative Development
e uire ents during terative evelop ent ay be tested fro 3 key perspectives
• Functional
• sability
• Non-functional
n a si ple feature, a cycle ay enco pass all three perspectives at the sa e ti e. owever, where terative
Development of a feature involves many cycles, involving several different people, the team may decide to focus a
cycle on one or perhaps two specific perspectives rather than covering all of the at the sa e ti e.
For e a ple, the tea ay decide to focus early cycles on the functional perspective of a re uire ent ensuring,
and de onstrating, that the detail of the re uire ent is properly understood and agreed. his ay be followed by
cycles focussed on usability ensuring interaction with the solution is effective and efficient.
ater cycles ay then focus on ensuring the re uired non functional uality e.g. perfor ance or robustness is
achieved, that all tests pass as e pected, and all acceptance criteria for the feature are et.
Iterative Development Perspectives - The FUN Model

Functional:
• Demonstrating how the business functionality has been achieved
Usability:
• Allowing the user of the solution to interact with the evolving solution
Non-functional:
• Demonstrating how issues related to, for example, performance, capacity, security or maintainability,
have been accommodated
The Agile BA will work with the Solution Development Team, Technical Coordinator and Business Visionary, to
ensure that testing is done from all of these perspectives, and also that end-to-end testing is performed as soon as
possible, and regularly, not all left until the end of a long series of i ebo es.
A further type of prototyping is a roof of oncept. his is typically a throwaway prototype, built to test the
feasibility of an approach or to try out different options. his ay be used during i ebo es or so eti es during
Foundations or even Feasibility. ne or ore of these throwaway roof of oncept prototypes ay be created in
order to e plore those options and work out the best way forward.
133
AgileBA Handbook
9.3.3 Solution focus

identifies that the solution ay be considered to have a nu ber of architectural layers.
he e a ple used here relates to business syste develop ent but the concept can also be
applied to a non project, such as a arketing ca paign.
terative evelop ent ay follow an approach in which i ebo es deliver hori ontal slices of
the solution, vertical slices or a co bination of the two.
Horizontal Approach
he hori ontal approach considers the solution layer by layer with each i ebo incre entally
delivering increased co ple ity of business process or layers of co ple ity co pleteness as
regards technology.
he advantage of the hori ontal approach is that it allows an initial sight of the full breadth of the
solution very early on. he disadvantage is that nothing works fully until the last hori ontal slice is
delivered. herefore no business benefit can accrue until that point.
Vertical Approach
he vertical approach slices through ultiple layers of the solution with each i ebo delivering
one or ore fully functional features.
The advantage of the vertical approach is that delivery of prioritised features may enable
olution ncre ents to be ore uickly and fre uently deployed into live use. he disadvantage is
that the full breadth of the solution is not clear until late in the project.
Combined Approach
he co bined approach starts by focussing one or two i ebo es on thin hori ontal slices of
the solution in order to fully understand the breadth of the solution before reverting to a
vertical approach to incre entally 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 incre ental delivery of business value into live use is also achieved. here
are no obvious disadvantages.
9.3.4 Controlling Iterative Development
ach terative evelop ent cycle is intended to result in an incre ental change to the volving olution that brings
it, or ore probably a feature of it, progressively closer to being co plete or done .
It is quite possible, however, that the review of such an incremental change may reveal that the solution has evolved
in a way that is not right. nder such circu stances it is i portant, wherever possible, to have the option to revert
to the previously agreed version and under take another cycle based on what has been learnt and on any new
insight arising fro the review. onfiguration anage ent of the solution is therefore an i portant consideration.
9.3.5 Dealing with Change within a Timebox
terative evelop ent enables a tea to deliver a product that is genuinely fit for its intended purpose by the end
of a i ebo . onverging on the accurate solution is achieved through constant refine ent of the product, based
on review by the business, led by the Business A bassador, supported by the Agile BA. t is vital that the decisions
about whether, at any given time, a solution appears right, or needs to change to make it right, are both quick and
sure. f decision aking is not uick and sure, there is a real risk that significant ti e will be lost by waiting for
decisions to be ade or wasted as a result of decisions being over turned . t is i portant that all e bers of the
Solution Development Team are appropriately empowered to handle any change that falls within the agreed scope
of the i ebo objectives, without the need for a for al change control process that reaches beyond the tea .
does not dictate the level of e power ent. he project level roles will nor ally want to clarify the level to
which the Solution Development Team are able to make decisions without reference to them, and which decisions
it would need the to refer often via the roject anager to the Business isionary, echnical oordinator or
Business ponsor. he factors involved in their need for this escalation of so e decisions include both project and
business risk.
134
For e a ple, in so e projects organisations the olution evelop ent ea will be e powered to ake their
own decisions on whether to descope hould ave re uire ents in others they ay need to consult the Business
isionary.
The following scenarios mean a change of scope and therefore are typically beyond the empowerment of the
Solution Development Team:
• hanging the breadth of the solution i.e. adding additional high level re uire ents after Foundations or
dropping ust ave re uire ents during i ebo es
• ncreasing the percentage of ust ave effort
owever, negotiation around the detail the depth of the solution can generally be handled by the e powered
olution evelop ent ea without the need for any escalation or specific approval by those outside the olution
evelop ent ea .
egardless of whether changes are dee ed to i pact scope or not,, typically the olution evelop ent ea is
e powered to operate within agreed boundaries without the need to escalate to the roject anager or other
project level roles.
9.3.6 Iterative Development and the Agile BA
terative evelop ent allows the high level re uire ents established during Foundations to be e plored and
evolved to a greater level of detail using iterative cycles and reviews, during the i ebo es.
ach iterative cycle is intended to bring the part of the solution being worked on closer to co pletion. t involves
collaborative working of the olution evelop ent ea and possibly other stakeholders.
terative evelop ent often involves prototyping, ock ups and odels. hese can be used to establish
re uire ents, confir e pectations and test the achievability and achieve ent of those objectives. he role of
the Agile BA in helping to define these prototypes and ock ups draws upon the use of personas, scenarios and
odelling techni ues hapter 8 . he Agile BA ay also facilitate the eview sessions hapter 7 .
Throughout the phases of the DSDM lifecycle, requirements are investigated and actively elaborated at increasing
levels of detail. n an Agile project, the Agile BA ust elicit the re uire ents at a level which gives only just
enough detail for each lifecycle phase s objectives to be et.
he Agile BA will need to be aware of the e perience and e pectations of stakeholders in how and ell sessions
during the early stages of the project. here is often an over e cite ent when early prototypes are seen. owever,
these are usually not yet complete and robust, and will require a considerable amount of work to make them
production ready. Friction can arise between the business representatives and those developing the technical
aspects of the solution, which the Agile BA, with a view and understanding of both business and technical worlds,
can be invaluable in seeing and alleviating.
his risk of the business users seeing so ething early and istakenly thinking it is finished is ore than offset by
the value to the business of early visibility of parts of the solution. hese can be checked to ensure the business
value needed is likely to be achieved and gives the opportunity to discover any missed or changed requirements or
priorities.
As the solution is being evolved by the Solution Development Team, the Agile BA will encourage frequent “Show
and Tell” sessions for business representatives, and ensure that they have hands on opportunities for use, as soon as
possible, in order to ensure the solution which e erges is a good fit to the real business re uire ent.
he Agile BA ay also directly facilitate these how and ell sessions see i ebo eview Workshops hapter
7 ensuring that discussions and suggestions are kept on track and the incre ent s objectives are kept in view.
The Agile BA often records the outcomes of such demonstrations, ensuring that new requirements, changes and
agree ents are captured.
The Agile BA’s skills in analysing scenarios, modelling and prototyping are essential in keeping the end-to-end view
of business processes visible, whilst the tea are reducing the solution into its constituent parts.
135
AgileBA Handbook
The Agile BA will also facilitate conversations between the different disciplines within the Solution Development
Team, and ultimately ease the transition of the developed, tested solution into the business-as-usual world via liaison
with the elease anage ent function of the organisation.
9.4 Different Knowledge Types

A ajor difficulty when eliciting re uire ents is finding out wha
whatt people want, or think they want, or what they
believe or know about their jobs. o on sense i plies that this should be a straightforward task, and all you
have to do is go and talk to the . nfortunately, this is not the case. u an beings perceive and understand their
work in very different ways.
A newco er to a job, who is still learning, ay be able to e plain the processes very well perhaps better than
so eone who has been doing the job for years. owever, a ore e perienced person will be better able to
e plain why the job needs to be done at all. he knowledge the BA is trying to access can be
• plicit knowledge
• Tacit knowledge
• Semi-Tacit knowledge
9.4.1 Explicit knowledge
his is knowledge that is known openly, in a for that can be e plained easily in words. usto er nu ber for at,
loan bands, categories of product are all plicit knowledge. nterviews, uestions, workshops and observation will
work well with this kind of knowledge.
9.4.2 Tacit knowledge
acit knowledge is not available to conscious introspection or verbalising. t can be subdivided into
• Implicit learning - occurs without any conscious learning process being involved
• o piled skills are initially learned e plicitly, but subse uently they beco e habitualised to the point where
the conscious co ponent is lost. o eone who is in a state of unconscious co petence is often no longer
consciously aware of all the steps they take to do the job. herefore they will o it infor ation without knowing
that they do
Presenting scenarios of use as models, and encouraging end users to demonstrate scenarios of their work
acco panied by a co entary of their actions known as rotocol Analysis can bring out infor ation not easily
accessible in other ways. eveloping ele ents of the volving olution and reviewing these with appropriate
stakeholders will help in drawing out tacit knowledge. Additionally, diagra style odelling can help to identify
issing infor ation, which ay be tacit knowledge too.
9.4.3 Semi-Tacit knowledge
Semi-Tacit knowledge can be subdivided into 3 categories:
• hort and long ter e ory the short ter e ory is a buffer of about 7 concepts plus or inus 2 . his
is temporary “working area” of storage and regularly replaced, with no record of what was there, seconds after it
has been used
• Taken for granted knowledge - this is the kind of information that the sender has and does not realise it,
therefore they do not convey it to their potential audience
• Front and back versions this covers the ti es when the Agile BA is told what should be happening in a work
area, rather than what actually is happening. his ay not be a deliberate isleading of the Agile BA, just a
perception of what they probably want to hear, i.e. the official process, not the unofficial one that is actually
used
136
9.5 Communicating Effectively - Learning styles
Visual See it
Auditory Hear it / read it
Kinaesthetic Feel, do, touch, smell
Figure 9f: Learning styles
eople s learning styles, and ways of co unicating and receiving infor ation, vary. he Agile BA will recognise this
and work with the Solution Development Team to present information in the best way for its target audience to
understand.
A factor in the way people register infor ation and knowledge is their key sensory channel s preference. he
ajor senses used are
• isual seeing diagra atic, pictorial presentations help here
• Auditory hearing, speaking e planations and te tual presentation assist this
• inaesthetic feeling, doing, touching, s elling hands on e perience of using a part of the solution accesses the
e otions and engaged this area
In demonstrating parts of the volving olution how and ell , we usually co unicate best with those with a
visual preference.
By explaining and discussing this, we co unicate with those of an auditory preference.
137
AgileBA Handbook
here are any ways of co unicating the volving olution, as shown in the picture below.
Screen-based, Role play Low tech

animation
Experimental Show, tell Video

and do
Figure 9g: Different types of prototyping
t is often only by allowing the users to be hands on with a prototype that the kinaesthetic preference is accessed.
his prototyping ust be ore than just how and ell de onstrations it ust include do and try .
9.6 Summary
The Agile BA works within the Iterative Development process to elicit, analyse, validate and manage the
re uire ents at appropriate levels of detail at different phases of the lifecycle. When detailed re uire ents are
being elicited, within i ebo es and during terative evelop ent, the Agile BA can help to
• eep the tea s focus on the end to end process, whilst working on a s all subset of the solution during any
one i ebo
• nsure that re uire ents ser tories re ain the focus rather than tasks
• nsure that acceptance criteria are fully thought through by the Business A bassador and olution ester
• Capture the evolving detail of requirements, at an appropriate and useful level for both current work and for the
support of the solution after implementation
• se appropriate techni ues to uncover different knowledge types and to co unicate, using scenarios,
prototyping and modelling, to accommodate the different communication needs of all those involved with the
project
138
10. Requirements
Planning and
Estimating
Throughout the
Lifecycle
1
139
1 1
Requirements Planning and Estimating Throughout the Lifecycle
AgileBA Handbook
10.1 Introduction
he Agile BA works throughout the project, with the project level roles and olution evelop ent ea
and with a wider stakeholder group, to evolve the re uire ents fro an initial idea to a detailed level, incre entally.
As seen in earlier chapters, the level of detail in the re uire ents alters throughout the lifecycle. As re uire ents
beco e ore specific, esti ates beco e ore precise. his drives the approach to planning in Agile projects. his
chapter should be read in the conte t of hapter 5 in particular, which discusses e uire ents and ser tories.
10.2 The Importance of Requirements Planning - How

Much Detail?
he Agile approach is to agree re uire ents at a high level early in the project, along with high level acceptance
criteria and then to further analyse the to provide just enough detail, just in ti e, throughout the project. f we
define low level detail too early it is wasteful, because re uire ents will inevitably change with ti e and increased
understanding. herefore we leave detailed re uire ents analysis until just before each particular feature of
the solution is to be built, in order to avoid wasted work. his approach also allows for learning as the project
progresses, letting earlier e perience in uence the detail of later ele ents of the solution. owever, it is also
essential to ensure that the project re ains focused on clear strategic goals, in line with the organisation s ission
and the project s vision and objectives. We ust ensure that the Agile solution is not reactive and disjointed.
he Agile BA is the guardian of the re uire ents throughout the project, but not the owner. t is essential
that ownership is clearly held by the business the Business isionary in particular. he Agile BA is also a key
co unicator of the o Be perspective within the project, supporting the Business isionary and Business
ponsor. he Agile BA has the skills to analyse and present an end to end view of the business processes and the
value strea s across depart ents and functional areas.
In addition to being fully integrated with the Solution Development Team during development, the Agile BA works
with the project level roles fro re roject and Feasibility through to ost roject and benefits assess ent. he
Agile BA brings structure to the overall requirements scope, retaining traceability of each requirement to the
overall objective of the project and fro the re uire ent s first entry into the project to its final deploy ent and
benefit realisation or its e it fro the solution, if descoped. hapter 11 e a ines the re uire ents lifecycle and
traceability in ore detail .
140
10.3 Requirements Planning Through the Lifecycle
Detailed requirements emerging

Timebox
imeb Timebox Timebox Timebox Timebox
• Feasibility study
• Outline business case • Timebox plans
• Key stakeholders • Completed product
• Outline plan
• Feasibility prototype
• Prioritised high level requirements
• Full business case
• Key stakeholders, roles and empowerment
• Project plan
• First increment plan
• Solution prototype
Figure 10a: BA involvement in a DSDM project
10.3.1 Requirements at Feasibility

At Feasibility, the project level roles need to be established Business ponsor, Business isionary, echnical
oordinator, roject anager and the Agile BA. rior to the project, a level of strategic business analysis will usually
have been perfor ed. he Agile BA for the project will bring this knowledge and analysis into the project, or access
it on behalf of the project, providing organisational conte t to the project.
er s of eference fro re roject trigger the start of Feasibility. his is the first state ent of any kind of
re uire ent. he Agile BA will clarify the project vision e bodied by this, for ulate the objectives and very high
level acceptance criteria with the project level roles and a wider group of stakeholders, as necessary, and ensure the
sharing of the vision for the project between appropriate stakeholders.
he Agile BA will work with the project level roles to develop solution options and an outline Business ase for
these. Working particularly with the echnical oordinator, Business isionary and roject anager, they will help
to identify the ost valuable se uence of develop ent, as input to the first cut elivery lan for the project. he
Agile BA will usually have a role in the presentation of these options to a wider group of corporate stakeholders.
he option to be pursued will be chosen by the end of Feasibility by the Business ponsor and Business isionary,
and usually be approved by a corporate steering co ittee or other authority outside of the project.
At this point, he es and pics begin to e erge and an initial tory ap ay be created, as an early road ap for
the project.
141
AgileBA Handbook
number:
Manage Manage
Payments House-
Room Meals
and Debts keeping
User
Stories
Detailed
User
Stories
Figure 10b: Story map
hapter 5 discusses ser tories, pics and he es and hapter 8 odelling shows the concept of tory
apping.
10.3.2 Requirements at Foundations
he project will be scoped and defined ore fully during Foundations, following the decision to fund further work
related to a particular option.
he Agile BA will be instru ental in the clarification and disse ination of the project vision, objectives and
acceptance criteria and in the evolution of the Business ase for the project. his will be done in collaboration with
the roject anager, other project level roles and key stakeholders. he Business ase will be elaborated during
Foundations fro the outline Business ase produced during Feasibility, and ay continue to evolve during the
project as ore detail is discovered. t will be used throughout, to guide and re evaluate the project. he features
and benefits defined within the Business ase will be subject to o oW prioritisation and will be a basis for
benefits assess ent ost roject.
n planning during Foundations, the first incre ent of the project will deliberately be defined ore fully than later
incre ents, since this is ore predictable. oo uch work on later incre ents will often be wasted as changes
occur during the project s ti eline. owever, later incre ents should be envisaged sufficiently to assess whether
the whole project is likely to be realistic and to spot any significant risks to later incre ents. he concept of a
project road ap is useful here, to outline the projected elivery lan.
142
n addition to the Business ase, and participating in ick off and ision Workshops, during Foundations the Agile
BA works with stakeholders to establish several essential artefacts, including:
• he rioritised e uire ents ist
• he olution Architecture efinition for the high level design of business processes and organisational change.
These might include:
A onte t coping iagra
odels to define and analyse the area of study rocesses, ata, eople, ocations, vents, and
e uire ents
ater in this chapter, we will look particularly at the as the repository for re uire ents, and the planning and
esti ating of re uire ents.
he key ele ents of the Agile BA s work during Foundations are
• Working with the Business Visionary and other stakeholders to establish a Business Case for the chosen option,
sufficient to guide the project
• Working with the Business isionary and Business A bassador s to ensure that the re uire ents identified are
able to eet the e pected business needs, deliver the re uired benefits and that the ust ave re uire ents
alone would be sufficient to for a ini u sable ubse
• Working with the Technical Coordinator to establish an understanding of the proposed physical solution, at a
high level, with the development and presentation to stakeholders of a Solution Prototype
• stablishing the high level re uire ents, following the e uire ents ifecycle of licitation, Analysis and alidation.
he will be a ajor aid to e uire ents anage ent and ocu entation throughout the project see
hapter 11
• egotiating the and its priorities, ensuring that it is at the right level and that it is co plete enough to allow
the whole olution evelop ent ea to esti ate and plan the first incre ent, without being so detailed that
it constrains the creativity and e ibility of solution develop ent. he Agile BA, as an integral e ber of the
olution evelop ent ea , will be involved in esti ating. sti ating is discussed in ore detail later in this
chapter
• Facilitating Workshops for project ick off, visioning, risk analysis and other agreed ele ents, e cept where an
independent Workshop Facilitator is justified
• anaging the evolving re uire ents with just enough detail to allow understanding and esti ating
• aining validation and sign off for ally or infor ally of the baselined set of high level re uire ents in the ,
with ost focus and detail being addressed to the first planned incre ent of the project.
uring Foundations, the Agile BA has an i portant role in helping stakeholders to see practical and valuable
groupings of re uire ents fro a business perspective he es , and in highlighting dependencies and interactions
between re uire ents, as well as clarifying the business value of each re uire ent. he Agile BA will also work
with the echnical oordinator to identify se uences of business process ow to i prove the effectiveness of
develop ent towards business value. A clear set of re uire ents, at a high level, will i prove focus on the business
need and enable the whole tea to better esti ate the effort re uired. hey will also aid assess ent of the relative
value of different re uire ents or groups of re uire ents to the business.
uring Foundations, the Agile BA needs to bring together the , at a level of detail which is just su cient to
allow esti ating for the i ebo es. his will typically be in the for of ser tories hapter 5 . hese will be
e panded during the i ebo es into specific details.
For the elivery lan, suitable feature based groupings of ser tories to be addressed by the i ebo es need
to be selected and a clear objective identified for each i ebo . he business benefits should be para ount, and
the breakdown into i ebo es should ai to a i ise early delivery of the best possible business benefit. he
Agile BA will collaborate with the project level and olution evelop ent ea roles to in uence the e ergence
of plans that are practicable from a business and implementation point of view and meet the business need, whilst
delivering value early. rouping by function or feature, business goal, set of related user goals is often appropriate.
143
AgileBA Handbook
hese feature based groupings should be s all, to keep the i ebo es short.
he olution evelop ent ea roles will typically be represented during Foundations and will be involved in the
esti ating of work to be done in the i ebo es. he Agile techni ue of lanning oker, which ay prove useful for
this purpose and can be used within an sti ating Workshop, is described later in this hapter.
he Agile BA will work with the roject anager and the olution evelop ent ea to aintain a business
focused delivery se uence by ensuring that early i ebo es address high priority business functionality. he
technical and architectural co ponents to support this functionality can be i portant in a new syste new
architecture. o ensure the correct architectural foundation is in place, the Agile BA should work closely with the
echnical oordinator.
10.3.3 Requirements during the Timeboxes
he work planned for a i ebo should ideally be a s all, usable subset of business functionality.
o eti es eploy ent ay also be a part of the sa e i ebo . ore often, eploy ent will be tied into the
release procedures and ti escales of the organisation. ach i ebo should have a planned outco e, in the for
of a clear and business focused objective.
uring a i ebo , the Agile BA ay be a sensible choice for ea eader because of their skill in facilitation.
owever, the choice of ea eader ulti ately rests with the olution evelop ent ea .
At the start of the i ebo , the selected features fro the which have been allocated to the i ebo need to
be further analysed. A ore detailed tory ap ay be created here, and the tea will typically display their work
on a tory Board which will re ain a visible tracking of progress throughout the i ebo .
he order of work within the i ebo es should be driven by the business objective for the incre ent and for the
i ebo . here ay also be a need for architectural co ponents to be in place on which to build the functionality,
and these ay in uence the se uence of develop ent. owever, business focus should be the pri e driver.
Additionally, risk should be taken into account in determining the sequence, typically with the more risky elements
being addressed early.
he pattern of detailed working within a i ebo , with its odelling, rototyping and eviews terative
evelop ent is defined in hapter 9.
10.3.3.1 Timeboxes and MoSCoW
n order to ensure that a i ebo will finish on ti e, there has to be a level of e ibility in the deliverables it ust
achieve. As lower level details of the re uire ents e erge, further prioritisation will be possible and also necessary.
he o oW classification of re uire ents provides the basis for decisions about what the tea will do over the
whole project, during any incre ent and during any i ebo within the project, i.e. a single re uire ent, during its
develop ent, will have three o oW priorities one for the roject, one for the roject ncre ent and one for
the i ebo . At a single point in ti e, a particular re uire ent ay be ust ave for the project, a hould ave
for the ncre ent and a ould ave or a Won t ave for the current i ebo .
As new re uire ents arise or as e isting re uire ents are defined in detail, the decision ust be ade as to how
critical they are to the success of the current work. All priorities should be reviewed throughout the project to
ensure that they are still valid. t is typically the descoping of lower priority re uire ents, if necessary, that enables
the tea s to deliver on ti e when proble s arise or unforeseen re uire ents need to be acco odated.
10.4 The Prioritised Requirements List (PRL)

he is first created at a very high level during Feasibility, is refined during Foundations and persists through
the project as the central repository for scope, prioritisation and detail. nitially, re uire ents ser tories will
be at a high level and will be fra ed in ter s of what is needed, rather than how it will be achieved although
the acco panying olution Architecture efinition will give the fra ework for the solution which will evolve,
and a solution prototype ay be created. ach re uire ent will be ualified by high level acceptance criteria
and an agreed priority. he level of detail of the re uire ents in the at this ti e needs to be sufficient for
the practicability of the first incre ent to be assessed and with sufficient detail for the work of i ebo es to be
144
esti ated by the olution evelop ent ea . t is also useful at this point to deter ine dependencies between
re uire ents and to consider the business value of each re uire ent and group of re uire ents .
he e act for at of a will depend upon the type of project and the organisation sponsoring it. owever, an
illustration of a possible is given below.
Req id Req/Story Req/Story Pry Confirmation Acc Criteria Source Owner Size Business
Short Name Description M, S, S,M, Value
“As a... I need C, W L,XL HML
...so that
STK001 Customer As a M Scenario 1: Security: no Order Order S H
Order Customer, I Customer has unauthorised Clerk Manager
need to place ordered previously: person can place
an order so Given an existing an order at any
that I can customer account, time (24 hours per
have food When Customer day or 24/7/365);
delivered to confirms an order,
my house. Then: can place the
Either: Account order at any time
credit is good, (24 hours per day
Conversation: The order scheduled or 24/7/365);up to
Order Office Manager for delivery and including
emphasised the need Or: Account credit delivery
for secure day and bad, Order is
night ordering rejected and
customer notified.
Figure 10c: Prioritised Requirements List
10.5 Estimating within a DSDM Project

sti ates can be used for several purposes to ake a Business ase to assess whether a project is feasible to plan
project costs and schedules to co unicate with stakeholders.
In order for estimating to be meaningful:
• sti ates need to be realistic and cover the risk associated with unknown factors
• sti ates 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
• sti ates are e pected to be revalidated throughout the project as the understanding of the re uire ents
deepens and as the olution evelop ent ea s actual delivery speed velocity is clarified
10.5.1 The estimating process
sti ating often involves breaking a project down into co ponent parts. here are any ways of doing this it
ay be by tasks, products, se ases, ser tories, function points, re uire ents, features or tangible solution
co ponents. hese co ponents ay then be si ed either relative to each other tory oints or by using standard
si e and co ple ity guidelines for co ponents or tasks. he Agile BA will have analysed the re uire ents of the
project and hold artefacts which can be of great value to the esti ating process. n a software develop ent project,
these ay be such things as ser tories, se ases, functional and data odels.
10.5.2 The difference in estimating within a DSDM project
he single biggest difference in esti ating for an Agile project is that contingency is anaged within the o oW
prioritisation of the features. hus, a key role for the Agile BA is to analyse and ake visible the o oW
priorities and also the dependencies between the features and re uire ents.
145
AgileBA Handbook
10.5.3 Estimates and requirements detail
Evolutionary
Development
Project Go / No go Project Go / No go
Less Accurate
Less Detail
Typically <10
requirements
by end
Feasibility Do not go into
Requirement detail
Requirement Detail
Estimate Accuracy
too early
Typically <100
requirements
by end
Foundations
Do not be held
hostage to early
estimates
Typically >100
More Accurate
requirements
More Detail
by end
Evolutionary
Development
Figure 10d: Estimating throughout the lifecycle
hroughout the lifecycle phases, the level of esti ating will beco e ore reliable and precise. nitial esti ates
during Feasibility will be based on the li ited infor ation known about the project, and on e perience of si ilar
solutions in different projects. sti ates in the for of a range and a degree of confidence will be appropriate
here. n Foundations, as ore beco es clear, the esti ates can be refined. owever, the Agile BA should resist the
te ptation to try to achieve re uire ents in low level detail at this point, in order to ake esti ates ore reliable.
t is wasted effort, as e perience shows that re uire ents will change with ti e and incre ental learning. t is
better to have a high level state ent of features envisaged se ases, ser tories, rocesses and their
acceptance criteria and allow detail to evolve later. uring later phases, esti ates will beco e ore precise, and
can also be assisted by actual easures of velocity.
10.5.3.1 Planning Poker
sti ating in an Agile project can use a variety of techni ues, including lanning oker, an Agile esti ating and
planning techni ue popularised by ike ohn. t is a consensus based approach to esti ating, using relative
esti ates to si e ser tories against each other. ach participant has a deck of lanning oker cards with values in
a series close to the Fibonacci series , 1, 2, 3, 5, 8, 13, 2 , 4 and 1 . he values can be used to represent story
points a relative easure , ideal days, or other units agreed by the tea who are aking the esti ates.
When a feature has been discussed, the participants ake their individual esti ate of the si e of the work involved.
All esti ates are revealed si ultaneously and any significant differences typically the highest and the lowest
esti ates are discussed. he process is repeated until consensus is achieved or until the feature is put aside
pending additional infor ation.
146
he benefits of this approach are
• It reduces peer pressure
• It creates a forum for discussing and understanding the requirements
• It allows several people to estimate, which is usually more accurate
• It involves those who will be doing the work in the estimating
10.5.4 The Estimating Workshop
ne of the best ways of esti ating during Foundations, and again at i ebo level, is to hold sti ating Workshops,
where those who will be responsible for delivery of the project carry out the esti ate. uring this Workshop, the
re uire ents need to be clearly understood and presented. he techni ue of lanning oker described above can
be used as a collaborative way to arrive at esti ates.
Whilst the Agile BA may be able to facilitate such a Workshop, it is more likely that their role as a participant is
ore i portant, inputting to the content of re uire ents detail. herefore a ore independent facilitator should
be considered.
10.6 Conclusion
The Agile BA is the guardian of the requirements and has the perspective to understand their interrelationships
and their strategic i portance. hus, they can guide the rest of the olution evelop ent ea and the Business
isionary in the i plications of the tea s choices and priorities. he e power ent that the tea ust accept and
use cannot be underesti ated and the Agile BA, along with the roject anager and the project level roles ust
encourage and facilitate the enact ent of this e power ent.
sti ating can be based on the re uire ents ser tories plus odels, prototypes etc. developed by the Agile
BA. he Agile BA can enable the roject anager, project level and the olution evelop ent ea roles to
understand these artefacts and their interrelationships.
he Agile BA ay facilitate any Workshops within the project. owever, care should be taken that they do not
lose the effectiveness of their role as a contributor to the sti ating Workshop.
147
AgileBA Handbook
148
11. The Requirements
Lifecycle in an Agile
Project
1
149
1 1
The Requirements Lifecycle in an Agile Project
AgileBA Handbook
11.1 Introduction
he Agile approach to re uire ents is to clarify the project objective and Business ase and then to define
re uire ents, at a high level only, early in the project. he definition of detailed re uire ents is deliberately left
until just before it is needed just before that particular aspect of the solution is developed and built. his avoids
waste and rework. t ensures that the product can evolve to re ect the needs of the business at the ti e of
solution building. t also allows for learning during the project and for change to be e braced.
owever, the risk inherent in this incre ental approach to defining re uire ents is that an inconsistent or internally
con icting set of re uire ents could evolve. his is where the skills of the Agile BA are essential. he Agile BA
ust facilitate the evolution of re uire ents fro high level objectives down to low level detail at the appropriate
ti e, whilst keeping the consistency and focus, co pleteness and prioritisation of the re uire ents set as a whole.
he traditional business analysis discipline of e uire ents ngineering is still appropriate when applied in an
Agile way. e uire ents ngineering acknowledges that each re uire ent has a lifecycle of its own, fro its initial
elicitation, through its analysis and validation to its eventual incorporation into the solution, or its rejection or
descoping.
n this chapter we look, fro an Agile perspective, at the e uire ent ngineering lifecycle of
• licitation
• Analysis
• Validation
• Management and documentation
his chapter addresses the approach the Agile BA takes, both re roject and throughout the lifecycle,
including ost roject Benefits Assess ent. t shows how the Agile BA ensures that the re uire ents for a
consistent and coherent whole. he re uire ents are captured and recorded appropriately, as they evolve and
e pand in detail, using key Agile practices during the process.
11.2 The Role of the Agile BA in Handling Requirements

he responsibilities of the Agile BA within a project are to ensure that the business needs are properly
analysed and are correctly re ected in the volving olution. n a day to day basis, the Agile BA anages the
docu entation and products related to business re uire ents. hey ensure that business i plications of day to
day decisions ade by the project level and olution evelop ent ea roles are thought through. hey keep
re uire ents aligned to the purpose and objectives of the project, as well as the needs of the end users and
custo ers of the product. hey are the facilitator, negotiator and ediator in conversations between business and
technical roles. hey have the skills to ake visible the i plications of prioritisation and the decisions to include or
descope re uire ents. hey beco e the central point of co unication about what is re uired and why for both
the project level and olution evelop ent ea roles.
he role of the Agile BA is to be the guardian and cha pion of the re uire ents. hey do not own the
re uire ents it is i portant that ownership is accepted by the business representatives . owever, the
anage ent of a clear, useful and incre entally evolving re uire ents set is the responsibility of the Agile BA.
As we saw in hapter 1, the role of the Agile BA ay be wider than the Agile project they ay also work in
a corporate planning fra ework or a strategic progra e. e uire ents ngineering activities are valid for
re uire ents work at any level.
150
11.3 The Lifecycle of a Requirement
A re uire ent ay begin life as an idea, a need, or a state ent of a proble to be addressed. he first
re uire ent of the project is its objective, e pressed in outline in the er s of eference and clarified
during Feasibility. Fro this point, a hierarchy of re uire ents begins to e erge, e panding fro the Business
ision and project objective to ajor he es, to pic tories high level re uire ents of the and down to the
detailed ser tories elaborated during volutionary evelop ent.
Elicitation Validation
Management and documentation of requirements
Analysis
Figure 11a: Requirements Engineering Lifecycle
very re uire ent passes through the following stages

• licitation
• Analysis
• Validation
• Management and documentation
These requirements lifecycle stages are not serial, with Management and Documentation happening throughout
and licitation and Analysis running together iteratively, overlapping with alidation as the re uire ents beco e
ore ature.
11.3.1 Elicitation
licitation is the identification, e traction and capture of the re uire ent. n an Agile project this is typically
achieved by:
• Face to face conversations
• bservation
• Facilitated Workshops
• Demonstrations of working elements of the solution
• Scenarios
• Modelling and Prototyping
hese approaches can work together. For e a ple, scenarios can bring to life business situations and can provide
the basis for prototyping and testing.
toryboarding scenarios can be seen as a for of low fidelity prototype.
151
AgileBA Handbook
licitation is not a trivial task any users do not know clearly what they do want fro the solution, until they see
so ething. Also, knowledge that the users have ay be
• plicit easy to e plain and capture
• Tacit: hard to capture because people do not even know that they are holding it
• Semi-tacit: where things are taken for granted, or only held in short-term memory and therefore not really
remembered or known
any re uire ents are o itted because they are taken for granted or erely forgotten. he Business Analyst
is a detective, uncovering the true re uire ents as the project progresses and using Agile practices and business
analysis skills to identify gaps and disconnects.
11.3.2 Analysis
ach re uire ent needs to be analysed to clarify its eaning and to deter ine whether it is
• ealistic
• na biguous clear enough to be understood by different stakeholders
• Feasible technically, financially, socially
• Congruent with the business goals
• elevant to the objectives of this project
ts dependence on other re uire ents ust be analysed and ade visible and any potential con icts and
duplication with other re uire ents ust be resolved.
he Agile BA will analyse each re uire ent and also facilitate the prioritisation of each re uire ent by the business.
he Agile BA ust be a negotiator, as there is a good chance that so e re uire ents will be in con ict with each
other, resulting in con ict between the stakeholders who own the . he Agile BA will ediate to reconcile these
con icts and differences, often by using facilitation skills in a Facilitated Workshop to bring together the parties in
con ict.
Agile techniques such as hands-on prototyping, role-plays, demonstrations and modelling can be helpful in
uncovering tacit and se i tacit infor ation.
e uire ents can e erge as business re uire ents, technical constraints, technical opportunities, business rules.
he Agile BA ay also find that they are stated as solutions in the first instance. hese need further analysis to
discover what benefit they ust give. f re uire ents are too solution oriented, they ay place unnecessary
constraints on the volving olution, re oving so e of the e ibility needed by the olution evelop ent ea
when they co e to evolve that piece of the solution.
e uire ents can be functional, describing the features needed or what the solution ust achieve. thers
can be non-functional and address the end product’s required behaviours such as performance, usability, access
security, archiving, backup, security, availability, aintainability, robustness. he co pleteness of the re uire ents
from a functional and non-functional perspective, and the evolution from business requirement to technical
i ple entations of those re uire ents is part of the analysis the Agile BA ust perfor .
11.3.3 Validation
Validation applies to both the individual requirement and to the whole set of requirements for the increment and
for the project. ince re uire ents do not e erge in detail until just before they are built, a high level view of the
re uire ents and their dependencies needs to be e pressed and co unicated. odelling can assist the process
of defining the incre ents into which the project is divided, and can show dependencies, in order to ini ise
une pected overlaps and reduce risk.
e uire ents ust also be testable. ven at the very early stage of identifying re uire ents, the Agile BA will
ensure easurable acceptance criteria for each re uire ent are agreed with stakeholders. his way, they will
confir what is needed for the re uire ent to be successfully i ple ented.
152
11.3.4 Management and documentation
11.3.4.1 Requirements documentation
Agile has a reputation for being light on docu entation, but why do re uire ents need to be docu ented
Documentation is typically for at least one of four purposes:
• o pass a essage fro one person set of people to another
• To record information now, whilst we know it, for later when we may have forgotten it
• o help us to anage co ple ity
• To prove we have done something
n an Agile situation, the first three are still true. he fourth should not be uite as necessary in an Agile culture
of trust, as it would be in a culture where the fear of failure predo inates. owever, this ay still have relevance
for audit and co pliance purposes, in highly regulated industries, for e a ple. he actual needs of such an
audit purpose should be investigated as many situations do not need the volume of documentation which was
custo arily provided in traditional waterfall projects.
For the first point above, the docu entation needed will be reduced if the tea including business roles can be
co located. For the second point, docu entation is reduced in an Agile situation as the detail is only elaborated just
before it is needed, so the ti efra e to re e ber detail is short. For the third point, co ple ity is reduced by the
incre ental approach to solution evolution and the feature focused ti ebo es. hese ai to deliver a co plete,
cohesive, s all and potentially i ple entable seg ent of the solution in a short ti efra e.
hus docu entation in an Agile project should be sufficient for purpose, and only that. he two golden rules of
Agile documentation are:
• o not docu ent unless it is useful to so eone specific a 5 page docu ent that no one actually reads is not
proving useful to anyone
• ocu ent in a way that is useful to the recipient ask how this will be used, by who and for how long
he appropriate level of docu entation depends on any things. For e a ple
• the ease of communication between team members and other stakeholders - co-located Agile teams probably
need less detail when writing down ser tories than distributed tea s, for e a ple
• skills of the tea e bers and co ple ity of the product it ay be easier and ore consistent to write
down or diagra detailed steps for a process, in addition to face to face e planation
• documentation may be needed to support end-users of the product or those running a Service Desk, for
e a ple
• where there are regulatory co pliance audit obligations to eet, docu entation needs to be sufficient to satisfy
that need
ocu entation ay be used by both business and technical tea e bers. he language needs to be clear and
accessible to all disciplines involved.
he docu entation of re uire ents in an Agile project is an incre ental, evolving activity.
he infor ation held within the should be sufficient to identify, group and anage the re uire ent and its
e erging detail. t will also help with configuration anage ent.
11.3.4.2 Requirements management
nce a re uire ent has been identified, its inclusion within the final product or its descoping should be traceable,
along with the rationale for this, both hori ontally fro beginning to end of the project and vertically fro
the overall business goal it is addressing to the realisation of this . his enables the stakeholders of the project to
understand what is, and is not, contained within the final solution. t helps to prevent re uire ents being issed
by accident or new re uire ents being brought into the project without consideration of their i pact on others
or on i ebo and project ti escales. his is not to prevent change Agile projects e brace change, even late in
the process. owever, this change needs to be introduced in a considered way, with an appropriate level of change
153
AgileBA Handbook
control not too heavy, but not non e istent. he Agile BA will be the guardian of the project re uire ents and
the related fro this perspective, although decisions on whether or not to accept change will ulti ately lie
with the Business isionary.
tools to support the anage ent of re uire ents, fro first capture through to integration and delivery
of the evolving solution, ay be necessary and useful. owever, tools alone are hardly ever the solution to
re uire ents proble s. isibility of the re uire ents as they progress through the lifecycle is the Agile approach
to co unication and disse ination of infor ation, through nfor ation adiators such as wallboards and
permanently-visible large screens, and through collaborative practices such as Daily Stand-up meetings and
Facilitated Workshops.
11.4 Requirements within the Agile Project Lifecycle
ery i evel
Requirements
re ro e t
( e tives and emes)
i evel rioritised
easi ility Requirements
(Epi s and User Stories)
oundations
Evolutionary
Development
ssem le
Revie
Deploy
Deployment
Detailed Requirements ost ro e t

(Detailed User Stories)
Figure 11b: The DSDM process showing requirements evolving
he pattern of eliciting, analysing, validating and anaging docu enting re uire ents is e bedded at every phase
of the lifecycle. owever, the level of detail is different, progressing fro the project objective and the very
high level re uire ents defined at Feasibility, through to the ost detailed level, which e erges i ebo by
i ebo during volutionary evelop ent.
Below, the involve ent of the re uire ents lifecycle within each project lifecycle phase is considered, together with
the use of practices.
11.4.1 Pre-Project
re roject activity supplies the er s of eference for the project. he will identify the proble to be
solved or opportunity to be addressed. his is effectively the first, very high level re uire ent.
11.4.1.1 Elicitation
A strategic Business Analyst a different person fro the allocated project BA ay have been involved in the
production of this, and the project s Agile BA will need to understand its conte t.
154
11.4.1.2 Analysis
he re roject analysis, or results of a progra e of which the project is a part, ay produce a high level scoping
diagra to set the objective in conte t.
11.4.1.3 Validation
he Business ponsor, Business isionary and Business Analyst, and later the roject anager, need the to be a
clear enough definition for the project to be correctly focussed during Feasibility.
11.4.1.4 Management and documentation
he should be docu ented one or two pages at a a i u with high level objective, benefits, costs, risks
and any initial assu ptions. has a product definition for the , along with other docu ents entioned
later.
11.4.2 Feasibility
he purpose of Feasibility is to provide a high level overview of the project, enough to assess whether the
project is worth doing, fro both technical and business points of view. uring Feasibility, a very high level set of
re uire ents will be elicited probably no ore than ten or so of these too any would indicate too low a level
of detail for the purpose of Feasibility . hese re uire ents are at the level of ajor the es or very high level
features. hey need to be just enough to
• Act as the headline guidance for the project scope. ach the e or feature will typically e pand during
Foundations into lower level detail
• ive enough detail for a broad esti ate of project si e, with the acknowledge ent that the accuracy of any
estimate is within a broad range
• Allow a first consideration of priorities, although at this level they ay all be ust aves
At Feasibility, the Agile BA is trying to establish a shared vision for the project with the Business isionary and
Business ponsor and between other stakeholders. he es and features are typically elicited by face to face
conversations and Facilitated Workshops. A Feasibility prototype ay be used to clarify what is envisioned.
he for ulation of a si ple, one sentence project objective, which sits above the the es and features will for a
useful focus for the whole project.
11.4.2.2 Analysis
he es and high level features are analysed to establish dependencies and con icts. he Agile BA would
use odelling to ake the structure of the functions visible. Facilitated Workshops would be used to enable
negotiation of the high level features and their priorities o oW prioritisation . Acceptance criteria very high
level, but easurable would be established for each he e or Feature. he Feasibility Assess ent will contain
these the es Features as the e bryonic .
11.4.2.3 Validation
he project tea during Feasibility is the Business ponsor, Business isionary, echnical oordinator, roject
anager and Business Analyst. alidation and acceptance of the very high level the es and features ay also need
approval of a wider set of stakeholders. hese ay be a steering co ittee, or an invest ent appraisal body
within the organisation, for e a ple. Whilst negotiation and agree ent of the ajor the es and their priorities
ay happen during a Facilitated Workshop, a ore for al uality eview eeting described later ay be
chosen, to baseline and effectively sign off the Feasibility Assess ent.
he the es features should be recorded appropriately and visibly for all stakeholders. his is the e bryonic
also often called a roduct Backlog in other Agile approaches . uring Feasibility, it needs to be at a level which
is just sufficient for purpose. t will for the top level of the hierarchy of re uire ents which will e erge later.
odelling and diagra ing will aid the visibility and clarity of this hierarchy and set out the conte t and scope.
155
AgileBA Handbook
11.4.3 Foundations
he tea during Foundations includes olution evelop ent ea roles, which are needed to esti ate work
re uired and produce the elivery lan. uring Foundations, it is i portant that the whole tea is aware that
there is ore work needed on re uire ents than one pass of re uire ents captured in a Facilitated Workshop
he the es fro Feasibility each need be e panded to a further level of detail, to for high level re uire ents
pic stories .
uring Foundations, business analysis work will be needed, to provide a clear structure a fir foundation on
which to work during volutionary evelop ent, when pics are split into lower level ser tories. Foundations
also provides the testing strategy as a part of the evelop ent Approach efinition against which validation will
be perfor ed.
he Agile BA will organise Facilitated Workshops to e pand the the es and features into high level re uire ents.
hese Workshops are often supported by odelling and prototyping, which the Agile BA will do. he participants
will be selected as appropriate for each Workshop, but will draw from the Business Sponsor, Business Visionary,
echnical o ordinator, roject anager, the olution evelop ent ea , Business Advisors and a wider group of
stakeholders.
11.4.3.2 Analysis
After eliciting re uire ents, the Agile BA will work face to face with appropriate stakeholders to define each
re uire ent further and analyse whether it is realistic, feasible, a biguous or con icting with, or duplicating other
re uire ents. hey would also gather ore infor ation about the business goal served and the value of the
re uire ent. he roles of Business A bassador s and Business isionary have the e power ent to speak on
behalf of the different business areas. uring Foundations, pic ser tories are established. Facilitated Workshops
can be used to clarify and share re uire ents infor ation and to resolve con icts and overlaps. Acceptance
criteria will be established at a high level against each re uire ent. rioritisation is also done at this point, using
Facilitated Workshops and o oW prioritisation.
11.4.3.3 Validation
nce a has been established, this needs to be validated by the project level and olution evelop ent ea
roles, and possibly a wider group of key stakeholders. t is reco ended that the is for ally agreed and
baselined at the end of Foundations, by uality eview. his then acts as a clear state ent of the scope, upon
which esti ates during Foundations are ade. Whilst the Agile approach is to e brace change, it is very powerful
focus for the project to agree the in this for al way. When change co es along during the project, which
changes the breadth of the project, it is easier to assess its i pact.
he pic tories on the act as the headlines fro which ore detailed re uire ents are elaborated during
i ebo es. ven if the project is e ploratory, the will set para eters related to the breadth of scope and the
benefits the project was funded to achieve.
A olution prototype ay also be produced during Foundations and is a powerful way to elicit and validate
re uire ents.
he ain re uire ents product of the Agile BA during Foundations is the . his beco es a central docu ent
for the re ainder of the project. he re uire ents on the should describe what needs to be achieved,
rather than e actly how it will be done, to allow e ibility during volutionary evelop ent to focus on the
business need and its achieve ent.
he should be at a sufficient level of detail to allow the olution evelop ent ea to esti ate for the
elivery lan, showing a schedule of e pected i ebo es for at least the first incre ent of delivery.
Business analysis is a defined part of the olution evelop ent ea work within each stage of iterative
develop ent within the i ebo es.
156
he Agile BA facilitates the e pansion of the pic tories of Foundations into lower level ser tories, which guide
develop ent and testing. Facilitated by the Agile BA, each ser tory will be elaborated via de onstrations,
prototypes, odels and face to face co unication within the olution evelop ent ea .
uring i ebo es, the detailed re uire ents ser tories need to be discovered. his will ostly be through
face to face discussions and prototyping. olution evelopers, olution esters and Business A bassadors
work together to concurrently e pand the re uire ents detail and build the product. he Agile BA will capture
the e erging detail, e panding the , i ebo by i ebo , with appropriate lower level detail and detailed
acceptance criteria.
11.4.4.2 Analysis
As requirements detail emerges, these lower-level requirements will need to be prioritised by the Business
A bassador s and Business isionary and agreed within the olution evelop ent ea . he business value of
the detailed requirements also needs to be assessed, priorities agreed and estimates made of the effort required to
co plete the .
The Agile BA will facilitate this conversation within the team and keep the link to the higher-level requirements,
processes and data within the solution do ain. he BA will odel the structure of the re uire ents story
apping and keep this visible to the tea , so that the i pacts of day to day decisions can be seen.
11.4.4.3 Validation
The Agile BA will work to keep the focus on the Business Case and higher-level themes and features, as lower-level
re uire ents and acceptance criteria are defined.
uring volutionary evelop ent, the focus is on the validation of the finished, working solution. Fre uent
de onstrations of ele ents of the solution to the project tea and a wider stakeholder group will be a key part of
this, facilitated by the Agile BA.
he acceptance criteria will drive tests. ecisions will be needed on
• he definition of one the criteria for the product to be considered acceptable and ready for deploy ent
• Test coverage - what is being tested at each demonstration or testing session: functional, usability and non-
functional aspects
uring volutionary evelop ent, detailed re uire ents ser tories are docu ented in the . Any
odifications or further sub divisions of the re uire ent should always be traceable back to the higher level
re uire ents.
t is also i portant during volutionary evelop ent to record those hould ave and ould ave re uire ents
or features that have been traded out or dropped and hence have beco e Won t ave this time e uire ents..
he can be a useful tool for recording errors and bugs discovered when testing the solution so that they can
be prioritised and considered in the conte t of the overall re uire ents.
11.4.5 Deployment and Post-Project
By eploy ent, the elicitation and analysis of re uire ents is co plete. Any specific re uire ents related to
the deploy ent of the solution should have been captured during volutionary evelop ent and fed into the
eploy ent lanning. he validation activity here is to ensure that re uire ents docu entation is sufficient for
both support of the solution in live usage, and for the ost roject Benefits Assess ent to be done. n the first
part of Deployment, the Agile BA will link those requirements for which the solution has now been built and tested
and is about to be delivered back to the Business ase. hey will ake visible the benefits which should now be
able to accrue to the Business isionary, and to those who will receive and use the solution.
ost roject, the docu entation of re uire ents fro the project, plus the Business ase will be used to assess
the level of i ple entation of the re uire ents. ost roject Benefits Assess ent is likely to be achieved using a
Facilitated Workshop, which the Agile BA ay facilitate.
157
AgileBA Handbook
11.5 Agile Practices

o oW prioritisation, Facilitated Workhops, odelling and rototyping, terative evelop ent and i ebo ing
have been considered above, alongside the project lifecycle. ne additional techni ue, useful as a collaborative way
of agreeing and validating a set of re uire ents, is the uality eview eeting.
11.5.1 Quality Review meetings
uality eview eetings are a for al eeting to study a product here a set of re uire ents and identify errors
or defects, which will be corrected outside of the eeting.
In brief, the process is as follows:
• Plan the review - the review team is selected, and the time and venue agreed
• Preparation for review the chairperson for the eview will distribute copies of the docu ent to all parties,
who should return a ueries list before the eeting
• The meeting - the meeting allows the AgileBA to talk through the requirements item by item and for reviewers
to respond. t should be noted that the eeting is not the place to identify the solutions or fi es to proble s.
At the end, the chairperson will agree with all reviewers what follow-up action is to be taken for any errors
found, by whom and by when
• Follow-up - follow-up action may be needed because the requirements were not acceptable and a further
review ay so eti es be needed. At the end of the review process, by agree ent, the docu ent can
be signed off and baselined, to provide a fir foundation for further evolution of the re uire ents during
i ebo es
11.6 Summary
Agile e uire ents ngineering allows re uire ents to follow a controlled, incre ental process of deco position
and elaboration, fro a high level objective, the es and features, through to high level prioritised re uire ents,
to fully evolved re uire ents present in prototypes and the final solution. ach re uire ent has a lifecycle of
licitation, Analysis, alidation, anage ent and ocu entation. Following this helps the Agile BA to ensure the
focus on re uire ents is appropriate at the different project lifecycle phases. t also helps to itigate the risk that
an inconsistent or internally con icting set of re uire ents could evolve.
he Agile BA facilitates the evolution of re uire ents fro high level objectives down to low level detail, whilst
keeping the consistency and focus, co pleteness and prioritisation of the re uire ents set as a whole. Agile
practices for a key part of this process, facilitated by the Agile BA.
158
12. Making the
Transition to
Agile BA
1
1
1 159
1
1 1
Making the Transition to Agile BA
AgileBA Handbook
12.1 Introduction
n this andbook, the role of the Agile BA has been described both in relation to Agile projects and to
organisational strategy. t has shown how an Agile approach focuses on fre uent delivery of business valuable
incre ents of a product. he andbook identifies so e of the best practice Agile techni ues and practices and
sets these within an Agile fra ework. t shows how the Agile BA supports the Business isionary, Business ponsor
and other business roles, alongside the Solution Developers and Testers and other stakeholders to ensure that
business value is delivered, the focus on the overall strategy of the organisation is not lost and that the end-to-end
value chain of e erging business processes is opti ised.
he uestion re ains, ow do get fro where a now, as a traditional Business Analyst BA , to being an
effective Agile BA
It is important to recognise that the transition will be different for each Business Analyst, each team of BAs and the
department to which they are aligned, which may be the IT function or a business function such as marketing or
finance. herefore, there can be no prescriptive series of steps. ather, the focus of this chapter is on providing
general advice to help anyone in a BA related role ove successfully to an Agile way of working.
The Role of the Business

Analyst, in an Agile World
Making the Transition to Agile BA Agile Fundamentals and the Agile BA
The Requirements Lifecycle The Agile Business Case

in an Agile Project
Requirements Planning and

Estimating Throughout the Lifecycle Stakeholders in the Agile Project
Timeboxing and Requirements and User Stories

Modelling and Prototyping Prioritisation
Facilitated Workshops
Figure 12a: Agile BA chapters
12.2 Why Are We Changing?

The reason why organisations move to an Agile way of working is usually related to the organisation’s needs to:
• eliver change faster or benefits earlier
• Be ore responsive to change in the e ternal or internal environ ent
• Stay on time and in budget with business change
• Deliver reliably what the business really needs
• nderstand the overall i plications of change for the business in a fast oving environ ent
Moving to an effective Agile way of working is rarely the decision of the BA, nor have they been traditionally
160
the driver for this initiative. deally the drive for such a change should co e fro senior anage ent, and be a
business inspired initiative. owever, in reality, the i petus ay co e fro al ost any level of the organisation,
and has often arisen in the past from solution developers, pressurised by tight timescales and the drive to deliver
everything re uested or specified.
Wherever the initial drive for Agile originated, its adoption and ultimate success is more likely if there is a senior-
level champion within the business, who has the authority to carry the change forward and can allocate budget
to fund not only the procedural change, but also the significant cultural change for all roles and all levels of the
organisation involved in business change projects.
he BA has a central and in uential role in Agile projects. here is also uch that they can do to support an Agile
transition, which is a business change, like any other, and for which the BA s skills can prove very useful.
12.3 Agile Transition for the Individual, or the Organisation

A BA has the business change and communication skills to help the transition of an organisation to an Agile way of
working. hey have the techni ues to carry out an assess ent of the gap between the current ways of working
and the goals set for an Agile approach. t should be noted that although it is essential for such goals to e ist at the
outset, they will inevitably be refined in the light of e perience an Agile concept in itself.
To identify the transition gap, whether for the individual BA role, the Agile team, or the organisation as a whole,
there are nu ber of uestions that should be asked. he answers can begin to highlight how uch preparation
and on going support will be re uired to change working practices. ey uestions are
• s there a clearly stated business driver objective for oving to an Agile way of working
• s there an owner for the initiative the Business ponsor and at what level within the organisation is their role
• What is the current culture within the organisation, with respect to the 8 principles Will all potential
stakeholders, including Business Analysts, accept the new ethods and practices
• Where are the current ways of working positioned in terms of a continuum that at one end may be formal,
procedural, traditional or waterfall-based, through one already embracing iterations and incremental delivery,
such as , to the adoption of isolated Agile practices
• What is the current level of knowledge, e perience and skill of the BAs and for that atter, of the rest of the
olution evelop ent ea , to work in an Agile way
• What is the current level of business involve ent o those involved have the willingness, e power ent and
authority to actively participate in a project throughout its lifecycle
• What is the current level of soft skills Are there skills of collaboration, co unication, facilitation, negotiation
and in uencing to support an Agile way of working
• Are there any e isting standards or practices in place that will specifically inhibit adoption of an Agile approach
What would be the i pact if these were changed or abandoned
• What automated tools are currently available to the BA and do they have the capability to support activities
such as odelling, incre ental specification, definition and refine ent of user stories, creating and aintaining a
Where the organisation is making the transition from Waterfall to Agile, there is a tendency at many levels to
want to continue to use e isting heavy sets of docu entation as a kind of co fort blanket . his will not work.
ike other aspects of the Agile way of working, the production and for at of docu entation needs to change.
ocu entation, beyond what is re uired fro a co pliance or legal perspective, will be ini al. owever, if it is
necessary to provide some familiar deliverables at the beginning of transitioning to Agile, then the Agile BA should
at least ensure that the requirements are addressed in an Agile manner, iteratively evolving these and elaborating
detail in a i ebo ed, business driven way.
he options for how to approach Agile adoption will vary widely and depend on any interrelated co ponents.
A business analyst cannot ove towards an Agile way of working in isolation. hey should do this as part of a
wider integrated initiative involving a diverse set of potential stakeholders. owever, it is useful to list so e possible
options to help fill the gap and begin adopting Agile working practices.
161
AgileBA Handbook
• dentify and select a project that re uires business analysis skills, but also covers all of the other roles in
develop ent and delivery. deally, an initial, pilot project should be less than si onths in duration with good
business visibility and clear business outcomes delivering real business value
• Disseminate, promote and adopt Agile principles across the stakeholder community
• Address the Agile yths around governance and docu ent centric controls. is a robust and scalable
Agile framework; one of the principles is “Demonstrate Control”
• reate si ple Agile etrics to onitor and support initial Agile projects and provide the basis for continued
refine ent. t should be noted that easure ent of the As s situation is the first step to easuring progress
towards a change, and the metrics chosen should be carefully selected to allow the comparison before and after
12.4 Individual Transition for the BA

n an individual level, even where the organisation is not yet e barking on a full Agile transition, the traditional
business analyst can begin to develop or enhance their Agile skills, and those of the teams they work with, by
focusing on the following areas:
• Agile re uire ents gathering, using ser tories and a ierarchy of e uire ents covered in hapter 5 .
This will also engage business stakeholders and allow them to become more familiar themselves with Agile
techniques and ways of working
• Modelling and Prototyping: the BA can begin to adopt and use one or more of the modelling and prototyping
techni ues covered in hapter 8
• Facilitated Workshops the BA can begin to use Facilitated Workshops hapter 7 to encourage collaboration.
hese allow participants to gain greater buy in to the project, hear each other s points of view and e ercise their
empowerment
ne big area of change for any business analysts is in the way that large organisations would have e pected the
to work in the past. raditionally, they ay have been e pected to be the conduit for co unication between the
business and develop ent roles, acting as an interpreter and conveyor of re uire ents. n an Agile role, they need
to switch their indset fro this see ingly powerful, controlling role to ore facilitative working. he developers
and testers in Agile are encouraged to talk directly to each other, to Business Ambassadors and Advisor, and to
work collaboratively together. he Agile BA still has value to add, and skills to bring, to this conversation. he
additional benefit of the collaborative working is in the reduction of isunderstandings and uicker co unication.
Agile working also fosters better understanding by all disciplines of each other s challenges and opportunities. his
helps to focus the volving olution on the true and current business need.
12.4.1 Agile requirements.
he characteristic of re uire ents detail e erging as the project progresses is one of the i portant ele ents for
any BA transitioning to an Agile way of working. he concept of ust n i e detail for each re uire ent, leaving
the elaboration of detail as late as possible to the last responsible o ent , just before develop ent and testing
will occur, is one of the ajor areas to focus on and successfully address.
To become familiar with these important concepts, the following points can provide a direction:
• o effectively establish the scope of a potential Agile project, re uire ents need to be considered in two
di ensions breadth first, then depth. t is essential to establish breadth the hori ontal e tent of the scope ,
as early as possible, then follow up on the detail of those high level re uire ents later. he re roject er s
of eference should state a high level objective, boundaries and the scale of costs and benefits. he project
objective for s the start of the ierarchy of e uire ents which will evolve during the Agile project. n
Feasibility, this objective can be broken down into ne t level of the hierarchy, as ajor business the es or
functions. o e of the e ibility within the re uire ents ay be discovered here, in the for of o oW
priorities
• uring Foundations, business functions can be defined and sub divided into a series of features pic stories .
his is where the depth of re uire ents begins to be e plored and prioritisation beco es ore detailed.
Further refine ent of the Business ase takes place here too. he Agile BA will begin to build up a based
162
on breaking objectives down into features. he Agile BA can facilitate the e pression of high level acceptance
criteria against each requirement, to help understanding and as a basis for future test criteria
• he lowest level re uire ents do not e erge until volutionary evelop ent, deliberately delayed as late
as practicable. uch a delay ay result in a significant a ount of effort fro the Agile BA alongside the
essential commitment of time and availability from the business users, during the iterative development within
i ebo es. owever, this is offset by the fact that, in a traditional develop ent, significant ti e and effort is
e pended up front in the project, at the point when least is known about the proble area. his detail ay
subse uently change because of error in understanding or because ti e has elapsed between specification and
i ple entation of the re uire ent, and the need has changed. he traditional approach is prone to resulting in
wasted effort in the early stages
• Within , the contains all the re uire ents that the project needs to address, but only at a high
level in the early stages. his is reviewed and enhanced throughout the project and updated whenever a new
re uire ent is identified when further detail is gathered for an e isting re uire ent is further refined or if the
re uire ent s priority changes. he Agile BA is the guardian and cha pion of the
12.4.2 Modelling and Prototyping
A central tenet of Agile working is to ake visible the volving olution, and the progress towards this. odelling
and rototyping hapter 8 are ways to achieve this which do not rely on wider agility to be useful.
he following odelling and prototyping techni ues are appropriate during the lifecycle phases.
• During Feasibility and Foundations, beginning with some high-level models to illustrate the breadth and depth
of an utline olution these can be used as an initial esti ate of the nu ber of i ebo es re uired to deliver
the eventual solution. Also, the high level re uire ents can be supported by scoping diagra s and high level
structure diagra s, which can be used to deter ine how any ele ent worked on in detail during volutionary
evelop ent fits into the whole structure. igh level re uire ents can be odelled if useful, for e a ple as
tory aps or high level se ases
rototypes can also be produced to ensure that all stakeholders share a vision of the sa e kind of solution.
Fre uently, a si ple prototype at this level so eti es only a drawing, or a set of si ple screens with no
processing logic can uncover significant differences of viewpoint between stakeholders, and lead to a clearer
shared vision for the re ainder of the project
A roof of oncept can eli inate an i practical idea early, or help to confir the feasibility of an innovative idea
• During Evolutionary Development, se ase diagra s and Business rocess Flow diagra s using swi lanes
may be useful for communicating with the Solution Developers, and as a basis for the Solution Tester to
structure tests
rototyping is the e bedded way of working within i ebo es, with fre uent reviews of these by a wider
group of stakeholders in addition to the olution evelop ent ea . hese should be not only the how and
ell de onstration style of prototype, but also usability prototypes. uch prototypes, which the end user can
e perience hands on , brings a stronger engage ent, deeper understanding and valuable feedback.
suggests the F Functional, sability, on functional perspectives for prototyping, to ensure good coverage
of prototyping
• During Deployment the Agile BA focuses on getting the solution or incre ent of the solution into operational
use. his is driven by the business objectives outlined during Feasibility and Foundations and encapsulated in the
Business ase. he Agile BA will ensure the definition of Acceptance riteria throughout the project, e erging
with ore precision as the re uire ents detail increases. hey also support the olution ester and Business
A bassador in the ser Acceptance esting A of the volving olution
The Agile BA will also ensure that an appropriate, agreed format and level of documentation is available post
deploy ent to support the delivered solution. his ay incorporate appropriate odels
163
AgileBA Handbook
12.4.3 Facilitated Workshops - The BA as Facilitator

Facilitation has always been one of the core skills of the BA. With Agile projects, the part that facilitation plays
in contributing to the success of the project is increased. t is well recognised in Agile that the ost efficient
and effective method of conveying information to, and within, the Solution Development Team is face-to-face
conversations. he skill of facilitation is essential to the Agile BA role. owever, the Agile BA ust judge which
Workshops they may appropriately facilitate and which ones they cannot, since they need to be involved as a key
participant.
During Feasibility and Foundations, Facilitated Workshops can be used to great effect, for e a ple, for
• stablishing Business ision
• efining roject bjectives and how these align to the Business trategy
• Agreeing roles and responsibilities
• Assessing isk and co pleting the roject Assess ent uestionnaire A
• apturing, refining and prioritising e uire ents
• Planning increments
• lanning for uality and esting
Facilitated Workshops can help to establish a tea , and to create a shared vision and understanding.
During Evolutionary Development, the Agile BA is a full member of the Solution Development Team, together
with Business A bassador, olution eveloper and olution ester roles. his tea works collaboratively, on a
day to day basis. Within the tea , conversations about re uire ents ay need to be facilitated to be effective
and the business analyst can help with this. lacing a greater e phasis on the skill of facilitation allows the Agile
BA to beco e an enabler and shaper of ser tories rather than just the scribe for re uire ents. hey guide the
discovery process and ensure that co unication, collaboration and consistency are aintained during the project.
During Deployment, there may be a need for facilitation of small groups of stakeholders, as training and support
of users progresses for the newly deployed product. A eview just before the solution is deployed, to ensure
readiness, is reco ended within . his ay often be facilitated by the Agile BA.
Post-Project, the responsibility for ensuring that benefits are assessed rests with the Business ponsor. he Agile
BA ay engage with stakeholders, including the Business ponsor and Business isionary, in a Benefits ealisation
eview Facilitated Workshop. he objective of this will be to deter ine the business value actually achieved, against
that described in the Business ase. Additionally, the use of etrospectives, post project and post incre ent, can
provide useful learning to be passed to other projects, or to enhance the perfor ance in the rest of the current
project.
12.5 Final Thoughts

he Agile way of working is still aturing and there are undoubtedly any gaps yet to be filled between theory
and practice. n the early days of Agile, the business analyst s role suffered fro Agile s original developer centric
origins and the desire of the developers to be in direct contact with the business end user. his desire for direct
co unication and collaboration is not a bad thing. owever, it so eti es resulted in the e clusion of the
necessary skills of business analysis.
n the early Agile approaches, the developer s role was dee ed to e tend to enco pass business analysis, syste s
analysis, design and testing. n addition, it i plicitly covered all of the soft skills re uired to support dyna ic
collaboration, and the process analysis skills necessary to deliver incremental, but coherent and valuable, business
features. his was an overly a bitious e pectation of a developer, or for that atter of any individual. rojects
struggled to deliver coherent business solutions. he lack of cross solution analysis one of the key aspects of
business analysis was considered by any to be a contributory factor for this. Whilst Agile e braces the idea of
self-organising teams and individuals with a wider base of skills, the advantages of different team members having
different skills and focusing fro different perspectives is also powerful.
164
The value of viewing a problem from multiple perspectives, which comes from developers, analysts and testers
collaborating with the real business users and customers, imparts richness to the production of the solution, which
allows a better product to e erge. he best solutions e erge fro a truly collaborative tea , where all tea
members work together collaboratively and synchronously, each bringing their unique perspective, skills and buy-in
to the proble at hand. he Agile BA role is essential in this collaboration, but only if they are able to fully e brace
the Agile values and principles, never allow themselves to become the “go-between” between business and solution
develop ent roles.
Another challenge for the Agile BA is the business analysts’ reputation for generating heavy-weight documentation
and, as a result, see ing to take control of re uire ents. For early Agile evangelists, this perception outweighed
the business analysts reputation for the analytical e pertise and co unication skills. here also appeared to
be a funda ental con ict between good Agile practice and good business analysis practice. Agile approaches
value individuals and interactions, custo er collaboration, working solutions and acco odation of change. By
reputation, business analysts seemed to value processes, documentation and getting everything agreed up front
contract negotiation . his is no longer the case, as business analysts e brace the advantages of an incre ental
approach and the opportunity to learn as they go . hey recognise the benefits of not wasting ti e doing detailed
work on re uire ents at the outset of a project, only for so e of those re uire ents to change with the passage
of ti e, or to be dropped.
n a Waterfall based project, the developer, tester and business analyst usually carry out their respective tasks
separately and se uentially, with long periods of work by one discipline before the hand off to another. any
resource anagers e press concern that Agile collaborative tea working will result in underutilisation of tea
e bers during a i ebo . n practice, this does not prove to be the case. f just enough work has been
undertaken in Foundations to provide the overall structure of the develop ent, and if the i ebo es are kept
short and feature-focussed, it is generally found that the developer, tester, business representative and Agile BA all
have si ultaneous and parallel tasks to do in the preparation of the solution. A benefit of this is that there is less
ti e spent reworking re uire ents, as the tea are working together. he collaborative pattern of working will
typically occupy all roles fully during the i ebo es. Alternatively, not all ay be needed full ti e, depending upon
the product being produced, but the appropriate work effort of each role will emerge for a given environment,
with e perience.
n an Agile world, therefore, there is still a need for business analysis skills and a specific Agile BA role, irrespective of
the develop ent and delivery approach or the technology being used to deliver the solution. rganisation, eople,
rocess and echnology e ist together in a holistic relationship. he opti isation of this relationship is the do ain
of the Agile BA.
he role of the business analyst is a changing one, re ecting the changing needs of the odern organisation. he
e tension of business analysis skills to enco pass an Agile way of working is another step along that path one that
re uires a refocusing and e tension of the hard and soft skills of business analysis, and the recognition of the greater
opportunities available to deliver sustained and early business value.
n this andbook, we have started a journey. We began with the ore traditional, strategic techni ues of the
business analyst and progressed to Agile practices which are collaborative and innovative. We saw our day to day
lives change in relation to a new fra ework of working in short ti ebo es. We saw the ow of our work change
fro one of long, isolated periods of re uire ents specification to a very different, intensely collaborative way of
working. We also discovered that we do not have to be an e pert in all of this fro the start the Agile process
itself, with its regular retrospection, gives us the opportunity to i prove as we go.
You are now on your way to becoming a more effective business analyst - an Agile BA and, together with your
tea , delivering better value to the business.
165
AgileBA Handbook
166
Appendix A
Glossary
1
167
1 1
Glossary
AgileBA Handbook
Term Abbreviation Detail
8 2 rule A rule of thu b stating that 8 of conse uences ste fro 2 of

causes. Also known as the areto rinciple it advocates prag atis on
a project. he value of the areto rinciple is that it re inds you
to focus on the 2 that atters.
Agile A style of working where requirements and solutions evolve through

collaboration between self organising, cross functional tea s. Agile
promotes adaptive planning, evolutionary development and delivery,
a ti e bo ed iterative approach and encourages rapid and e ible
response to change.
Agile Manifesto he Agile anifesto defines the approach and style that is funda ental
to all Agile approaches. t was created in 2 1, at a su it attended by
representatives of all the Agile ethodologies.
“As Is” and “To Be” odels can be produced to show the current situation As s or the
Modelling intended situation o Be
Abstraction Modelling usually incorporates a degree of abstraction. i.e.
it focusses on a particular perspective e.g. the business processes , and
deliberately o it other aspects of detail fro the odel e.g. the data
structures , to allow clearer focus upon the particular aspect s chosen.
usiness Process Mo e an otation ( PM ) The Business Process
odel and otation B supports business process anage ent
for technical and business users and bridges the communication gap
between business process design and i ple entation. t was developed
by Business rocess anage ent nitiative B and is aintained by
the bject anage ent roup .
Balanced Business The Balanced Business Scorecard provides a framework for measuring
Scorecard the success of the change. his approach can be used to identify ritical
uccess Factors and to set appropriate ey erfor ance ndicators
and targets . ts strength is that it considers not only the financial
aspects of an organisation s success, but other factors too.
Behaviour-Driven BDD his is an approach to e pressing the detailed acceptance or test

Development criteria for a ser tory. ach scenario has the following structure
iven the initial condition or conditions assu ed to be true at the
beginning of the scenario; When: the event which triggers the start of
the scenario; hen the e pected outco e, in one or ore clauses
Benefits Assess ent A roduct. t describes how the benefits have actually accrued,
following a period of use in live operation.
Business Case A roduct. Baselined at the end of the Foundations phase,

it provides a vision and a justification for the project fro a business
perspective.
168
A style of esti ating. sing this approach, each co ponent is esti ated
individually and then the esti ates are su ed to find the total effort.
Burn-Down Chart A publicly displayed chart or graph counting the nu ber of features
re uire ents re aining work re aining or ti e needed to co plete
the outstanding work ti e re aining for the current ncre ent or
i ebo . When the Burn own is showing i e e aining, tea
members always re-estimate time to complete, rather than simply
subtracting ti e spent fro the original esti ate. i e re aining is
ore co only used at i ebo evel. Work re aining is ore
co only used at ncre ent level. Burn down is useful for predicting
when all of the work will be completed, based on the current rate of
progress elocity . t also highlights whether the current plan looks
achievable or whether it ay be necessary to de scope features. his
infor ation can also be presented as a Burn p hart, showing work
ti e co pleted
Burn p hart A publicly displayed chart showing features re uire ents that have
been co pleted and the value earned so far.
Big Visible Chart BVC See Team Board
Cycle defines terative evelop ent as an infor al cycle of hought,

Action, onversation
Delivery Plan A roduct. t provides a high level schedule of ncre ents for
the project and, at least for the first i inent ncre ent, the ti ebo es
that ake up that ncre ent.
Development DAD A roduct. Baselined at the end of the Foundations phase, it

Approach provides a definition of the tools, techni ues, custo s, practices and
efinition standards that will be applied to the evolutionary development of the
solution.
Deployed Solution his is a baseline of the volving olution, which is deployed into live
use at the end of each roject ncre ent.
Deployment he lifecycle phase which focuses on getting the solution or

part of it into operational use.
Development A fi ed period of ti e, part of volutionary develop ent, where

i ebo develop ent and testing of the volving olution takes place. ypically
2 4 weeks long. ee i ebo
Done A co on ter used in cru an ite is one co pleted when

it eets all the criteria that have been defined for it efinition of
one . one is binary an ite is either one or ot one.
169
Glossary
AgileBA Handbook
A ser tories that is large and not well defined. An pic is si ply a
story that it is too large to fit into one i ebo for develop ent.
volutionary The DSDM lifecycle phase used iteratively and incrementally to

Development investigate the detailed requirements and evolve them into a viable
solution
volving olution A roduct. t is ade up of all appropriate co ponents of the

final solution together with any inter ediate deliverables necessary to
e plore the detail of re uire ents and the solution under construction.
At any given time, such components may be either complete, a
baseline of a partial solution, or a work in progress. hey include, where
valuable:- models, prototypes, supporting materials and testing and
review artefacts.
Feasibility he lifecycle phase which gives the first opportunity for

deciding whether or not the project is viable fro a technical and or
business perspective.
Feasibility A roduct. t provides a snapshot of the evolving Business,

Assessment olution and anage ent products as they e ist at the end of the
Feasibility phase. t ay be e pressed as a baselined collection of the
products or as an e ecutive su ary covering the key aspects of each
of the .
Fit for urpose o ething that is good enough to do the job it was intended to do
Foundations he phase to establish fir and enduring foundations fro the

three perspectives on a project of business, solution and anage ent.
Foundation A roduct. t provides a snapshot of the evolving Business,

Summary olution and anage ent products as they e ist at the end of the
Foundations phase. t ay be e pressed as a baselined collection of
the products or as an e ecutive su ary covering the key aspects of
each of the .
Function Feature ee e uire ent
Impact Map i ilar to a tory ap as a visual presentation, but with a value i pact
focus.
Increment An ele ent of the volving olution, co prising a collection of one or

ore features which, as a group, have eaning value for the Business.
ne or ore ncre ents ay for a elease.
170
ncre ent i ebo i ebo ing can be applied at incre ent level and an ncre ent
i ebo co prises the ti e fi ed by the su of the evelop ent
i ebo es for this ncre ent. ee i ebo
Information See Team Board

adiator
Instrumental F A key behaviour or style of working that is seen as instrumental to

uccess Factor position projects for success . Where these factors cannot be
et, they represent a significant risk to the approach.
odel his is a checklist for the production of a good ser tory. ser
tories should be ndependent egotiable aluable sti able or
sti atable all appropriately si ed estable.
Iteration 1. A general ter for working in a cyclic way, where several atte pts
are ade in order to get a ore accurate or beneficial result.
2. ne cycle of develop ent and testing which takes place one or
ore ti es inside a evelop ent i ebo and which finishes with
a eview.
3. teration e uates to a i ebo
anBan Board See Team Board
ano A prioritisation approach for re uire ents, the ano odel takes
account of three distinct types of custo er need pected Will
or al Want citers Wow and two di ensions of value
eality, erception
nowledge types This describes 3 types of knowledge

Explicit knowledge: knowledge that can be e plained easily in words,
for e a ple custo er nu ber for at, loan bands, categories of
product
Tacit knowledge is not available to conscious introspection or
verbalising. t can be subdivided into plicit learning co piled skills
Semi-Tacit knowledge can be subdivided into 3 categories: knowledge
that is hard to recall without cues short ter e ory taken for
granted knowledge and concealed knowledge front and back stories
Lean Lean thinking is based on theory and practice developed for

anufacturing. t e phasises the re oval of waste often called
uda fro a process or value chain, to deliver value for the
custo er.
171
Glossary
AgileBA Handbook
Learning Styles he key sensory channel s preference affecting the way people
register infor ation and knowledge. he ajor senses used are isual
seeing diagra atic, pictorial presentations help here Auditory
hearing, speaking e planations and te tual presentation assist
this and inaesthetic feeling, doing, touching, s elling hands on
e perience of using a part of the solution accesses the e otions and
engaged this area
MoSCoW A DSDM prioritisation technique, mainly used on requirements

although also useful in other areas such as esting . stands for ust
ave, stands for hould ave, stands for ould ave and W stands
for Won t ave his i e.
c insey 7s odel his odel proposes that organisations are subject to seven inter
related aspects. All seven need to be considered together. f one
changes it will affect all the others.
Management MAD A roduct. Baselined at the end of the Foundations phase, it

Approach re ects the approach to the anage ent of the project as a whole
efinition and considers, fro a anage ent perspective how the project will be
organised and planned, how stakeholders will be engaged in the project
and how progress will be de onstrated and, if necessary, reported.
ini u sable . . . The minimum set of requirements needed to deliver a usable solution
SubseT the Worst ase basic deliverable. he ini u sable ubse is
defined as the ust aves. rovided the o oW rules are
properly applied, delivery of the ini u sable ubse is guaranteed.
Model A description or analogy used to help visualise something that cannot

be directly observed A s all but e act copy of so ething A pattern or
figure of so ething to be ade
Modelling This refers to the diagrams, sketches, illustrations, built artefacts and
prototypes, which make visible a situation we want to communicate to
others. overs si perspectives what, how, where, who, when, why. A
prototype is a kind of model, built to illustrate the typical qualities of the
eventual solution. t ay be an evolutionary prototype or a disposable
prototype. ee Appendi for types of odelling
Analysis his techni ue analysis the internal status of the organisation business
from the perspectives of Mission, Objectives, Strategy, Tactics
his techni ue analyses the e ternal factors affecting the organisation

business from Political, Economic, Socio-cultural, Technological, Legal,
and Environ ental perspectives.
172
Planning Poker is a consensus-based technique for estimating using sets

of nu bered cards. t is typically used to esti ate effort or relative si e
of stories.
orter s Five Forces This technique analyses the competitive forces within the organisation’s
Analysis arketplace. t identifies five key co petitive factors uppliers, Buyers
consu ers , o petitors, ew ntrants, ubstitute roducts.
ost roject he phase which takes place after the last planned eploy ent.
t is used to assess the business value delivered by the project.
ower nterest rid his techni ue aps stakeholder interest and power or in uence
in a 2 2 grid. By identifying the levels of power and interest, we ay
uncover potential difficulties, or potential opportunities which ay e ist,
and re ain unrealised without involve ent of those stakeholders.
re roject The DSDM phase where the initial idea or imperative is formalised in
order to initiate a project.
Principle A natural law which acts as an attitude to take and a indset to adopt
on a project.
Prioritised A roduct. Baselined at the end of the Foundations phase

e uire ents ist it describes the re uire ents that the project needs to address and
indicates their priority with respect to eeting the objectives of the
project and the needs of the business.
roject Approach A he uestionnaire, based on the nstru ental uccess Factors

uestionnaire which helps ag potential risks to a successful project.
roject overnance A panel of corporate decision akers who decide whether projects
Authority should proceed or not.
roject eview A roduct. pdated at the end of each ncre ent it aptures
eport the feedback to confir what has been delivered and what has
not; captures learning points from the retrospective focusing on the
process, practices employed and contributing roles and responsibilities;
where appropriate it describes the business benefits that should now
accrue through the proper operation of the solution delivered by the
project up to this point. After the final roject ncre ent a roject
etrospective, in part infor ed by these ncre ent reviews, is prepared
as part of the closure of the project.
roject i ebo i ebo ing can be applied at roject level and a roject i ebo
co prises the ti e fi ed by the su of the ncre ent i ebo es for
the roject. ee i ebo
173
Glossary
AgileBA Handbook
Prototype A piece of work that de onstrates how a given objective can be or

has been achieved or to prove a concept.
A and A A responsibility Assign ent atri , describing participation by roles

for co pleting the roducts. esponsible, A Accountable,
upporting , onsulted, nfor ed
elease A collection of Features developed and tested ele ents of the

volving olution being deployed into operational use. A elease ay
comprise one or more Increments
e uire ent o ething the final solution needs to be able to do Functional

e uire ent or do to a certain level on functional re uire ent .
i ilar words function, feature, ser tory.
enera usiness e uire ents ( s) are the rules that all projects
ust adhere to e.g. business policies, legal constraints, regulatory
guidelines.
echnica Po ic e uire ents ( P s) are the technical and
infrastructure policies and standards that any solution proposed must
adhere to e.g. hardware and software platfor , network conventions,
service strategy and design.
echnica Po ic e uire ents ( s) are the technical and
infrastructure policies and standards that any solution proposed must
adhere to e.g. hardware and software platfor , network conventions,
service strategy and design.
unctiona e uire ents ( s) e press function or feature and define
what is required
on unctiona e uire ent ( s) define how well, or to what level,
perfor ance needs to be provided. hey describe solution attributes
such as security, reliability, aintainability, availability and any other ...
ilities , plus perfor ance and response ti e.
esource Audit This is a means of identifying and assessing the current capabilities of
the organisation business across a nu ber of inter related areas.
etrospective A facilitated workshop to look back on a recent event and to assess

what went well and what could be i proved.
eturn on he concept of an invest ent of so e resource which yields a benefit

nvest ent. to the investor
Solution SAD A roduct. Baselined at the end of the Foundations phase, it

Architecture provides the design fra ework for the solution.
efinition
174
Scope A description of what the solution will do and what it will not do. his
could be a list of features and or a description of areas of the business
which ay or ay not be affected.
ne of the Agile approaches, with a strong focus on the ea

anage ent process. cru s focus is on a e ible, holistic product.
development strategy
Servant-Leader ervant eader is the style of leadership that Agile projects aspire to, in
particular fro the roject anager and ea eader roles. A servant
leader shares power, puts the needs of others first and helps people
develop and perform as highly as possible
Stakeholder A person, group, organisation, member or system who either affects or

is affected by actions taken by the roject or the ea
Story ee ser tory
Story Map A visible odel of the whole re uire ents set, e pressed as ser
tories, usually for one incre ent of develop ent at a ti e. t is
achieved by displaying individual story cards in groups in a way which is
visible to the whole tea .
Story Points A relative unit of si e, used for esti ating, planning and tracking in an
Agile project.
W Analysis his is a si ple but powerful eans of pulling together key findings
trengths fro the ternal and nternal analyses of an organisation. t is a
Weaknesses, su ary of the organisation s current strategic position.
pportunities
hreats
Test Driven TDD An approach whereby a test is written before the solution is built, thus
Development ensuring the re uire ent is understood and testable. ai s to
encourage si ple designs and inspire confidence. t is ost co only
applied in an IT environment but is now gaining interest as a technique
outside .
Team Board A large graphical representation of roject i ebo infor ation

kept plainly in sight within an Agile tea s shared workspace. t shows
anyone who views it information they care about, and thus avoids
the need to keep asking the tea for infor ation. his ensures ore
co unication with fewer interruptions. ea Boards can contain
ost types of charts used in Agile develop ent. Burn down charts, task
boards, planning boards and storyboards are a ong the possibilities.
An information radiator is usually hand-drawn or printed but can also
include co puter generated charts and electronic displays. o eti es
called nfor ation adiator, Big isible hart or anBan Board
175
Glossary
AgileBA Handbook
er s of eference o A product created re project. t is a high level definition of the

over arching business driver for, and top level objectives of, the project.
i ebo A fi ed period of ti e, at the end of which an objective has been et.

he objective would typically be a deliverable of so e sort. ypically
i ebo es operate at develop ent level, but ti ebo ing can also be
applied at project and incre ent level. A ti ebo is anaged by adding
or re oving content in order to eet the ti ebo objective and the
deadline. ee also print cru and teration
i ebo lan A roduct. t is created for each evelop ent i ebo . t

elaborates on the objectives provided for that i ebo and details
the e pected deliverables, along with the activities to produce those
deliverables and the resources to do the work. he i ebo lan is
created by the Solution Development Team and is often represented
on a ea Board as work to do, in progress, and done.
i ebo eview A roduct. t is created for each evelop ent i ebo ,

ecord capturing the feedback from each review that takes place during that
i ebo . t describes what has been achieved up to that point together
with any feedback that ay in uence plans oving forwards. Where
appropriate, e.g. in a regulated environ ent, it ay provide a for al
auditable record of review co ents fro e pert Business Advisors
and other roles.
Top-Down A style of esti ating using appro i ate si ings and groupings. For
e a ple, esti ating 1 s all co ponents at typically one day each,
2 ediu co ponents at typically three days each, three co ple
co ponents at typically five days each. hese groups are su ed to
give an appro i ate esti ate for a solution where the low level detail
is probably still unknown.
Total Cost of he cost of the whole life of a project and its product, including
wnership support rather than just considering the develop ent cost .
W Analysis his is used in conjunction with a W analysis, to identify the

actions options to pursue to help turn the state ents ade in a
W analysis into action.
Transparency his describes openness, co unication, and visibility. ransparency

means operating in such a way that it is easy for others to see what
actions are being perfor ed and what progress is being ade.
176
nified odelling he nified odelling anguage is used to specify, visualise,

anguage construct and document particularly the artefacts of a software-
intensive develop ent project. owever, it is also possible to use it at
a high level to odel business processes using se ase diagra s , to
enable business process improvement
ser tory A re uire ent e pressed fro a user point of view and with
associated acceptance criteria. he usual for at is As a role want
re uire ent Feature so that benefit to be gained
Value Chain and A value chain breaks an organisation down into its strategically valuable
Value Stream activities in order to understand the costs and sources of product and
Analysis service differentiation. A value strea is an end to end collection of
activities that creates value for a custo er. hese concepts are found in
lean anufacturing.
Velocity Velocity is a simple measure of the rate at which a team delivers

business value. elocity initially esti ated but soon validated by the
tea s track record of delivery is used for forward planning. .g. n an
ncre ent of 4 2 week i ebo es, a tea with a velocity of 25 points
can confidently plan to deliver about 1 points. B A velocity score is
individual to a tea their velocity signature and should not be used as
a comparative measure across teams
Workshops Workshops are a specialised type of eeting. n a Facilitated Workshop

a neutral facilitator is responsible for the structure and conte t of the
event but is not involved in contributing content.
eXtreme
X ne of the Agile approaches with a strong focus on technical
Programming develop ent techni ues. is intended to i prove software uality
and responsiveness to changing custo er re uire ents.
177
Glossary
AgileBA Handbook
178
Appendix B
Modelling Techniques and
where they are useful in the
DSDM Lifecycle
1
179
1 1
Modelling Techniques and where they are useful in the DSDM Lifecycle
AgileBA Handbook
Technique Style Main focus Perspectives Level of Detail Lifecycle Phase when created / used
Post Project
Evolutionary Development
Deployment
Foundations
Pre Project
Big Picture
Feasibility
WHERE
WHEN
WHAT
WHO
HOW
Detail
Business ne page Stakeholders WHY
Y Y Y Y Y - Y Y
anvas Picture plus Goals
Lean Canvas te t
2 Business Diagram Data Y Y Y Y Y Y
Domain Business
odel lass ules
iagra
3 Business Diagram Process, Y Y Y Y Y Y Y Y Y

Process Locations,
Diagrams Actors
using wi
anes
4 onte t Diagram Scope of Y Y Y Y Y - Y

coping study or
Diagram change
5 Customer Picture, vents Y Y Y Y Y Y Y Y Y Y Y Y

Journey diagram
Mapping
6 Impact Diagram Benefit, oal Y Y Y Y Y Y

Mapping
7 Personas e t plus People Y Y Y Y Y Y

picture
8 Product Prototype Whole Y Y Y Y Y Y Y - Y Y

ision Bo product
9 ich icture Picture Any Y Y Y Y Y Y Y - Y Y
10 pecification Prototype ser Y Y - Y Y

by a ple Interface,
11 Storyboards Picture ser Y Y Y Y Y Y Y Y
Wirefra es Interface,
vents
12 se ases Diagram Actors, Y Y Y Y Y Y Y Y Y

plus written Process
specification
13 ser tory Picture Planning, Y Y Y Y - Y Y

Mapping
14 Value Chain Diagram Process Y Y Y Y Y Y Y Y Y Y Y

Mapping improvement
180
Appendix C
Project Approach
Questionnaire (PAQ)
1
181
1 1
Project Approach Questionnaire (PAQ)
AgileBA Handbook
DSDM Project Approach Questionnaire (PAQ) Collective opinion
Ref Statement Strongly Strongly

Agree Neutral Disagree Disagree
Agree
1 All e bers of the project understand and accept the approach
hilosophy, rinciples and ractices
2 The Business Sponsor and the Business Visionary demonstrate clear and
proactive ownership of the project
3 he Business ision driving the project is clearly stated and understood by
all e bers of the project tea
4 All project participants understand and accept that on ti e delivery of an
acceptable solution is the pri ary easure of success for the project
5 he re uire ents can be prioritised and there is confidence that cost and
ti e co it ents can be et by e ing the scope of what is delivered
6 All e bers of the project tea accept that re uire ents should only be
defined at a high level in the early phases of the project and that detail will
be emerge as development progresses
7 All e bers of the project tea accept that change in re uire ents is
inevitable and that it is only by embracing change that the right solution will
be delivered
8 he Business ponsor and Business isionary understand that active
business involvement is essential and have the willingness and authority to
co it appropriate business resources to the project
9 It is possible for the business and solution development members of the
olution evelop ent ea to work collaboratively throughout the project
1 power ent of all e bers of the olution evelop ent ea is
appropriate and sufficient to support the day to day decision aking
needed to rapidly evolve the solution in short, focussed i ebo es
11 The DSDM roles and responsibilities are appropriately allocated and all role
holders understand and accept the responsibilities associated with their role
12 The Solution Development Team has the appropriate collective knowledge
and skills soft skills and technical skills to collaboratively evolve an opti al
business solution
13 olution evelop ent ea e bers are allocated to the project at
an appropriate and consistent level sufficient to fully support the
i ebo ing practice
14 ools and collaborative working practices within the olution evelop ent
ea are sufficient to allow effective terative evelop ent of the solution
15 All necessary review and testing activity is fully integrated within the
Iterative Development practice
16 roject progress is easured pri arily through the incre ental,
demonstrable delivery of business value
17 There are no mandatory standards or other constraints in place that
prevent the application of the DSDM Philosophy and Practices on this
project
182
Appendix D
Some Typical Agile
1
183
1 1
Some Typical Agile Facilitated Workshops
AgileBA Handbook
Introduction
A few of the workshops described in this andbook have been selected here for e planation, as they are
representative of the nature of workshops, particularly in an Agile project.
he Agile BA would typically be involved in all of these workshops. hey ay facilitate so e of the workshops, and
will have a role in ensuring that the end to end process of the e erging business solution is kept in view.
his Anne gives an outline of si co on workshops. he workshops highlighted below are
• roject Foundations Workshop
• Futurespective a isioning Workshop
• e uire ents apture rioritisation Workshop ser tory Workshop
• sti ating and lanning Workshops
• i ebo eview Workshop
• etrospective
For each, there is an outline, using the headings
• What is its utco e
• Who should be there
• Who should facilitate
• When does it happen
• ow should it run
Project Foundations Workshop

WHAT is its Outcome?
An Agile project needs a Foundations Workshop to establish in particular
• Appropriate resources
• ea roles and the responsibilities, and the anner of work within a self organising tea and an Agile project
• he purpose and operation of fi ed ti ebo es
• he objectives of the project and tea e power ent with respect to prioritisation and descoping of the
requirements, if necessary
WHO should be there?
• Business Sponsor
• Business Visionary
• Technical Coordinator
• roject anager
• Agile BA
• Appropriate Solution Development Team roles
• ther ey stakeholders, as appropriate
WHO should facilitate?
• The Agile BA
• he Agile roject anager
• The Team Leader
• An independent facilitator ay facilitate this Workshop, for the larger project or progra e
184
WHEN does it happen?
• Foundations. he project is not fully started until this phase
HOW will it run?
• Collaborative games and interactive activities are often used to begin to establish team relationships
• The Business Sponsor, Business Visionary and Technical Coordinator will reinforce the messages of
e power ent and utual support and disse inate the business objectives for the project
• he Agile BA will help to establish the conte t of the project within the business and technical architectures of
the business as usual services within which the project e ists
Futurespective (a Visioning Workshop)

he Futurespective is a visioning e ercise, to atte pt to anticipate the proble s and opportunities which ay arise,
to allow for better handling of these. t ay be used early in the project life cycle as a broad visioning e ercise, or
as the beginning of a i ebo , to look forward to the ele ents of the solution in scope for the ne t ti ebo , or as
an adjunct to the etrospective to help define the way forward.
he outco e of an Agile Futurespective should be the identification of
• Anticipated problems
• Anticipated opportunities
• Anticipated risks
• A way of working to best avoid risks and problems and realise opportunities, and which is acceptable to the
team
he consolidation of these points will define the way of working for the future.
• Business Visionary and Technical Coordinator
• roject anager
• Agile BA
• Appropriate members of the Solution Development Team
• Any other relevant stakeholders
The Agile BA may facilitate this Workshop, or an independent facilitator may be used, to allow the AgileBA and
appropriate e bers of the project to fully participate.
A low level futurespective ay be facilitated by the ea eader or the BA.
A Futurespective can be run at any ti e and for any defined future period.
t could be an activity within Feasibility. t is often run at the start of the project and ay be run at the start of a
i ebo .
HOW will it run?
he purpose of a Futurespective is to allow its participants to consider and i agine, as if looking back fro a future
point, how their process actually worked. n doing this, they atte pt to foresee proble s, risks and opportunities
which ay arise, to allowing for their itigation, avoidance or e ploitation.
185
AgileBA Handbook
n a Futurespective, the facilitator will usually pose a viewpoint, such as
“Imagine we have already delivered the solution.”

and ask questions such as:
• What were our Acceptance riteria for the solution we delivered, and were they helpful
• What issues did we have
• What risks aterialised
• What opportunities arose
• What went well
• ow did we feel at the end of a i ebo
his allows tea e bers to air their ideas, raise their concerns and gain a shared vision of the way forward.
The workshop may end with a summary of:
• What aspects of the job ahead are we looking forward to
• What aspects were we worried about and how have we lessened the worry
• What should we continue to do, that we have done before
• What will we change about our way of working
• What will we onitor for opportunity and risk
• What are our acceptance criteria and how will we know when we are done
Requirements Capture/Prioritisation Workshop (User Story

Workshop)
he e uire ents apture and e uire ents rioritisation Workshop often constitutes two or ore linked
workshops, sometimes in close sequence, sometimes separated across phases of the life cycle as greater detail of
re uire ents e erges fro phase to phase of the life cycle.
ser stories are re uire ents e pressed in a particular way, as described in hapter 5 of this book.
he outco e of e uire ents apture e uire ents rioritisation Workshop is an agreed set of
• e uire ents ser tories
• Acceptance criteria for the re uire ents ser tories
• riorities for the re uire ents ser tories
• roject anager
• Agile BA
• Any key stakeholders who have significant input needed for the outco e of the workshop
The BA may facilitate this Workshop, but it is often necessary to involve an independent facilitator for larger or
ore contentious situations.
• Feasibility very high level re uire ents
• Foundations for the definition of the agreed prioritised re uire ents list
186
HOW will it run?
his will typically be a series of workshops, with analysis work in between. he first Workshop ay capture
brainstor ed re uire ents, or present a straw an set of re uire ents for i prove ent. ater workshops ay
refine these and still later ones prioritise the . n order to better understand the re uire ents, acceptance criteria
are usually defined before final prioritisation. he re uire ents are then used in later workshops for esti ating and
planning.
For the definition of high level re uire ents, to be agreed at the end of Foundations, uch work is needed by
the business representatives and the Agile BA between workshops, with input from other team members as
needed. he Agile BA will typically ensure that the full re uire ents lifecycle of elicitation, analysis, validation and
anage ent is carried out, at the appropriate high level for Agile projects, and a necessary level of docu entation
should acco pany this. here should be only just sufficient detail to record and understand the re uire ents,
and enough to esti ate and plan at a level of confidence which represents acceptable risk within the project. oo
uch ti e spent defining the detail of these re uire ents at this point represents wasted ti e, as re uire ents
usually change over ti e. oo little represents risk, the tolerable level of which has to be assessed by business and
technical roles together. n a well understood project environ ent, a uch less detailed re uire ent is usually
tolerable. owever, in a changing environ ent there ay also be little value in trying to capture re uire ents
detail at anything but a very high level. n such e ploratory projects, the risk is itigated by the short ti ebo es
which follow, and regular review associated with the .
he Agile BA should odel the process and identify events and then assist the tea in apping the re uire ents
ser tories to where they have i pact within the process odel and use case odels.
The participants will order the requirements and use the MoSCoW approach for requirements prioritisation
defined in hapter 6. t is i portant that the Agile BA e plains the eaning and i plications of o oW to the
stakeholders who are participants, being careful that people do make the correct distinction between the priorities
and realise the i plications of the different prioritisation levels.
Where ser tories are being defined by the users, the Agile BA will facilitate the process by helping the to
identify the business scenarios related to the stories and consider their acceptance criteria. ere the Agile BA will
enlist the skills of the olution ester to help with the definition of acceptance criteria.
Estimating and Planning Workshops

• he outco e of an sti ating Workshop is an agreed set of esti ates upon which to plan
• The outcome of Planning Workshop is an agreed plan, at the appropriate level
These two workshops are usually separately run but closely linked, the planning not being possible until the
esti ating has been done.
his depends upon the level of planning being undertaken. Appropriate participants ay be drawn fro
• roject anager
• Agile BA
his depends on the level of planning being undertaken. Facilitation should always leave the participants free of the
responsibility of also facilitating.
187
AgileBA Handbook

• Feasibility very high level re uire ents
• Foundations for the definition of the agreed prioritised re uire ents list
• i ebo es
HOW will it run?
his will typically be a series of workshops, clarifying re uire ents and investigating possible solutions.
he lanning sti ating Workshop run at Foundations will typically take the re uire ents ser tories prioritised
for the ne t incre ent and allocate the to i ebo es. he essential ele ent of this is olution evelop ent
ea participation in the planning. he people who are going to be involved in doing the work related to the
re uire ents should be the ones to set and agree esti ates esti ates should not be i posed on a tea .
o ensure eaningful and robust planning, it is essential that good infor ation is available. o e of the uestions
that could be asked at the outset, to determine whether all the necessary information is available are:
• What do we need to know in order to plan effectively
• What do we know
• What don t we know
• ow can we get the infor ation needed
• What are our constraints
• What are we assu ing
Timebox Review Workshop

na project, each i ebo has several recognised review points, for review of the product of the i ebo
as it evolves. he anner of working is iterative develop ent, which involves prototyping and evolving towards a
solution. he volving olution will be shared with a wider group of stakeholders as appropriate at these review
points allow for de onstrations of the product.
WHAT is its outcome?
he outco e of a eview Workshop is a de onstrated, reviewed product and a set of feedback co ents. hese
sessions are co only known as how and ell sessions.
• roject anager
• Agile BA
• Business and echnical Advisors with specific skills, as re uired
• ther key stakeholders, as appropriate
The Agile BA may facilitate this Workshop and a Business Ambassador may demonstrate, or an independent
facilitator ay be used as appropriate.
• Feasibility
• Foundations
• i ebo es on going how and ell related to the volving olution, plus i ebo eview
188
HOW will it run?
A i ebo eview Workshop needs facilitation, since the purpose of the workshop and the e power ent of the
participants need to be clear. he solution ele ents being de onstrated or discussed are, by definition, inco plete.
he e pectations of participants need to be anaged carefully in this respect. Additionally, the e powered
decision akers are the defined roles within the olution evelop ent ea and project level roles. Whilst
opinions will be captured, it will be the e powered roles within the project that will ake decisions about the
volving olution.
The Agile BA can be helpful here in presenting the end-to-end view of the process into which the demonstration
and review fits, to ensure that what ay be de onstrations of s all, disjoint pieces of functionality are viewed in
conte t.
Retrospective
he purpose of a etrospective is to allow a tea to re ect on their way of working, with a view to i proving it.
etrospectives could be run for an entire project, but in practice are usually run at the end of each i ebo .
he purpose of a i ebo etrospective is to allow the olution evelop ent ea to re ect on the i ebo
they have just co pleted, and to inspect their way of working in detail, with a view to i proving it for the ne t
i ebo a process called inspect and adapt .
he outco e of a etrospective should be the identification of process i prove ents for the ne t i ebo .
For a i ebo etrospective
• Agile BA
• All members of the Solution Development Team
• roject anager possibly
• Business isionary and echnical oordinator possibly
• Any stakeholders who have had a significant input to the i ebo that the tea dee to have useful input.
WHO should Facilitate?
he Agile BA ay choose to facilitate this Workshop, or the olution evelop ent ea eader. owever,
both roles ay be dee ed to be too involved, and have a strong role as participants. n this case, a person with
facilitation skills who was independent of the i ebo would be a better choice.
A etrospective is run at the end of every i ebo . hey can also be used at the end of an incre ent and at the
end of the project.
HOW will it run?
he reason for running a etrospective at the end of every i ebo is that learning about how to work together
can be quickly embedded into team processes and practices, improving the process immediately, and for the
re ainder of the project.
The team should ask themselves the following questions:
• What do we want to stop doing
• What do we want to try, or start doing
• What should we continue doing
hey should then work together to define how they will work for the ne t i ebo .
he etrospective should include the whole tea , including business roles.
189
AgileBA Handbook
The Prime Directive of Retrospectives

he key to effective etrospectives is that all participants respect each other and the purpose of the event. he
following ri e irective of etrospectives was proposed by or an erth, and is often helpful in establishing
this focus:
“Regardless of what we discover [here today], we understand and truly believe

that everyone did the best job they could, given what they knew at the time,
their skills and abilities, the resources available, and the situation at hand.”
he Facilitator can present this at the outset of each etrospective, as the ground rules to which the group
should agree to adhere. his allows people the freedo to learn as they go and to be honest about what worked
and what did not, without fear of personal criticis or bla e.
190
Appendix E
Bibliography
1
191
1 1
Bibliography
AgileBA Handbook
Initial Author Title Publisher Date Web Page ISBN
ojko Ad ic Impact Mapping Provoking 2012 www.a a on.co.uk 978 95568364

Thoughts
ojko Ad ic Fifty uick deas Neuri 2 14 www.a a on.co.uk 978 993 881
to Improve your Consulting
ser tories LLP
Scott Ambler Disciplined Agile IBM Press 2012 www.a a on.co.uk 978 13281 135
Delivery
anjiv Augustine Managing Agile Pearson 2007 www.phptr.co 13 124 71 4

rojects
Alistair Cockburn Writing ffective Addison- 2000 www.a a on.co.uk 978 2 17 2255
se ases Wesley
Mike Cohn ser tories Addison- 2 4 www.awprofessional.co 978 3212 5681

Applied Wesley
Mike Cohn Succeeding with Addison- 2009 www.awprofessional.co 978 321579362

Agile Wesley
Mike Cohn Agile sti ating Pearson 2011 www.phptr.co 978 131479418
and Planning
obert Damelio The Basics of Productivity 2011 www.a a on.co.uk 978 1563273766
Process Mapping Press
Deal & Corporate Addison- 1982 www.basicbooks.co 978 7382 38 5

ennedy Cultures Wesley
Deal & The new Basic Books 2 8 www.basicbooks.co 978 7382 38 5

ennedy Corporate
Cultures
Debra Paul, Business Analysis British 2010 www.bcs.org 978 1 9 6124 61 8

Donald 2nd dition Informatics
Yeates, Society
James Cadle
ditors
erby and Agile Pragmatic 2 6 www.a a on.co.uk 978 97761664

Larsen D etrospectives Bookshelf
192
DSDM DSDM DSDM 2 14 www.dsd .org 978 9544832 9 6

Agile roject Consortium
Fra ework
andbook
llen Gottesdiener e uire ents by Addison- 2 8 www.a a on.co.uk 2 1 786 6

Collaboration Wesley
Gottesdiener Discover to B 2012 www.ebgconsulting.co 978 9857879 5

and Deliver Consulting
Gorman M
a pden iding the Waves Nicholas 2012 www.a a on.co.uk 978 19 4838388
Turner of Culture Brealey
Fons Publishing
Trompenaars
Charles andy nderstanding Penguin 1993 www.a a on.co.uk 978 14 156 34

rganisations
Charles andy Gods of Souvenir 2009 www.a a on.co.uk 978 28563844

Management Press Ltd
Geert ofstede Cultures & McGraw- 2010 www.a a on.co.uk 978 7 166418 9
rganisations ill
Software of the
Mind
Geert ofstede Cultures- Sage 2003 www.a a on.co.uk 978 8 3973244

Consequences: Publications
Comparing
Institutions
Johnson & ploring Pearson 2013 www.a a on.co.uk 978 1292 2545
Scholes trategy e t
Cases
Noriaki ano uide to Springer 1996 www.link.springer.co 978 92 833 113

in Service Link
Industries
Norman erth roject Dorset 2001 www.a a on.co.uk 978 932633446

etrospectives ouse
A andbook for Publishing
ea eviews
193
Bibliography
AgileBA Handbook
otonya e uire ents John Wiley 1997 www.wiley.co.uk 471 972 8 8

Sommerville ngineering & Sons
I
Patrick ayfield Practical People bereth 2013 www.ppethebook.co 978 9927114 5

ngage ent Publishing
Dave c insey Creating

rganisational
Transformations
Ale ander sterwalder Business Model John Wiley 2010 www.wiley.co.uk 978 47 87641 1
Generation & Sons
Jeff Patton ser tory eilly 2 14 www.a a on.co.uk 978 14919 49 9

Mapping Media
o an Pichler Agile roject Addison- 2010 www.a a on.co.uk 978 3216 5788
Management Wesley
with Scrum
Mary & Poppendieck The Lean Addison- 2013 www.a a on.co.uk 978 321 8969 2
Tom Mindset Wesley
Michael Porter Competitive Free ress 2 4 www.a a on.co.uk 978 74326 879
Advantage
Penny Pullan Business Analysis ogan age 2013 www.a a on.co.uk 978 74946862
and Leadership
Andrew Stellman Learning Agile eilly 2 14 www.a a on.co.uk 978 1449331924

Media
obert Thomsett adical roject Prentice 2002 www.a a on.co.uk 978 13 94865
Management all
Dorothy Tudor Agile roject The 2010 www.tsoshop.co.uk 978 11331 975
and Service Stationery
Management ffice
Tudor D and The DSDM Galatea 2010 www.a a on.co.uk 978 9543 7134
Tudor I Atern Student
Workbook
Bill Wake efactoring Addison- 2003 www.a a on.co.uk 978 3211 9293
Workbook Wesley
The Scrum www.scru guides.org

Guide
194
John A ach an A Primer for 2003 http www. ach aninternational.co .

nterprise
ngineering and
Manufacturing
electronic
book
195
Bibliography
AgileBA Handbook
196
Appendix F
Index
1
197
1 1
Index
AgileBA Handbook
his inde is in alphabetical, word by word order. t does not cover the isclai er, Acknowledge ents, ontents
list or Foreword.
ocation references are to chapter and section nu ber, e.g.
Agile Alliance, 2.1.2
indicates that infor ation on the Agile Alliance can be found in hapter 2, section 1.2
Abbreviations App Appendi Fig Figure
acceptance criteria
confir ation of eeting, 9.2.2
pic level, 5.5.2
volutionary evelop ent phase, 11.4.4.3
general, 9.3.1.2 11.3.3
tory cards, 5.4.2.2, Fig 5f
Ad ic, ojko, 8.9.1.6, 8.9.1.1
Agile Alliance, 2.1.2
Agile culture in organisations
see also, Business Analysts, transition to Agile culture
general. 1.6.1 4.3 12.5
transition to, 12.3
Agile tea s, 4.1
analysis, see business analysis; requirements, analysis
Balanced Business corecard, Fig 1f

benefits assess ent, 2.7.14
benefits realisation, 3.3.3
bibliography, App 3
B , 8.7.4.1
Build ncre entally fro Fir Foundations rinciple 5 , 2.4.5 8.11
see also Principles
Burn down charts, 9.2.2, Fig 9d
Business Advisors
role, 2.6.4.1
working with, 4.4.3.1
198
Business Ambassadors
prioritisation of re uire ents, 6.6
role, 2.6.4.7
business analysis
see also Business Analysts
general, 1.1 1.2
holistic view, 1.2.1, Fig 1b
s all scale changes, 3.2.3
top to botto analysis, Fig 1a
Business Analysts
see also business analysis
develop ent of Business ase, 3.2.1, 3.3.2, 3.5.5
holistic view of business, 1.2.1
involve ent in project lifecycle, Fig 3a Fig 1 a
re uire ents gathering, checklist, 5.1
role
Agile projects, 2.9 1
tea s, 2.6.4.5
Facilitated Workshops, 7.3 12.4.3
general, 1.2, 1.7
terative evelop ent, 9.3.6
i ebo es, 9.2.2
skill re uire ents, 1.1
top prioritisation tips, 6.8
transition to Agile culture
Facilitated Workshops, 12.4.3
general, 12.1, 12.4, 12.5, Fig 12a
odelling, 12.4.2
prototyping, 12.4.2
re uire ents considerations, 12.4.1
transitioning organisations to Agile, 12.2 3, Fig 12b
understanding business environ ents, 1.3 3.2, 1.7
Business anvas, 8.9.1.1, Fig 8c
see also modelling techniques
199
Index
AgileBA Handbook
Business Case
contents, 3.4 4.1, Fig 3b
creation
eploy ent phase, 3.3.5
volutionary evelop ent phase, 3.3.4
Feasibility phase, 3.3.2
Foundations phase, 3.3.3
ost project phase, 3.3.6
re project phase, 3.3.1
develop ent, 3.2.1
Facilitated Workshops, 3.6.2
for at, 3.4
general, 2.7.1.2 3.1, 3.7
terative evelop ent, 3.6.4
odelling, 3.6.3
prioritisation, 3.6.1
project business case, 3.2.1
proposed solution, 3.4.2
prototyping, 3.6.3
purpose, 3.4
re uire ent for, 3.2
role involvement
Agile Business Analyst, 3.5.5
Business ponsor, 3.5.1
Business isionary, 3.5.2
roject anager, 3.5.4
echnical o ordinator, 3.5.3
si e, 3.4
s all changes within organisation, 3.2.3
strategic business needs, 3.2.2
Business o ain odel lass odel , 8.9.1.2, Fig 8d
business environment
e ternal in uences, 1.3 3.1, Fig 1c
internal in uences, 1.3, 1.3.2, Fig 1c
200
Business rocess iagra s, 8.9.1.3, Fig 8e 12.4.2
see also, modelling techniques
Business rocess odelling otation B , 8.7.4.1
see also modelling
Business Sponsors
creation of Business ase, 3.3.2, 3.5.1
role, 2.6.4.1
Business ision, 3.4.1 5.5.2
Business Visionaries
ownership of re uire ents, 1 .2
prioritisation of re uire ents, 6.6
role, 2.6.4.2
A , 5.4.3
change management
considerations
collaboration, 1.6.3
co unication, 1.6.2
culture, 1.6.1
general, 1.6
heckland, eter, 8.9.1.9
lass odels, 8.9.1.2, Fig 8d
ohn, ike, 1 .5.3.1
ollaborate rinciple 3 , 2.4.3 8.11
see also Principles
collaboration, 1.6.3 4.1
see also stakeholders
co on sense, 2.2, Fig 2a
o unicate ontinuously and learly rinciple 7 , 2.4.7
see also Principles
201
Index
AgileBA Handbook
communication
effectiveness of odelling, 8.3, 8.12
plans, 1.6.2
presentation of infor ation, 9.5, Figs 9f g
with stakeholders, 4.8 5.9
o puter Aided e uire ents ngineering A , 5.4.3
onte t coping iagra s
Foundations phase, 8.8.2 8.3
general, 8.9.1.4, Fig 8f
ost, as project variable, 2.3, Fig 2b
ould ave re uire ents, 6.3.1.3 11.4.4.4
see also MoSCoW prioritisation
usto er ourney apping, 8.9.1.5, Fig 8g
aily tand ups, 9.2.2.1

eliver on i e rinciple 2 , 2.4.2 8.11
see also Principles
elivery lans, 2.7.1.6
e onstrate ontrol rinciple 8 , 2.4.8 8.11
see also Principles
eployed olution, 8.8.5
Deployment phase
Business ase, 3.3.5
Facilitated workshops, 7.6 12.4.3
general, 2.5.5
odelling, 8.8.5
re uire ents, 11.4.5
evelop teratively rinciple 6 , 2.4.6 8.11
see also Principles
evelop ent Approach efinition A , 2.7.1.5
distributed workshops, 7.11
see also Facilitated workshops
202
documentation
audit trials, 2.7.2
Feasibility phase, 11.4.2.4
Foundations phase, 11.4.3.4
general, 11.3.4.1
re project phase, 11.4.1.4
transition fro Waterfall approach to Agile, 12.3
DSDM
benefits, 2.1.6
co position, 2.2, Fig 2a
creation, 2.1.1 1.2
difference fro Agile approaches, 2.1.4
difference fro traditional project approach, 2.1.3
philosophy, 2.2
principles, see Principles
process, Fig 2c
products, see products
reasons for choosing, 2.1.5
roles, see roles
tea odel, Fig 2d Fig 4a
DSDM Coaches
role, 2.6.4.13
tructured i ebo es, 9.2.1 2.1.1, Fig 9a
see also i ebo es
203
Index
AgileBA Handbook
elicitation of requirements
see also requirements
general, 11.3.1
e power ent, olution evelop ent ea , 9.3.5
pics
see also he es ser stories
Foundations phase, 11.4.3 4.3.4
general, 5.5.2, Fig 5g
estimates
difference within projects, 1 .5.2
esti ating workshops, 1 .5.4
general, 1 .5, 1 .6
lanning oker techni ue, 1 .5.3.1
process, 1 .5.1
re uire ents detail, 1 .5.3, Fig 1 d
volutionary evelop ent phase
Business ase, 3.3.4
general, 2.5.4
odelling, 8.8.4
re uire ents activity, 5.6.3
volving olution
co unication of, 9.5, Fig 9g
general, 2.7.1.1
e plicit knowledge, 9.4.1
see also knowledge types
e ternal in uences on businesses, 1.3.1, Fig 1c
see also W analysis
204
see also Workshop Facilitators
activities, 7.9
define and plan, 7.9.1
docu ent, 7.9.5
facilitate, 7.9.3.1 9.3.2
follow up, 7.9.6
prepare, 7.9.2
retrospectives, 7.9.4 9.2.2
benefits, 7.1
creation of Business ase, 3.6.2
definition, Fig 7a
distributed tea environ ents, 7.11
esti ating workshops, 1 .5.4
features, 7.7, Fig 7c
general, 7.1, 7.12
roles
Business Analyst, 7.3 12.4.3
e a ple Fig 7b
observer, 7.5.5
participant, 7.5.4
scribe, 7.5.3
workshop facilitator, 7.5.2
workshop owner, 7.5.1
success measures
clear agenda, 7.8.5
clear objectives, 7.8.2
clear scope, 7.8.3
e powered participants, 7.8.4
facilitators, 7.8.1
outputs outco es, 7.8.6
types in Agile project phases, 7.6 App
use, 7.2, 7.4
Feasibility Assess ents
general, 2.7.1.8
inclusion of Business ase, 3.3.2
205
Index
AgileBA Handbook
Feasibility phase
Business ase, 3.3.2
general, 2.5.2
odelling, 8.8.2
requirements
activity, 5.6.1 6.7.1
analysis, 11.4.2.2
docu entation, 11.4.2.4
elicitation, 11.4.2.1
general, 11.4.2
anage ent, 11.4.2.4
planning, 1 .3.1
validation, 11.4.2.3
workshops, 7.6 12.4.3
Features, as project variable, 2.3, Fig 2b
Focus on the Business eed rinciple 1 , 2.4.1 8.11
see also Principles
Foundation u aries, 2.7.1.9
Foundations phase
Business Analyst role, 1 .3.2
Business ase, 3.3.3
general, 2.5.3
odelling, 8.8.3
re uire ents activity, 5.6.2 6.6, 6.7.1
re uire ents planning, 1 .3.2
workshops, 7.6 12.4.3
Free for at i ebo es, 9.2.1, 9.2.1.2, Fig 9b
see also i ebo es
Functional e uire ents F s , 5.3.1.3, Fig 5b 11.3.2
eneral Business e uire ents B s , 5.3.1.1

glossary, App A
206 205
governance processes, products used in
Benefits Assess ents, 2.7.1.14
Feasibility Assess ents, 2.7.1.8
Foundations u aries, 2.7.1.9
roject eview eport, 2.7.1.13
er s of eference, 2.7.1.1
i ebo eview ecords, 2.7.1.12
pact apping, 8.9.1.6

pact aps, 5.5.5, Fig 5i
see also ser stories
internal analysis of business, 1.3, 1.3.2, Fig 1c
see also W analysis
Agile BA role, 9.3.6, 9.6
Business ase, 3.6.4
controlling, 9.3.4
general, 9.1, 9.3
uality criteria, 9.3.1 3.1.1
solution focus, 9.3.3
testing, 9.3.2, Figs 9e f
validation, 9.3.1.3
verification, 9.3.1.3
acobsen, var, 8.9.1.12
an Ban boards, 9.2.2, Fig 9c

A odels
see also requirements, prioritisation
e a ple, Fig 6b
e citer features, 6.5.1.3
e pected features, 6.5.1.1
general, 6.5
nor al features, 6.5.1.2
207
Index
AgileBA Handbook
knowledge types
e plicit, 9.4.1
general, 9.4
se i tacit, 9.4.3
tacit, 9.4.2
layered solution architecture, 9.3.3

ean anvas, 8.9.1.1, Fig 8c
ean thinking, 1.4.2
see also value, creation of
learning styles, 9.5, Fig 9f
see also communication
anage ent Approach efinition A , 2.7.1.7

management of requirements
general, 11.3.4.2
anifesto for Agile oftware evelop ent, 2.1.2
aurya, Ash, 8.9.1.1
c insey 7 odel, Fig 1e
ini u sable ubse
see also MoSCoW priorisation
delivery, 3.6.1 4.3 6.3.2
ust ave re uire ents, 6.3.1.1
modelling
see also prototypes
abstraction, 8.4
Agile lifecycle
eploy ent phase, 8.8.5 12.4.2
volutionary evelop ent phase, 8.8.4 12.4.2
208
Feasibility phase, 8.8.2 12.4.2
Foundations phase, 8.8.3 12.4.2
general, 8.8
approaches, 8.1
as is and to be , 8.6, Fig 8a
Business Analyst role, 8.1 12.4.2
Business ase, 3.6.3
rinciples, 8.11
general, 8.1, 8.12
languages
Business rocess odelling otation B , 8.7.4.1
general, 8.7.4
nified odelling anguage , 8.7.4.2
perspectives
breadth of re uire ents perspective, 8.7.2
general, 8.7.1, Fig 8b
single user role perspective, 8.7.3
purpose, 8.1
techniques, see modelling techniques
modelling techniques
Business anvas, 8.9.1.1, Fig 8c
Business o ain odels, 8.9.1.2, Fig 8d
Business rocess odels, 8.9.1.3, Fig 8e
lass odels, 8.9.1.2, Fig 8d
onte t coping iagra s, 8.9.1.4, Fig 8f
usto er ourney apping, 8.9.1.5, Fig 8g
general, 8.9 9.1
pact apping, 8.9.1.6, Fig 8h
ean anvas, 8.9.1.1, Fig 8c
ersonas, 8.9.1.7, Fig 8i
roduct ision Bo es, 8.9.1.8, Fig 8j
ich ictures, 8.9.1.9, fig 8k
pecification by e a ple, 8.9.1.1
toryboards, 8.9.1.11, Fig 8l
209
Index
AgileBA Handbook
se ases, 8.9.1.12, Fig 8

use in DSDM lifecycle, App B
ser tory apping, 8.9.1.13
alue chains strea s, 8.9.1.14, Fig 8p
Wirefra e diagra s, 8.9.1.11, Fig 8l
models
see also modelling; prototypes
definition, 8.2
purpose, 8.2
target audience, 8.3
MoSCoW prioritisation
see also requirements, prioritisation
Business ase, 3.6.1
business value, 6.3.1.5
ould ave re uire ents, 6.3.1.3 11.4.4.4
delivery of re uire ents, 6.3.2
dependencies between re uire ents, 6.4
general, 6.3.1, Fig 6a
ust ave re uire ents, 6.3.1.1, 6.7.1
hould ave re uire ents, 6.3.1.2 11.4.4.4
i ebo es, 1 .3.3.1
understanding need for, 4.4.1.1
Won t ave this ti e re uire ents, 6.3.1.4 11.4.4.4
analysis, 1.3.2, Fig 1c
uda waste , 1.4.2
, see ini u sable ubse
ust ave re uire ents, 6.3.1.1, 6.7.1
ever o pro ise uality rinciple 4 , 2.4.4 8.11

see also Principles
on functional re uire ents F s , 5.3.1.4, 5.6.1, Fig 5b 11.3.2
210
observers at Facilitated Workshops, 7.5.5
see also Facilitated Workshops
organisation culture, 1.6.1
organisational odels, 1.2
sterwalder, Ale , 8.9.1.1
participants in Facilitated Workshops, 7.5.4, 7.8.4, 7.11

people
see also roles; stakeholders
co position of , 2.2, Fig 2a
ea odel, 2.6 6.1, Fig 2d
ersonas, 8.9.1.7, Fig 8i
, 1.3.1, Fig 1c
lanning oker esti ating techni ue , 1 .5.3.2
see also estimates
orter s Five Forces Analysis, 1.3.1, Fig 1c
orter s alue hain, 1.4.1, Fig 1d
see also value, creation of
ost project phase
Business ase, 3.3.6
general, 2.5.6
odelling, 8.8.6
re uire ents, 11.4.5
power interest grids, 4.7.2, Fig 4d
see also stakeholder analysis
practices, 2.2, 2.8, Fig 2a, Fig 2f
see also Facilitated Workshops ini u sable ubse o oW prioritisation
prag atis , 2.2, Fig 2a
211
Index
AgileBA Handbook
re project phase
Business ase, 3.3.1
general, 2.5.1
odelling, 8.8.1
requirements
analysis, 11.4.1.2
elicitation, 11.4.1.1
general, 11.4 4.1
anage ent, 11.4.1.4
Principles
general, 2.2, 2.4, 2.4.9, Fig 2a
rinciple 1 Focus on the Business eed, 2.4.1 8.11
rinciple 2 eliver on i e, 2.4.2 8.11
rinciple 3 ollaborate, 2.4.3 8.11
rinciple 4 ever o pro ise uality, 2.4.4 8.11
rinciple 5 Build ncre entally fro Fir Foundations, 2.4.5 8.11
rinciple 6 evelop teratively, 2.4.6 8.11
rinciple 7 o unicate ontinuously and learly, 2.4.7
rinciple 8 e onstrate ontrol, 2.4.8 8.11
rioritised e uire ents ist
baselining, 5.6.2, 5.7 11.4.3.3
develop ent aintenance, 5.7
e a ple, Fig 5d
general, 2.7.1.3 3.3.3 1 .4, Fig 1 c
production, 11.4.3.4
recording of re uire ents, 5.4.4
recording of ser stories, 5.4.1
processes
configuring for scalability, 2.5.8
212
general, 2.2, 2.5, 2.5.9, Fig 2a, Fig 2c
lifecycle, 2.5.7
ost project, 2.5.6
roduct ision Bo es, 8.9.1.8, Fig 8j
products
Benefits Assess ent, 2.7.1.14
Business ase, 2.7.1.2
elivery lan, 2.7.1.6
evelop ent Approach efinition A , 2.7.1.5
volving olution, 2.7.1.1
Feasibility Assess ent, 2.7.1.8
Foundation u ary, 2.7.1.9
general, 2.2, 2.7, 2.7.2, Fig 2a, Fig 2e
anage ent Approach efinition A , 2.7.1.7
rioritised e uire ents ist , 2.7.1.3
roject eview eport, 2.7.1.13
olution Architecture efinition A , 2.7.1.4
er s of eference, 2.7.1.1
i ebo lan, 2.7.1.11
i ebo eview ecord, 2.7.1.12
roject Approach uestionnaire A , App
project level roles
see also roles
Business Analyst, 2.6.4.5, 2.9
Business ponsor, 2.6.4.1
Business isionary, 2.6.4.2
general, 2.6.2.1
roject anager, 2.6.4.4
echnical o ordinator, 2.6.4.3
roject anagers
co unication planning, 4.8
role, 2.6.4.4
213
Index
AgileBA Handbook
roject eview eports, 2.7.1.13

roject tea s, collaboration, 4.1
see also collaboration
projects
approach, 2.1.3, Fig 2b
project stakeholders, 4.2
project variables, 2.3, Fig 2b
traditional approach, 2.1.1, Fig 2b
roof of oncept, 8.8.2 9.3.2 12.4.2
see also prototypes
protocol analysis, 9.4.2
prototypes
see also modelling; models
benefits of prototyping, 8.5.2
definition, 8.5 5.1
Foundations phase, 8.8.3 11.4.3.3 12.4.2
general, 3.6.3 4.4.1.2, 4.5
roof of oncept, 8.8.2 9.3.2 12.4.2
specification by e a ple, 8.9.1.1
uality, as project variable

criteria, 9.3.1 3.1.1
general, 2.3, Fig 2b
uality eview eetings, 3.3.3 11.5.1
A A atrices, 4.7.1, Fig 4c

see also stakeholder analysis
apid Application evelop ent A , 1.3.1 2.1.1
requirements
analysis
214 213
general, 11.3.2
Business Analysts transitioning to Agile culture, 12.4.1
baselining, 5.6.2, 5.7
categories
classification, 5.3.1, Fig 5a
Functional e uire ents, 5.3.1.3, Fig 5b
eneral Business e uire ents, 5.3.1.1
on functional e uire ents, 5.4.1.4, Fig 5b
echnical olicy e uire ents, 5.3.1.2
checklist for Agile Business Analysts, 5.1
co unication of to others, 5.9
consideration of whole set, 5.4.4
defining needs, 5.2, 5.8
definition, 5.3
dependencies between, 6.4
general, 5.1, 5.11
lifecycle, see re uire ents lifecycle in Agile projects
planning, see requirements planning
prioritisation, see requirements prioritisation
re uire ents lifecycle in Agile projects
Agile BA role, 11.2
volutionary evelop ent phase, 5.6.3 11.4.4 4.4.4
Feasibility phase, 5.6.1 11.4.2 4.2.4
Foundations phase, 5.6.2 11.4.3 4.3.4
general, 5.6, Fig 5j 11.1, 11.6, Figs 11a b
hierarchy of requirements
analysis, 11.3.2
elicitation, 11.3.1
general, 11.3
anage ent, 11.3.4.2
validation, 11.3.3
215
Index
AgileBA Handbook

re project phase, 11.4.1 4.1.4
requirements planning
Agile BA role, 1 .2, Fig 1 a 11.2
Feasibility phase, 1 .3.1
Foundations phase, 1 .3.2
general, 1 .1, 1 .6
level of detail re uired, 1 .2 11.1
lifecycle ti eline, Fig 1 a
i ebo es, 1 .3.3 3.3.1
requirements prioritisation
see also rioritised e uire ents ist
drivers, 6.2
effective prioritisation, 6.6
general, 6.1, 6.9
ethods, 6.3
see also A odels o oW prioritisation
i ebo es, 6.7.2
top tips, 6.8
esource audits, 1.3.2, Fig 1c
ich ictures
odelling techni ue, 8.9.1.9, Fig 8k
roles
ea odel, Fig 2d Fig 4a
fulfil ent of, 2.6.3
general, 2.6.5
project level
Business ponsor, 2.6.4.1
Business isionary, 2.6.4.2
general, 2.6.2.1
216
roject anager, 2.6.4.4
echnical o ordinator, 2.6.4.3
olution evelop ent ea
Business A bassador, 2.6.4.7
general, 2.6.2.2
olution eveloper, 2.6.4.8
olution ester, 2.6.4.9
ea eader, 2.6.4.6
supporting roles, 2.6.2.3
Business Advisor, 2.6.4.1
oach, 2.6.4.13
echnical Advisor, 2.6.4.11
Workshop Facilitator, 2.6.4.12
scenarios, 5.4.2.2
see also Story cards
scribes, 7.5.3
, see olution evelop ent ea
se i tacit knowledge, 9.4.3
hackleford, B, 8.9.1.8
hould ave re uire ents, 6.3.1.2 11.4.4.4
olution Architecture efinition A , 2.7.1.4
olution architecture layers, 9.3.3
Solution Developers
role, 2.6.4.8
olution evelop ent ea
Burn down charts, 9.2.2, Fig 9d
Business A bassador, 2.6.4.7
control of changes within i ebo es, 9.3.5
general, 2.6.2.2
217
Index
AgileBA Handbook
olution eveloper, 2.6.4.8

olution ester, 2.6.4.9
ea Boards, 9.2.2, Fig 9c
ea eader, 2.6.4.6
working collaboratively, 4.4.2.5, 4.9, Fig 4b
Solution Prototypes
see also prototypes
creation during Foundations phase, 8.8.3 1 .3.2 11.4.3.3
de onstration, 3.6.2
Solution Testers
role, 2.6.4.9
stakeholder analysis
general, 1.6.3
power interest grids, 4.7.2, Fig 4d
A A atrices, 4.7.1, Fig 4c
stakeholders
analysis of, see stakeholder analysis
Business ase, creation, 3.3.2
categories, 4.2
co unication planning, 4.8
definition, 4.2
philosophy, 2.2
engage ent, 4.3, 4.9 1
working with
key ele ents, 4.6
project stakeholders, 4.4.1.1 4.1.3
olution evelop ent ea , 4.4.2.1 4.2.5
supporting roles, 4.4.3.1 4.3.3
wider co unity, 4.5
Story cards
see also ser stories
creation of pact aps fro , 5.5.5, Fig 5i
creation of tory aps fro , 5.5.4, Fig 5h
front, 5.4.2.1, Fig 5e
general, 5.4.2
reverse, 5.4.2.2, Fig 5f
218
tory aps, 5.5.4, Fig 5h Fig 8n 1 .3.1, Fig 1 b
see also ser stories ser tory apping
toryboards, 8.9.1.11, Fig 8l
strategic Business Analysts, 3.3.2
see also Business Analysts
strategy
Balanced Business corecard, Fig 1f
i ple entation within organisation, 1.5
c insey 7 odel, Fig 1e
supporting roles
see also roles
Business Advisor, 2.6.4.1
oach, 2.6.4.13
general, 2.6.2.3
echnical Advisor, 2.6.4.11
Workshop Facilitator, 2.6.4.12
Swimlanes, see Business Process Diagrams
W analysis, 1.3.3, Fig 1c
tacit knowledge, 9.4.2

ea Boards, 9.2.2, Fig 9c
Team Leaders
role, 2.6.4.6
Technical Advisers
role, 2.6.4.11
Technical Co-ordinators
Business ase, creation, 3.3.2, 3.5.3
role, 2.6.4.3
technical policy re uire ents, 5.3.1.2
219
Index
AgileBA Handbook
er s of eference
Business ase, 3.3.1
Feasibility phase, 5.6.1 1 .3.1
general, 2.7.1.1
re project phase, 11.4.1 4.1.4
testing, 9.3.2
Themes
see also pics ser stories
general, 5.5.1, Fig 5g
i e, as project variable, 2.3, Fig 2b
i ebo lans, 2.7.1.11
i ebo eview ecords, 2.7.1.12
i ebo eviews, 9.2.2
i ebo es
Agile BA role, 9.2.2
changes within, 9.3.5
tructured i ebo , 9.2.1 2.1.1, Fig 9a
Free for at i ebo , 9.2.1, 9.2.1.2, Fig 9b
general, 9.2
in conte t of project, 9.2.3, Fig 9e
investigation of ser stories, 5.6.3
o oW prioritisation, 1 .3.31
re uire ents planning, 1 .3.3
re uire ents prioritisation, 6.6, 6.7.2
solution delivery, 9.3.3, Figs 9
i ebo ing, 9.1 2
W analysis, 1.3.3, Fig 1c
nified odelling anguage , 8.7.4.2

see also modelling
se ases, 8.9.1.12, Fig 8 12.4.2
ser stories
see also pics re uire ents he es
baselining, 5.6.2, 5.7
220
definition, 5.4.1
volutionary evelop ent, 5.6.3 11.4.4 4.4.4
e a ple, Fig 5c
for at, 5.4.1, 5.4.3
hierarchy, 5.5, Fig 5g
odel, 5.4.3
specificity, 5.5.3
story cards, see Story cards
ser tory apping, 8.9.1.13
see also modelling techniques; Story maps
validation of requirements
general, 11.3.3
value, creation of, 1.4
see also Lean thinking
value chain analysis, 1.4.1, Fig 1d 8.9.1.14, Fig 8o
value strea analysis, 1.4.1 8.9.1.14, Fig 8o
waste, 1.4.2
Waterfall approach to projects
general, 2.1.1 12.5
transition to Agile approach, 12.3
Wirefra e diagra s, 8.9.1.11, Fig 8l
Won t ave this ti e re uire ents, 6.3.1.4 11.4.4.4
221
Index
AgileBA Handbook
Workshop Facilitators
Agile Business Analyst as, 7.3
preparation for workshops, 7.9.2
role, 2.6.4.12
role in Facilitated Workshops, 7.5.2, 7.8.1, 7.9.3.2
workshop owners
role, 7.5.1
defining objectives, 7.8.2, 7.9.1
workshop reports, 7.9.5
workshops, see Facilitated Workshops
222
223
This eBook was purchased by:
Name: Karolina Jurowicz

Email: gladczak.k@gmail.com
on 01/05/2022 10:06 UTC.
EditionMark Powered by EditionGuard.com

Agileba Handbook 5 8qYBzy2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agileba Handbook 5 8qYBzy2

Uploaded by

Copyright:

Available Formats

This eBook was purchased by:

Name: Karolina Jurowicz

EditionMark Powered by EditionGuard.com

rinted in the nited ingdo by Buckland edia roup i ited, www.buckland.co.uk

1.2 The Holistic View of the Business

Figure 1a: Top to bottom analysis within an organisation

1.2.1 Organisation, people, process, technology

Figure 1b: The holistic view of a business

1.3 Understanding the Business Environment

Figure 1c: External/internal analysis

1.3.2 Internal analysis

Human Resource Management

Marketing & Sales

Support Activities Primary Activates Gross Sales

Figure 1d: Porter's value chain

1.5 Implementing the Organisation’s Strategy

Figure 1e: McKinsey 7S model

“To achieve our vision, A measurement

Figure 1f: Balanced business scorecard

1.6 Change Projects

2.1 Choosing DSDM as your Agile approach

Individuals and interactions over processes and tools

Kent Beck James Grenning Robert C. Martin

2.1.3 How does DSDM differ from more traditional approaches?

2.1.4 How does DSDM differ from most Agile approaches?

2.2 Philosophy and Fundamentals

Common sense and pragmatism

Figure 2a: The composition of DSDM

2.3 Understanding Project Variables

Traditional Approach DSDM Approach

Figure 2b: Project variables - traditional and DSDM

1. Focus on the business need 2. eliver on ti e

3. ollaborate 4. ever co pro ise uality

5. Build incre entally fro fir foundations 6. evelop iteratively

7. o unicate continuously and clearly 8. e onstrate control

2.4.1 Principle 1 - Focus on the Business Need

2.4.5 Principle 5 - Build Incrementally from Firm Foundations

2.5 The DSDM Process

Figure 2c: The DSDM process

2.5.4 Evolutionary Development phase

Business Project Technical

Technical Business Business

Solution Development Team

Figure 2d: The DSDM tea

2.6.1 The DSDM Team Model explained

Pre-Project Feasibility Foundations Evolutionary Development Deployment Post-Project

Business Case Supporting

Definition Testing &

Development Approach Solution

Figure 2e: DSDM products

2.7.1 The DSDM Products

2.7.1.2 Business Case

2.9 The Agile BA within the Agile Project

3.2 Why do we need a Business Case?

3.3 When is a project Business Case Created and How

Detailed requirements emerging

Figure 3a: BA involvement in a DSDM project

3.4 What should an Agile Business Case Contain?

Where we are now Where we want to be

How can we get there?

Figure 3b: Business Case and options

3.5 Involvement of the Agile Roles in the Business Case

3.6 Agile Practices and the Business Case