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

Like this? Share it with your network

Share

Business analyst in agile projects

on

  • 1,754 views

Business analyst in agile projects

Business analyst in agile projects

Statistics

Views

Total Views
1,754
Views on SlideShare
1,725
Embed Views
29

Actions

Likes
0
Downloads
39
Comments
0

8 Embeds 29

http://agilemanagementsolutions.com 7
http://agilemanagementsolutions.blogspot.com 6
http://agilemanagementsolutions.blogspot.ca 6
http://www.slideshare.net 5
http://agilemanagementsolutions.blogspot.in 2
http://agilemanagementsolutions.blogspot.gr 1
http://agilemanagementsolutions.blogspot.co.uk 1
http://agilemanagementsolutions.blogspot.pt 1
More...

Accessibility

Categories

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.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
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.