What is your role as a BA on a Scrum team? How do you fit in? This presentation was given to the IIBA conference in NZ in 2010 by Stephen Reed. Stephen had worked extensively as a BA and moved into using Scrum with multiple teams at a large Insurance company. This experience led to a lot of questions around what the BA should be doing on a Scrum team. This presentation goes some way to listing what worked in the teams Stephen was involved in. The BA role does not change and all the skills of a great BA are necessary still on a great Software Development team, just more focused on being a team member and utilising those skills for the Scrum process of getting working software to the customer with more focus and clarity for the user.

1. Sprint •Agile Sprint •Analysis Sprint •Backlog
1 •Scrum 2 •Stories 3 •End
DEMYSTIFYING THE ROLE
OF THE BA ON AGILE
SOFTWARE DEVELOPMENT PROJECTS
(USING SCRUM)
Stephen Reed
BA and ScrumMaster

2. Scenario – Sprint 19
• We are in to our 4th release of the software
• It is day 9 of our 19th Sprint (2 week long sprints)
• The team is feeling under pressure as they have
only completed 1 of the 7 stories they committed
to in sprint planning.
• There is no way everything will be done ready for
the review, which is tomorrow.
What happened?
• What could have caused the team to not meet what they
committed to?
• What have they learnt?
• What could they improve on in next sprint?

3. WHAT COULD WE HAVE DONE BETTER?

4. WHY HAVE A SPECIAL TERM – AGILE?
Agile is an umbrella term that includes various
approaches, methods, and techniques that:
use short iterations and
continuous customer feedback
so that the project team can evolve the customer
need (a.k.a. the product).
-Mario E. Moreira, 2010
CM Expert
Sprint •Agile
1 •Scrum

5. THERE IS AN AGILE MANIFESTO
http://agilemanifesto.org/
use short iterations and
continuous customer feedback
So that we can get working software in front of our
customer fast, and then repeat the cycle.
Sounds practical and pragmatic – right?
Can it be done?
Who does it?
Do we already do it?
Do we want to improve our “value add” to the customer?
What’s holding us back?

6. SOMEONE TRIED TO CATEGORIZE THEM ALL
Software Engineering Bodies of Knowledge.
- SDLC 3.0: Beyond a Tacit Understanding of Agile, Mark Kennaley, 2010

7. THE ROLE OF THE BUSINESS ANALYST?
“Far from de-emphasizing the role,
agile methods... actually ask more of
business analysts than previous
methods…
…when agile methods are really
applied and not merely talked-
about, that is”
- Dec 9, 2008 4:33 PM by DN
In response to http://www.infoq.com/articles/agile-business-analyst-role by Shane Haste

8. AGILE REQUIRES ALL LEVELS…
to better share leadership and
assume the responsibility that goes with it
The team is responsible and accountable for their
actions; listen, cooperate, and collaborate
Adapting Configuration Management for Agile Teams - Mario E. Moreira, 2010

9. CHANGE IS DIFFICULT

10. SCRUM IS ONE OF THE AGILE METHODS
Includes (but not limited to) :
Scrum,
Extreme Programming (XP),
Dynamic Systems Development Method (DSDM),
Feature Driven Development (FDD),
Agile Unified Process (AUP).
Sprint •Agile
1 •Scrum

11. SCRUM IN A NUTSHELL!

12. SCRUM – WHAT PARTS APPLY TO ME
Same Principles Apply
Does not matter what methodology
Focus on the Current Iteration
Getting working software in front of the user quickly
Your pre-work may remain similar (BC, HLR)
But with less detail for all requirements
Identify the top priority functionality
(the PO does this)
Make sure you analyse it enough
Be ready to bring top priority into your first
sprint

13. RULE - NO CHANGES DURING A SPRINT
Change
Plan sprint durations around how long you can commit to
keeping change out of the sprint
Typically 2 weeks is long enough for most Product Owners
What if the “developers” say they want 3 week sprints?

14. ROLES IN SOFTWARE DEVELOPMENT...
“I'm not sure defining all these roles
help.
In my mind there are just two roles.
People who want software
and people who build it.”
- Dec 6, 2008 10:17 AM by PB
In response to http://www.infoq.com/articles/agile-business-analyst-role by Shane Haste

15. SCRUM – THE PRODUCT OWNER
Representing the customer
Understand the system – or can find out
Define the features of the product
Decide on release date and content
Be responsible for the profitability of the
product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as
needed
Accept or reject work results

16. SCRUM - THE TEAM
Typically 5-9 people
Cross-functional:
Analysts, developers, testers, user experience
designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Ideally, no titles but rarely a possibility
Membership should change only between
sprints

17. WHAT DOES CROSS FUNCTIONAL MEAN?
Reality is we all have our own specialty…
so live with it.
What work needs to be done?
analysis
development
testing
architecture, dba, dc
Testers can do some analysis etc
Analysts can do some testing etc
Primary goal is to get working software

18. IN SCRUM THE TEAM IS…
committed,
empowered,
self-organized
They can make the best decisions to move
forward…
because they are the closest to the challenges and
work to be accomplished
Empowerment does not mean leadership…
Its about having the ability to make the right
decisions at the right time and doing it
Have discussions, not change requests!

19. SO WHOSE BACON IS ON THE LINE?
THE BA IS NOW ONLY ONE OF THE TEAM
WHOSE BACON IS ON THE LINE

20. “DO SCRUM BY THE BOOK UNTIL
YOU GET GOOD AT IT
– THEN ADJUST”
-Mike Cohn

21. THE ROADMAP – LETS GET CLEAR
"What am I supposed to be doing on the team?“
Story Writing with Product Owner
Analysis of Product Backlog Items
Clarification with PO on Acceptance Criteria (AC)
Story prep for Grooming
Mocking up User Interface's (UI) with the PO
Clarifying and defining User Experience (UX) criteria with the PO / team.
Building Conditions of Satisfaction with the PO; building scenarios for
testing
Looking forward at releases and what must be in the next release.
Sprint •Agile Sprint •Analysis
1 •Scrum 2 •Stories

22. ANALYSIS HAPPENS – FOCUS ON THE SKILLS
I have been a BA (and always will be)
You know what I mean!
I am now learning to be a ScrumMaster and Agile
Coach
Its an ongoing process
So what have I seen that a Business Analyst can
actually do as part of an agile team to ensure the
practices of business analysis are not missed out
during the development process?
Don’t get bogged down in the detail too much. JDI

23. LET ME TAKE YOU THROUGH A TYPICAL DAY…
Take a look at the Burndown first thing
Mosey over to the scrum board
Have a standup with the team
Check in on confidence - just to get a feel of where we
are and if we're going to make it by the end of the sprint
Talk about the blockers
Diagnose any problems with the team
Go get things moving
Groom the Product backlog with the team and the
product owner
Let's play some poker
Run through some demo's with our product owner
Check things meet our team Definition of Done
Prep-just in time for our review
Show the business working software

24. THE SPRINT BACKLOG

25. THE GOOD THINGS I SEE…
The BA not working in isolation
The BA always in constant flux with product
owner, testers, developers, architects,
Not a lot of artifacts being maintained
No business requirements document updates
No functional spec changes
No change request matrix being updated
No time recording overhead
…
Just enough detail through conversations and
clarification and coordination amongst the team

26. WHAT THE BA’S TOLD ME…
“Just doing it is more fun”
“I enjoy seeing the users getting a piece of
functionality each sprint”
“More enjoyable”
“Easier to focus on the current work”
“Quicker than waterfall - don't have to wait 6
months to see something working”
“Clarifying things when we get to them”
“Not getting too ahead of ourselves”
“Producing working software quickly”
“Not working on functionality that won't be used”

27. WHAT’S CHANGED?
Before
The BA works with the business on the BR’s and
documents the Business Requirements Document
The BA also works on getting the BR Doc Signed Off
The BA also works on the Functional Specification
The BA also works on getting the FS signed off
The BA also does a bit of the PM’s work…
Sprint •Agile Sprint •Analysis
1 •Scrum 2 •Stories

28. STORY WRITING WITH PRODUCT OWNER (PO)
After
The BA works closely with the PO
Write clear User Stories that explain WHAT the PO wants
The BA uses their skills to elicit the requirements
The BA assists with UI and UX criteria with the PO
The BA helps document these against stories as
Acceptance Criteria and Conditions of Satisfaction
As a <user> I want <something> So that <I get to do this>

29. USER STORIES – THE DETAIL
Clarification with the PO on
Acceptance Criteria (AC)
Contains sufficient detail
Allows testers to start thinking of how
they are going to test the functionality
Allows coders to know more about “What”
they are supposed to be building
The testers start driving the code with
Tests (TDD)
Can be at a high level
Can be detailed
Conversations with the team

30. THE BA IS NOW FREE… TO USE THEIR SKILLS
The BA is in the team
Making sure the analysis is done
Check-ins with team
Works closely with the Tester in a Test Driven
Development environment
Focus is now on the Analysts skills, not on
documents and artifacts they produce
Focus is on utilizing the Analysts skills to
produce working software – value to the
customer

31. ACCEPTANCE CRITERIA
“THERE SHOULD ALWAYS BE A
CONVERSATION TO CLARIFY”
Analyst
Tester
Developer

32. MAINTAINING AND UPDATING THE
PRODUCT BACKLOG
Stories that do not provide sufficient detail in the
AC’s will need to be broken down into smaller
stories.
Analysis of this detail goes on during a sprint in
the background - Grooming
Getting ready for the next sprint or two
Working closely with the PO
Sprint •Agile Sprint •Analysis Sprint •Backlog
1 •Scrum 2 •Stories 3 •End

33. THE ELECTRONIC PRODUCT BACKLOG
(JIRA, TFS …)

34. STORY PREP FOR GROOMING
The BA helps ensure only prepped Stories are
brought to the Grooming session.

35. GROOMING THE PRODUCT BACKLOG
- WITH THE TEAM
Backlog Item Highest
Priority
We need these
Backlog Item
done in 2 weeks!
Backlog Item
Backlog Item
These aren’t
critical, but it Backlog Item
would be nice.
Backlog Item
Backlog Item
Not having these
Stories isn’t Backlog Item
Lower
hurting anybody.
Backlog Item Priority

36. PRODUCT BACKLOG GROOMING

37. Scenario – Sprint 19
• We are in to our 4th release of the software
• It is day 9 of our 19th Sprint (2 week long sprints)
• The team is feeling under pressure as they have
only completed 1 of the 7 stories they committed
to in sprint planning.
• There is no way everything will be done ready for
the review, which is tomorrow.
What happened?
• What could have caused the team to not meet what they
committed to?
• What have they learnt?
• What could they improve on in next sprint?

38. Retrospective – Sprint 19
IMPROVEMENTS:
• Clear ACs
• Better grooming
• PO clear on implications of story, complexity, after
some analysis from team
• Clear mockups showing what needs to be displayed
• PO has a clear understanding of technology
involved/complexity story brings to system
• The team wanted to Improve the Sprint planning
What happened?
• What did the team learn?
• What could they improve?

39. Sprint 20
• 9 out of 10 stories complete.
• Sprint 20 improved but most of the work was tidying up
the previous sprint. All stories except one completed
• BA was working with the PO closely
• BA was clear on their role in the team
• Grooming was getting better
• Focus on most important stories for the upcoming
sprint during grooming
• Team was able to task out story for upcoming sprint
• Team felt confident that stories were well thought out
and good amount of detail

40. Sprint 21 – Continued Success
• All stories complete (12/12),
• plus a stretch story (bonus) and all had integrated
testing.
• Grooming was being done well
• Had a lot clearer stories (better grooming prep)
• Because the team had worked closely with the PO
• BA had been on the team for 3 sprints now
• PO with BA’s help was bringing clear Stories, AC, and
screen mockups to the team sprint planning
• Everyone on the team seemed happier
• The business was really happy…
• Tell the world, and keep working on it.

41. “I believe the role of analysis
is vital, and that a good business
analyst is of benefit to any team.
However, the temptation for an
experienced analyst to slip back into
being a buffer between the IT team and
the customer,
enabling each to become lazy in
communicating with the other,
is a constant danger”
- Dec 8, 2008 4:35 AM by SP
In response to http://www.infoq.com/articles/agile-business-analyst-role by Shane Haste

42. THANK YOU
So your day as a Business Analyst on an agile
project has just got full!
Stephen Reed –
stephen@prestigeconsulting.co.nz
Sprint •Agile Sprint •Analysis Sprint •Backlog
1 •Scrum 2 •Stories 3 •End