Business analyst in agile projects
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Business analyst in agile projects



Business analyst in agile projects

Business analyst in agile projects



Total Views
Views on SlideShare
Embed Views



8 Embeds 29 7 6 6 5 2 1 1 1



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

Business analyst in agile projects Presentation Transcript

  • 1. Business Analyst in Agile Projects
    Agile Management Solutions
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 2. BA Traditional Activities
    Scope the System-Creation with stakeholders of a “business vision” of the project.
    Initial Requirements-Translating high level discussions with stakeholders into documents.
    Document the Business Needs- Create a document that the business can read.
    Document the Business Needs-Create a document that was a iterative process from the developers (questions, answers) that the business and developers can read.
    Technical Translation-Explain technical complexities to project stakeholders, such as architectural , infrastructure, code selection.
    Explain to Developers-Why is this project being created and why does the business think it should be created in this fashion.
    Explain to Business-What developers are doing and Why are they doing it this way.
    Schedules-Estimates and basis of the timeline
    Model Documentation-Business details documented as per domain and project.
    Communications-Between the business and development teams.
    Validation and Testing-Walk through, demos, documenting results.
    Stakeholder Representation-Liaison between teams for the project life-cycle.
    Politian -Liaison for entire organization and all teams involved in the project.
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 3. Common Project Problems
    Lack of Skills-Wrong people put into the role and they will never have the opportunity to gain the skills needed to thrive in the BA role.
    Too Much Influence-Some BA’s will try to influence the project, not the stakeholders and might play politics.
    Out of Date BA Skills-Trained on Cobol projects but working on object-oriented web projects.
    No Understanding of the Technology-They need at least minimal understanding of the technology that the project is going to be developed on.
    Communication Barrier-BA’s that act as a barrier instead of a conduit for the project.
    Over Analyzing-Focusing on their specialties and what they are comfortable with , not on all the tasks involved in the project. EX:Time spent on documentation and little spent on modeling.
    Communication-Poor feedback between team members for the length of the project life-cycle.
    Anti-Team Creation-Using only one conduit to go through does not create well running teams.
    Limiting Skill Sets-If team members only go though the BA then developers and other teams members never get the chance to improve their communications skills by dealing with the business.
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 4. Re-Thinking the BA Role Agile Style
    Co-located and Team Generalists
    Team members working side by side and team members that have one or more technical specialties and are striving to gain new skills.
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 5. Agile Style Success
    Agile Estimation-Includes prioritization of requirements.
    Agile Communications-Face-to-face discussion with team members.
    Project Stakeholders-Team members like to work closely with business.
    Iterative Analysis-Estimating and Design efforts placed on a team as a whole.
    Incremental Analysis-No need to build the systems all at once.
    Exploration Analysis- Understand the need for your system then communicate efficiently with the entire team.
    Agile Documentation-Just good enough not perfect just good enough.
    Disciplined Change Management-Each integration implement the highest proity items.
    Modeling-Use simple tools (flip charts, boards) to make it easier for stakeholders to participate.
    Terminology-Use universal terminology through out the entire life-cycle.
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 6. Conclusion
    Agile means self-organization, test driven development, collaboration teams, face to face communications and teams based on IT generalists.
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.
  • 7. Paul Gravinahas been working in the Information Technology arena for the past 15 years. He has worked in a variety of roles related to technology such as Quality Assurance, Business Analyst and Project Management. He has been certified as a Six Sigma Green Belt and is the owner of Agile Management Solutions an IT contracting firm. Paul also contributes to the blog Agile Management Solutions
    © 2010 Agile Management Solutions. (AMS LLC) All rights reserved.