How Business Analysts Can Re Invent Themselves For An Agile World

How Business Analysts can

re-invent themselves for an

Agile world

Skeptical? Confused? Practicing?

Who are you?

Skeptical? Confused? Practicing?

Let’s start with some basics…

7%

13%

16%

19%

45%

Utility of requirementAlways used 7%Often used 13%Sometimes used 16%Seldom used 19%Never used 45%

Source: Standish Group study, 2002.

2009

24% 44% 32%

Chaos report from the Standish Group: www.standishgroup.com

Laura BrandauBridging-the-gap.com

Laura BrandauBridging-the-gap.com

Shippable Product

Product Backlog

Product Roadmap

Product Owner Team Scrum master

Sprint Planning

Daily Stand-ups

Product review Retrospective

Sprints

Story PointsUser stories

Velocity

Up front requirements?

On the wall

C.R.A.C.K. Analysts

(Barry Boehm, Richard Turner)

Collaborative

Representative

Accountable

Committed

Knowledgeable

the “product owner” role

Image used with permission from EMC

the “product owner” roleDean Leffingwell, ‘Scaling Software Agility’

Product Owner

Ensure team is pursuing a

common vision

Establish priorities to track business

value

Act as ‘the customer’ for

developer questions

Work with product management to

plan releases

Plan, elaborate & accept

user stories and iterations

Technical: understand and

prioritize refactoring and infrastructure

Go visit Paul’s blog at www.cleverworkarounds.com

It’s not about being a translator

User StoriesINVESTIndependent, Negotiable, Valuable, Estimable, Sprint-able, Testable

(or SMART)

As a

mortgage holder

I want

my lender to tell me

when there is a better

deal available,

So that

I can save money4SP

Product BacklogsUse a list

(Use other techniques also)(But use a list)

2 5

Story Points• Relative size• Proximity• Planning Poker• Independent from who does the work

What’s the fascination with post-it notes?

Put stuff on the wall“Information radiators”

Constant interaction with the dev team

THAT’S THE END OF THE BASICSHow do we do it in practice?

1/1/0

9

11/1/0

9

21/1/0

9

31/1/0

9

10/2/0

9

20/2/0

9

2/3/0

9

12/3/0

9

22/3/0

9

1/4/0

9

11/4/0

9

21/4/0

9

1/5/0

9

11/5/0

9

21/5/0

9

31/5/0

9

10/6/0

9

20/6/0

9

30/6/0

9

10/7/0

9

20/7/0

9

30/7/0

9

9/8/0

9

19/8/0

9

29/8/0

9

8/9/0

9

18/9/0

9

28/9/0

9

8/10/0

9

18/10/0

9

28/10/0

9

7/11/0

9

17/11/0

9

27/11/0

9

7/12/0

9

17/12/0

9 -

50

100

150

200

250

300

Story Points

Story Points Polynomial (Story Points)

Managing requirements• Industry averages 2-4% per month• This shows about 4% from a nominal baseline point

Requirements baseline point

Velocity• “Done”• Vertical slices of functionality

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 -

5

10

15

20

25

30

Velocity

Velocity Average Velocity Recent Average Velocity

Release planning• 3 months requirements ramp up• Ongoing requirements management• Forecast done with velocity

1/1/09 27/1/09 22/2/09 20/3/09 15/4/09 11/5/09 6/6/09 2/7/09 28/7/09 23/8/09 18/9/09 14/10/09 9/11/09 5/12/09 -

50

100

150

200

250

300

Conservative forecast Likely forecast Story Points Cumulative done

The journey is as important as the destination

Not every BA can be a product owner

BA and QA

Not started In Progress Done

QA is critically important in an iterative project. A BA may well be fully engaged in QA activities.

Product “Owner”Making calls, Business Value, Balancing stakeholder needs, Selling the solution.

“Business” analysts “Systems” Analysts

11

1

Continuous improvementGet things wrong and improve

Make sense?

This work is licenced under the Creative Commons Attribution 2.5 Australia License. To view a copy of this licence, visit http://creativecommons.org/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

Craig Brownwww.betterprojects.net

Individuals and interactions

That is, while there is value in the items on the right, we value the items on the left more

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

The Agile Manifesto

processes and tools

Working software comprehensive documentation

Customer collaboration contract negotiation

Responding to change following a plan

over

over

over

over

Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.