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

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…

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

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

18. Proximity

19. Planning Poker

21. Put stuff on the wall “Information radiators”

23. Constant interaction with the dev team

24. That’s the end of the basics How do we do it in practice?

26. This shows about 4% from a nominal baseline pointRequirements baseline point

29. Ongoing requirements management

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

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.

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.