• Like
How Business Analysts Can Re Invent Themselves For An Agile World
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

How Business Analysts Can Re Invent Themselves For An Agile World

  • 3,439 views
Published

a presentation on how a business analyst can fit themselves into an agile/scrum project. …

a presentation on how a business analyst can fit themselves into an agile/scrum project.

Comments very welcome.

Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • this was quite not helpful...i imagine this could only be better with audio...
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
3,439
On SlideShare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
376
Comments
1
Likes
13

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Skeptical?
    Confused?
    Practicing?
    How Business Analysts can re-invent themselves for an Agile world
  • 2. Skeptical?
    Confused?
    Practicing?
    Who are you?
  • 3. Let’s start with some basics…
  • 4.
  • 5. 2009
    24%
    44%
    32%
    Chaos report from the Standish Group: www.standishgroup.com
  • 6. Laura Brandau
    Bridging-the-gap.com
  • 7. Laura Brandau
    Bridging-the-gap.com
  • 8.
  • 9. 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
  • 10. C.R.A.C.K. Analysts (Barry Boehm, Richard Turner)
    Collaborative
    Representative
    Accountable
    Committed
    Knowledgeable
  • 11. the “product owner” role
    Image used with permission from EMC
  • 12. the “product owner” role
    Dean Leffingwell, ‘Scaling Software Agility’
  • 13. Go visit Paul’s blog at www.cleverworkarounds.com
    It’s not about being a translator
  • 14. 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
  • 15. Product Backlogs
    Use a list
    (Use other techniques also)
    (But use a list)
  • 16. 2
    5
  • 17. Story Points
    • Relative size
    • 18. Proximity
    • 19. Planning Poker
    • 20. Independent from who does the work
  • What’s the fascination with post-it notes?
  • 21. Put stuff on the wall
    “Information radiators”
  • 22.
  • 23. Constant interaction with the dev team
  • 24. That’s the end of the basics
    How do we do it in practice?
  • 25. Managing requirements
    • Industry averages 2-4% per month
    • 26. This shows about 4% from a nominal baseline point
    Requirements baseline point
  • 27. Velocity
    • “Done”
    • 28. Vertical slices of functionality
  • Release planning
    • 3 months requirements ramp up
    • 29. Ongoing requirements management
    • 30. Forecast done with velocity
  • The journey is as important as the destination
  • 31. Not every BA can be a product owner
  • 32. BA and QA
    QA is critically important in an iterative project. A BA may well be fully engaged in QA activities.
  • 33. Product “Owner”
    Making calls, Business Value, Balancing stakeholder needs, Selling the solution.
  • 34. “Business” analysts
    “Systems” Analysts
  • 35. 1
    1
    1
  • 36. Continuous improvement
    Get things wrong and improve
  • 37.
  • 38. 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.
  • 39.
  • 40. 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
  • 41. 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.