How Business Analysts Can Re Invent Themselves For An Agile World

Skeptical?
Confused?
Practicing?
How Business Analysts can re-invent themselves for an Agile world

Skeptical?
Confused?
Practicing?
Who are you?

Let’s start with some basics…

2009
24%
44%
32%
Chaos report from the Standish Group: www.standishgroup.com

Laura Brandau
Bridging-the-gap.com

Shippable Product
Story Points
User stories
Product Backlog
Product Roadmap
Up front requirements?
Velocity
On the wall
Product Owner
Team
Scrum master
Sprint Planning
Daily
Stand-ups
Product review
Retrospective
Sprints

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” role
Dean Leffingwell, ‘Scaling Software Agility’

Go visit Paul’s blog at www.cleverworkarounds.com
It’s not about being a translator

User Stories
INVEST
Independent, 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 money
4SP

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

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 basics
How do we do it in practice?

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

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

The journey is as important as the destination

Not every BA can be a product owner

BA and QA
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

Continuous improvement
Get things wrong and improve

Make sense?
Craig Brown
www.betterprojects.net
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.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions
The Agile Manifesto
processes and tools
over
Working software
comprehensive documentation
over
Customer collaboration
contract negotiation
over
Responding to change
following a plan
over
That is, while there is value in the items on the right, we value the items on the left more

Principles behind the Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://www.betterprojects.net	266
https://gilsavage.backpackit.com	174
http://www.slideshare.net	18
http://analizabusiness.com	9
http://www.lmodules.com	2
http://translate.googleusercontent.com	1
http://www.brijj.com	1
http://www.jjicky.blogspot.com	1
http://www.craigwbrown.net	1
http://127.0.0.1:8795	1
http://jjicky.blogspot.com	1

How Business Analysts Can Re Invent Themselves For An Agile World

by Craig Brown on Sep 23, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

11 Embeds 475

Statistics

How Business Analysts Can Re Invent Themselves For An Agile World — Presentation Transcript