Slides from a presentation given by David Jurczyszyn to the North branch of IIBA UK on 29/06/2016

1. THE AGILE BA
JUST GET OUT OF THE WAY

2. SOME QUESTIONS?
What is a
requirement? How does this
get translated
into a product?
When was the
last time you
talked to a
developer?
When was the
last time you
talked to a
tester?
How are your
requirements
translated for
testing?
When did you last
ask a user to
speak to a
developer?
When did you last
test a product you
did the
requirements for?
When did you last
say “if you didn’t
have this
requirement for
live would you go
ahead?”

3. IS THIS THE PROBLEM?
Stakeholders
BA
Developers
Customers Users Business
Testers
Is this how you
work?

4. AN AGILE RETROSPECTIVE
Break into small groups – 4 to 8 people
How can we do this better? – 3 or 4 ideas
Vote on our favourite – 3 dots each
Commit to some action
Each team introduces their ideas Reflection is an
important part of
the agile process

5. RETROSPECTIVE

6. AGILE BA APPROACH
• High value high priority items first, a change is just another
requirement, add it and prioritise
• Turn stakeholders into developers and testers
• Executable specifications over static documents (a requirement is
a test)
• Just in time detail and breadth, no big requirements up front –
analysis is organic and should be done every day
• Explore problems through vertical slicing
• Developers and testers are perfectly capable of speaking to the
business, sometimes you just have to get out of the way

7. ANY QUESTIONS?
TAKK

9. A STUDY IN PROJECT FAILURE
Source: http://www.bcs.org/content/ConWebDoc/19584

10. WHY IS THIS WRONG?