DEMYSTIFYING THE ROLE

•Agile

•Scrum

Sprint 1

•Analysis

•Stories

Sprint 2

•Backlog

•End

Sprint 3

DEMYSTIFYING THE ROLE

OF THE BA ON AGILE

SOFTWARE DEVELOPMENT PROJECTS

(USING SCRUM)

Stephen Reed

BA and ScrumMaster

•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 committedto in sprint planning.

•There is no way everything will be done ready for

Scenario – Sprint 19

•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?

WHAT COULD WE HAVE DONE BETTER?

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 so that the project team can evolve the customer

need (a.k.a. the product).

-Mario E. Moreira, 2010

CM Expert

•Agile

•Scrum

Sprint 1

THERE IS AN AGILE MANIFESTO

� 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.

http://agilemanifesto.org/

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?

SOMEONE TRIED TO CATEGORIZE THEM ALL

Software Engineering Bodies of Knowledge.

- SDLC 3.0: Beyond a Tacit Understanding of Agile, Mark Kennaley, 2010

THE ROLE OF THE BUSINESS ANALYST?

“Far from de-emphasizing the role, agile methods... actually ask more of

business analysts than previous methods… 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

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

CHANGE IS DIFFICULT

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), � Feature Driven Development (FDD),

� Agile Unified Process (AUP).

•Agile

•Scrum

Sprint 1

SCRUM IN A NUTSHELL!

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

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?

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 PBIn response to http://www.infoq.com/articles/agile-business-analyst-role by Shane Haste

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

SCRUM - THE TEAM

�Typically 5-9 people

�Cross-functional:

� Analysts, developers, testers, user experience designers, etc.

� Members should be full-time� 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

WHAT DOES CROSS FUNCTIONAL MEAN?

� Reality is we all have our own specialty…

� so live with it.

� What work needs to be done?

� analysis� 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

IN SCRUM THE TEAM IS…

� committed,

� empowered,

� self-organized

� They can make the best decisions to move � 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!

SO WHOSE BACON IS ON THE LINE?

THE BA IS NOW ONLY ONE OF THE TEAM

WHOSE BACON IS ON THE LINE

“DO SCRUM BY THE BOOK UNTIL

YOU GET GOOD AT IT

– THEN ADJUST”– THEN ADJUST”-Mike Cohn

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� 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.

•Analysis

•Stories

Sprint 2

•Agile

•Scrum

Sprint 1

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� 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

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 � 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

THE SPRINT BACKLOG

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 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

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”� “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”

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 works on getting the FS signed off

� The BA also does a bit of the PM’s work…

•Analysis

•Stories

Sprint 2

•Agile

•Scrum

Sprint 1

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 � 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>

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 functionalitythey 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

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 environmentDevelopment 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

ACCEPTANCE CRITERIA

“THERE SHOULD ALWAYS BE A

CONVERSATION TO CLARIFY”

AnalystAnalyst

Tester

Developer

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 - Groomingthe background - Grooming

� Getting ready for the next sprint or two

� Working closely with the PO

•Analysis

•Stories

Sprint 2

•Agile

•Scrum

Sprint 1

•Backlog

•End

Sprint 3

THE ELECTRONIC PRODUCT BACKLOG

(JIRA, TFS …)

STORY PREP FOR GROOMING

� The BA helps ensure only prepped Stories are

brought to the Grooming session.

GROOMING THE PRODUCT BACKLOG

- WITH THE TEAM

Backlog Item

Backlog Item

Backlog Item

Highest

PriorityWe need these

done in 2 weeks!

Backlog Item

Backlog Item

Backlog Item

Backlog Item

Backlog Item

Backlog Item

Lower

Priority

These aren’t

critical, but it

would be nice.

Not having these

Stories isn’t

hurting anybody.

PRODUCT BACKLOG GROOMING

•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 committedto in sprint planning.

•There is no way everything will be done ready for

Scenario – Sprint 19

•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?

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

Retrospective – Sprint 19

• 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?

• 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•

Sprint 20

•• 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

• 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

Sprint 21 – Continued Success

• 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.

“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 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

THANK YOU

� So your day as a Business Analyst on an agile

project has just got full!

� Stephen Reed –

stephen@prestigeconsulting.co.nzstephen@prestigeconsulting.co.nz

•Analysis

•Stories

Sprint 2

•Agile

•Scrum

Sprint 1

•Backlog

•End

Sprint 3