How Business Analysts Can Re Invent Themselves For An Agile World


Published on

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

Comments very welcome.

Published in: Business, Technology
1 Comment
  • this was quite not helpful...i imagine this could only be better with audio...
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How Business Analysts Can Re Invent Themselves For An Agile World

  1. 1. Skeptical?<br />Confused?<br />Practicing?<br />How Business Analysts can re-invent themselves for an Agile world<br />
  2. 2. Skeptical?<br />Confused?<br />Practicing?<br />Who are you?<br />
  3. 3. Let’s start with some basics…<br />
  4. 4.
  5. 5. 2009<br />24%<br />44%<br />32%<br />Chaos report from the Standish Group:<br />
  6. 6. Laura Brandau<br /><br />
  7. 7. Laura Brandau<br /><br />
  8. 8.
  9. 9. Shippable Product<br />Story Points<br />User stories<br />Product Backlog<br />Product Roadmap<br />Up front requirements?<br />Velocity<br />On the wall<br />Product Owner<br />Team<br />Scrum master<br />Sprint Planning<br />Daily <br />Stand-ups<br />Product review<br />Retrospective<br />Sprints<br />
  10. 10. C.R.A.C.K. Analysts (Barry Boehm, Richard Turner)<br />Collaborative <br />Representative <br />Accountable<br />Committed <br />Knowledgeable<br />
  11. 11. the “product owner” role<br />Image used with permission from EMC<br />
  12. 12. the “product owner” role<br />Dean Leffingwell, ‘Scaling Software Agility’<br />
  13. 13. Go visit Paul’s blog at<br />It’s not about being a translator<br />
  14. 14. User Stories<br />INVEST<br />Independent, Negotiable, Valuable, Estimable, Sprint-able, Testable<br />(or SMART)<br />As a <br />mortgage holder <br />I want <br />my lender to tell me when there is a better deal available, <br />So that<br />I can save money<br />4SP<br />
  15. 15. Product Backlogs<br />Use a list<br />(Use other techniques also)<br />(But use a list)<br />
  16. 16. 2<br />5<br />
  17. 17. Story Points<br /><ul><li>Relative size
  18. 18. Proximity
  19. 19. Planning Poker
  20. 20. Independent from who does the work</li></li></ul><li>What’s the fascination with post-it notes?<br />
  21. 21. Put stuff on the wall<br />“Information radiators”<br />
  22. 22.
  23. 23. Constant interaction with the dev team<br />
  24. 24. That’s the end of the basics<br />How do we do it in practice?<br />
  25. 25. Managing requirements<br /><ul><li>Industry averages 2-4% per month
  26. 26. This shows about 4% from a nominal baseline point</li></ul>Requirements baseline point<br />
  27. 27. Velocity<br /><ul><li>“Done”
  28. 28. Vertical slices of functionality</li></li></ul><li>Release planning<br /><ul><li>3 months requirements ramp up
  29. 29. Ongoing requirements management
  30. 30. Forecast done with velocity</li></li></ul><li>The journey is as important as the destination<br />
  31. 31. Not every BA can be a product owner<br />
  32. 32. BA and QA<br />QA is critically important in an iterative project. A BA may well be fully engaged in QA activities.<br />
  33. 33. Product “Owner”<br />Making calls, Business Value, Balancing stakeholder needs, Selling the solution.<br />
  34. 34. “Business” analysts<br />“Systems” Analysts<br />
  35. 35. 1<br />1<br />1<br />
  36. 36. Continuous improvement<br />Get things wrong and improve<br />
  37. 37.
  38. 38. Make sense?<br />Craig Brown<br /><br />This work is licenced under the Creative Commons Attribution 2.5 Australia License. To view a copy of this licence, visit or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.<br />
  39. 39.
  40. 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:<br />Individuals and interactions <br />The Agile Manifesto<br />processes and tools<br />over<br />Working software<br />comprehensive documentation<br />over<br />Customer collaboration<br />contract negotiation<br />over<br />Responding to change<br />following a plan<br />over<br />That is, while there is value in the items on the right, we value the items on the left more<br />
  41. 41. Principles behind the Agile Manifesto<br />Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. <br />Welcome changing requirements, even late in development. Agile processes harness change for the customer&apos;s competitive advantage.<br />Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. <br />Business people and developers must work together daily throughout the project. <br />Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. <br />The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. <br />Working software is the primary measure of progress. <br />Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. <br />Continuous attention to technical excellence and good design enhances agility. <br />Simplicity--the art of maximizing the amount of work not done--is essential. <br />The best architectures, requirements, and designs emerge from self-organizing teams.<br />At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.<br />