How Business Analysts can re-invent themselves for an Agile world Skeptic al? Confuse d? Practic ing?
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
Related Documents
