• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Steve Gara Presentation   Sgbizservices

Steve Gara Presentation Sgbizservices



Agile Business Analysis \'101\'

Agile Business Analysis \'101\'



Total Views
Views on SlideShare
Embed Views



2 Embeds 10

http://www.linkedin.com 6
https://www.linkedin.com 4



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • ----- Forwarded message from ronjeffries@XProgramming.com ----- Date: Wed, 24 Aug 2005 07:20:58 -0400 From: Ron Jeffries Reply-To: agileprojectmanagement@yahoogroups.com Subject: Re: [APM] Agile documentation To: agileprojectmanagement@yahoogroups.com On Wednesday, August 24, 2005, at 1:02:25 AM, Ronsley Vaz wrote: > Was just wondering for academic reasons whether there is any > documentation that results from an agile process? If there is, where > can I find a list or a resource page that I can read up about it. Here's how I look at it: An agile team (note that I'm not saying "process") will produce two main kinds of documentation: what they need to do their work, and what the product needs as a deliverable. First, the team will produce any documentation that they themselves need. This might include pictures of the product design, sketches of how it looks, descriptions of some key aspects of the product, graphs of key project metrics. Second, they will produce any documentation that the product owner / customer / requirements giver asks for. This might include manuals, maintenance-oriented design materials, external status reports, progress charts. The words "need" and "asked for" are crucial: the team will not as a matter of course produce some specific document that we might imagine. They'll produce it only if they need it, or if it is asked for, as a project deliverable, by the product owner. For a bit more on this, use the search function on xprogramming.com to search for documentation. There is a magical index page on the subject, but I just noticed that it seems to be broken. Search will find some articles for you, though. Ron Jeffries www.XProgramming.com Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. --Albert Einstein

Steve Gara Presentation   Sgbizservices Steve Gara Presentation Sgbizservices Presentation Transcript

  • 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
  • Agenda
    • What does a Business Analyst really do? (BABOK)
    • Agile principles “101” for BA’s
    • Questions?
  • 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.
  • Agile Principles – Hot concept
    • Collaborate
    • Iterate (repeat)
    • Serve the Team
    • Consider Context
    • Reflect and Adapt (Flexibility)
    • Deliver Value
  • 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)
  • 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
  • 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
  • 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.)
  • 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 .
  • 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)
  • 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
  • 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.”
  • 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
  • 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>
  • 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
  • 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
  • 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
  • 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
  • Solution Assessment and Validation
    • Business solution vs technical solution
    • Release planning
    • Supporting testing
  • 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.
  • 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
  • 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>
  • 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
    • 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
  • 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.
  • 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