Considers the purpose of business analysis, with trade-offs between rigour and simplicity. Agile methods can help bridge the gap, by concentrating on the details that matter at a particular time, rather than trying to understand everything at once. Finally, some simple methods using tools such as Trello are used to show how roadmaps, product backlogs and story maps can be captured and communicated.

1. Simple approaches to
agile business analysis
Tony Willoughby, Ascham Consulting
awilloughby@aschamconsulting.com
1

2. Contents
1. Introduction
2. Traditional (i.e. waterfall) approaches to BA
3. Complexity vs. Rigour
4. Agile methods
5. Simple tools – e.g. Trello
2

3. Tony Willoughby - bio
I am a freelance consultant working in the Cambridge area. I specialise in agile
development - delivery management, business analysis, agile coaching &
training…
Recent projects include:
● Digital transformation for an international training business
● Delivery manager for the apprenticeship levy (public sector)
● Service architect for a 300 person public sector transformation project
● Design and delivery of training courses for agile adoption
Contact: awilloughby@aschamconsulting.com, and www.linkedin.com/in/tonywilloughbyuk/
3

4. Waterfall development
4
Requirements
Design
Build
Test
Deploy
We could
a) Resist change
b) Accept changes and the
resulting delays
That doesn’t
work either!
Requirements
understanding is
a journey, not
an end state
Requirements
Design
Build
Test
Deploy
?
?
? OR
We could spend more
time on the
requirements?

5. Methods and tools
Some simple methods
● Text
● Requirements catalogue (aka scope matrix)
● Diagrams/rich pictures
More complex methods
● Flow charts
● Data flow diagrams
● UML (use cases, activity diagrams, domain models, state transitions…)
● SSADM (DFDs, LDMs, ELHs, ECDs…)
5

6. Rich picture (example)
6

7. Example – dataflow diagram
7

8. Example – domain object model
8

9. Example – state transition diagram
9

10. Simplicity vs rigour
A new initiative starts with an idea
Vision, inspiration, elastic, flexible, ambiguous….
And if successful it culminates in an implementation (code)
Detailed, rigorous, precise, unforgiving
How do we move from the Vision to the Code (and bring everyone with us)?
That is the job of Business Analysis!
10

11. Complexity vs Rigour
11
Vague,
ambiguous
Simple
but vague
Complex but
imprecise
Complete
and precise
Precise but
incomplete
Simple, clear
uncluttered
Complex,
incomprehensible
Precise,
unambiguous
Complexity
Rigour
Idea
Code

12. Stakeholder engagement
● Why do stakeholders need to understand the analysis?
● Because
○ They are the people who want the system
○ They are the ones who should determine what’s in and what’s out
○ The better they are informed, the better decisions they will make
12

13. Complexity vs Rigour
13
Pre- and
Post-
conditions
Code
Complexity
Rigour
Idea
Free
text
User stories
Rich
pictures
Use
cases
Flow
charts
Class
diagrams,
LDMs
Data flow
diagrams
Other
UML or
SSADM
Activity
diagrams

14. Why does increasing rigour lead to lower clarity?
BA methods can reduce clarity because:
● Specialist knowledge required
○ BA tools and methods may require specialist knowledge to interpret
● Volume of information goes up
○ Business stakeholders don’t have time to digest it all
● Details obscure important information
○ Clear structure can help to navigate
Agile methods can help bridge the gap
14

15. Agile business analysis
15
Code
Complexity
Rigour
Idea
Detailed
User
StoriesEpics
Acceptance
criteria
Scope
Detail
Prioritise
Documents,
Diagrams, Charts etc.
Build &
Test

16. Continuous development
16
Scope
(backlog)
Stories
(subset)
Refined
stories
Code
Running
code
Select
(prioritise)
Detail
Develop
Deploy
Review,
refine

17. Tools to support agile BA
● Simple tools, little structure
○ E.g. MS Office docs, spreadsheets, drawing tools
● High level structure
○ Trello + docs, Jira + Confluence, etc.
● More complex, specific language and notation
○ Flow charts, UML tools, etc.
17

18. Roadmap
● A roadmap provides
○ High level scope
○ High level plan
○ Communication tool
18

19. Product backlog
● Defines the overall scope of the project
● Comprised of user stories
● Undergoes continuous refinement
○ High priority stories are detailed first
○ Low priority stories are left as placeholders, for later iterations
19
Export
Excel or
HTML/Word
document

20. Excel Export
20

21. HTML export
21

22. Creating the Sprint Backlog
22
High
Low
Priority
Product Backlog Sprint Backlog
Add to the Scrum/Kanban
board

23. Conclusions
● Business analysis is best regarded as a journey, not a result
● Rigorous methods of BA add complexity, and often reduce clarity
● Agile development simplifies the process, using just-in-time BA, with
just enough complexity
● Simple tools such as Trello, and commonsense, are often enough.
23

24. To discuss
● What tools do you use for doing business analysis?
● How do you rate them in terms of complexity vs. rigour?
24