The Agile Business Analyst

1. The Agile Business Analyst Bob Schommer, CSP, PMP, MCTS Senior Project Manager Skyline Technologies, Inc.

2. Agile Business Analyst Role • Delegate for Product Owner • Groomer of the Product Backlog • Value driven • Stays 1-2 sprints ahead of the team • Release planning • Trawls for user story requirements at appropriate level of detail • Definer of “Done” • Represents interests of software users during development

3. Value Driven • User stories focus on the user, what they want to do and why they want to do it • Other techniques do not consider business value • “The system shall…” • Use cases • Avoids elaboration of low priority features that may never be developed • A properly prioritized Product Backlog ensures delivery of high priority features

4. User Stories – The Three C’s • Card • A written description used for • Planning • As a reminder • Conversation • Discussions about the story that flesh out details • Confirmation • Tests that convey and document details • Used to determine when a story is complete A reminder to have a conversation

5. Trawl – Don’t “Elicit”, “Capture” or “Collect” • Consider this as a new metaphor for defining requirements • Different sized nets for different sized stories • Not all requirements are worth catching • Some die • You won’t catch everything • You will likely catch some debris • Skill is required

6. Techniques • User interviews • Know the difference between a solution and the problem • Questionnaires • Effective to collect data about stories you already have • Observation • Watch how your software is being used

7. Techniques • Story-Writing Workshops • Rapid way to write many stories • Involve all team members • Combine with a low-fidelity prototype • Focus is on screen flow – not actual screens or fields • Ask questions that will help identify new stories: • What will user likely do next? • What mistakes could they make? • What could confuse them? • What additional information might they need? • Throw the prototype away when done writing stories

8. Guidelines for Good User Stories • Start with goal stories for each user role • Decompose from here • “Slice the cake” • Write stories that will deliver end-to-end functionality • Do not split large stories along technical lines • Write closed stories that can be accomplished • Can be finished by achieving a meaningful goal • “Done” is clearly understood • Create constraint story cards • For documenting non-functional requirements • Write “constraint” on card • Do not estimate • Write acceptance tests when appropriate

9. Guidelines for Good User Stories • Keep the UI out as long as possible • Causes the solution to interfere with understanding requirements • UI stories will be defined eventually – but not in early iterations • Exception – the UI is important to the success of the product • Not all requirements need to be user stories • Screen shots are appropriate to define the UI • User stories may not be appropriate for some interface specifications • Write for one user • Write in an active voice • Ideally, the customer should write

10. Other Considerations • To automate or not? • Should user stories be retained? • If using software, there is no reason to discard • Satisfaction of ripping up a completed story vs. keeping it in case it is needed it later • If in doubt, keep them • Bugs as user stories? • Cards should be created for user story sized bugs • Consolidate small bugs together on one card if estimates are very small

11. You Still Need Customer Involvement Regardless of the methodology you use, you will not be successful without customer participation. • Agile/Scrum is not a “silver bullet” • If customers are not participating, be brave and stop the project • You cannot be successful • Your customer will not be happy

12. Your Turn – Time for Discussion