The document discusses incorporating Agile methodologies into business analysis. It provides an overview of Agile principles, the Agile Unified Process methodology, and how business analysts can apply Agile practices to their work. Specifically, it emphasizes focusing on business value, understanding problems before solutions, using appropriate tools for elicitation and documentation, and facilitating regular delivery of working software.

1. The Agile Business Analyst (incorporating Agile Methodologies into Business Analysis) Steven J. Gara, MS, PHR, CBAP Founding Member of South Florida IIBA and President/Owner/Partner: SGBIZSERVICES, INC and LeverForce.com

2. Agenda What does a Business Analyst really do? (BABOK) Agile principles “101” for BA’s What is SGBIZSERVICES.COM? Questions?

3. Conditions of Satisfaction Explain the key principles of Agile in terms relevant to “the BA world” Identify agile practices that fit into each of the six knowledge areas of the BABOK Explore how certain agile practices may be appropriate for use in non agile projects.

4. Agile Principles – Hot concept Collaborate Iterate (repeat) Serve the Team Consider Context Reflect and Adapt (Flexibility) Deliver Value

5. Agile Unified Process Methodology “101” The serial nature of Agile UP is captured in its four phases : http://www.ambysoft.com/unifiedprocess/agileUP.html Inception . The goal is to identify the initial scope of the project, a potential architecture for your system, and to obtain initial project funding and stakeholder acceptance (sign offs are critical). Elaboration . The goal is to prove the architecture of the system. Construction . The goal is to build working software on a regular, incremental basis which meets the highest-priority needs of your project stakeholders. Transition . The goal is to validate and deploy your system into your production environment. (Overall goal is to deliver incremental releases over time rather than one large release as is usual)

6. The Agile BA Understands most available tools Uses the appropriate tool Knows both business and technology Language Coach, not a translator Champions Business Value Facilitates the definition of problems and description of solutions and offers plenty of options – Flexibility and Adaptability

7. Enterprise Analysis Business Value A project creates business value when it increases or protects cash flow, profit, or Return on Investment (“show me the $$$”) Should be presented as a model rather than statements (Vision) Inputs to business value models become constraints on projects Success is measured against business value

8. Planning and Management Plan in iterations Describe solution at high level in beginning of project (placeholders) During each iteration dive deeply for a specific area of functionality (i.e. order processing, for instance) Maintain and add to product/system wide models such as conceptual domain model, process model Functionality based plans instead of task based plans (what is the 1 st most important function/behavior of system, 2 nd most important, etc.)

9. Planning and management Scope and change Scope is realized by a prioritized feature list Change is realized by additions to, subtractions from, or reprioritization of feature list Progress is measured in terms of business value delivered thru running tested features .

10. Elicitation Define a Common Language Stakeholders and development team need to speak the same language Jointly develop object model/data model/class model with developers BA facilitates this development Data model is progressively completed throughout the project (Iteratively) Data dictionary (metadata) is also a key part of this effort (i.e. Data Mapping)

11. Elicitation Multiple Models There is no one way to represent facts about the solution, case by case basis When working with stakeholders to define solution utilize different models at the same time to establish a complete picture Parallel, not sequential Pick the right model for the job

12. Analysis and Documentation Goal is to define the solution Know your audience (who is using the requirements) One potential format – User stories – examples: “ As a customer representative, I can search for my customers by their first and last name. “ “ As a non-administrative user, I can modify my own schedules but not the schedules of other users.”

13. Analysis and Documentation Know your audience Know for whom you are describing the solution ASK THEM how they want to see it documented (Counterintuitive – put onus on the client, not you!) Be willing to revise approach based on feedback from audience (Be Flexible!) Pick the appropriate approach for their needs

14. Analysis and Documentation User Stories One approach to documenting functional requirements Add detail in terms of acceptance tests Simple format adds discipline to requirements format As a <User Type> I want <feature> So that <business value> Given <Pre Conditions> When <Condition> Then <Resulting Action>

15. Analysis and Documentation “Barely Sufficient” Documentation Documents team needs to do work Note team , not process Low tech tools (Whiteboard, post it notes) Use as a communication aid (not the sole form of communication) Documents customer asks for Product deliverables (Manuals, materials to support maintenance, etc) Tracked along with all other requirements

16. Communication Show Me! Gain approval thru showing bits of working functionality at regular intervals - meetings Benefit of iterative approach is the delivery of working software every 2 – 4 weeks Stakeholders find it easier to provide feedback after using software vs looking at documents (Visual and Interative is “name of the game”) Utilize this opportunity to reflect and adapt approach and solution design

17. Communication The BA as Language Coach BA should help developers and stakeholders speak the common language – develop common acronyms, glossary When acting as “translator”, BA applies their own filters to the message – not good Use data modeling tools to establish the common language discussed before

18. Communication A word on reviews and signoffs First level of review – planning meeting Second level of review – end of iteration demo Signoffs replaced by team agreement on iteration plan and release plan

19. Solution Assessment and Validation Business solution vs technical solution Release planning Supporting testing

20. Solution Assessment and Validation Business solution/technical solution Restatement: Requirements describe the solution to the business problem (make sure the client understands the requirements and signs off so no bad surprises) Many different options/paths for realizing the business solution technically (Web/API), Mobile App, etc.

21. Solution Assessment and Validation Release planning Develop high priority functionality first (and see benefit from it) Prioritize functionality based on delivery of business value (let stakeholders “hash out” priorities and create a list) – CIO and Managers Group functionality in iterations and releases based on themes

22. Solution Assessment and Validation Supporting testing Write requirements as tests (Test use cases) Use Case story example: Given <Pre Conditions> When <Condition> Then <Resulting Action>

23. Things to Remember Focus on business value Understand the problem before working on a solution Expand your toolkit – not every problem is a nail. Requirements describe the business solution and are not an end themselves Be a Language Coach, not a translator

24. About SGBIZSERVICES.COM We are a locally based “conglomerate” that includes many different facets of business. I work with another fellow CBAP’er, Larry Velarde and our focus is Business Analysis, Project Management and Business Intelligence however we are involved in many diverse services, including Tax Liens, Notary Services, etc. Inventor of an enhanced appliance (Patent Pending) Title of Invention: 3-IN-1 PORTABLE BEVERAGE CHILLER AND WARMER (Works via USB, Battery and Traditional electric adapter for car) Inventor Information for USPTO #: 12/276457: GARA, STEVE Published White Paper: The Integration of Six Sigma with Business Analysis to achieve desired results (in a project) http://www.docstoc.com/profile/sgara/ Writer/Commentator for local Business and Industry on Examiner.com

25. Steven J. Gara Steven J. Gara is a multi-faceted business professional with a wide array of skills and experience in a variety of industries including Software, Entertainment (including being a musician), Travel, Banking, Insurance and Tax Lien investments. Educationally, he holds a Bachelor’s Degree from Temple University and a Master’s Degree from Cornell University. He has over a total of 15 years of experience combined in Human Resources and Information Technology consulting, has an entrepreneurial personality and a creative side that allows “thinking out of the box” for any given issue. The ability to think creatively and to step back and see the bigger picture and research all the facets of a given issue is what sets him and the company apart from others and his experience in Six Sigma Principles also helps clients to maximize their profits and minimize losses.

26. Questions? Steven J Gara, MS, PHR, CBAP Business Analyst, Writer, Inventor [email_address] http://www.sgbizservices.com http://www.examiner.com/x-6457-Miami Business-and-Industry-Examiner