Career Forums

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Business Analyst Deliverables in Agile
Previous Previous
 
Next Next
New Post 8/8/2018 5:26 PM
User is offline Meta BA
19 posts
9th Level Poster


Business Analyst Deliverables in Agile 

I started my career as a business analyst in a very waterfall organization and my deliverables were quite clear and defined as a part of the SDLC. The heavy hitter being the requirements document,  business requirement document, requirements package, or whatever you might call it. The largest and established organization typically have a template to follow that includes where to include process, the attributes per requirement, etc. 

In agile, the less document heavy development cycle, things are different. In my experience two primary activities of a business analyst in agile that actually provide value. First, is the keeper of the functionalities. Things will be changing all the time and user stories are not a great way to keep track of how an application works. Keeping track of the functionalities, business rules, etc provide a lot of value. Secondarily, I function as a conduit of communication and shared understanding. Whether it is by process models, meeting facilitation, user cases, or whatever, I constantly get to work my BA muscles to help drive to the best solutions.

For a longer and more visual explanation Business Analyst Deliverables Agile vs Waterfall 

 
New Post 8/28/2019 7:38 PM
User is offline Leslie Munday
4 posts
No Ranking


Re: Business Analyst Deliverables in Agile 
A deliverable is something you produce that is used by someone else. If there is no recipient who is gong to gain benefit from your deliverable, then why are you making it? With that in mind waterfall gets a bad rep by putting all eggs (requirements, analysis, business needs, etc) into a single basket (requirements package) that is delivered to an audience where only 80% of the people are interested in 20% of its content. (I picked on those numbers at random, but I hope they make my point.) As a BA on an agile project, I get to deliver only content that is used, only the people that want it. I still do the same work; elicit requirements, analyze requirements, build models, etc, but I only deliver user stories to people that want those user stories, when they want those user stories. In summary, the difference to a BA between Waterfall and Agile, is similar to that of a developer. You write the same code, but you write only what is wanted at this time, for the people that want it it at this time. You might think of the difference as breaking down your Huge Requirements Documentation package into user story sized chunks and only working on the highest priority chunks at any time. P.S. I liked the video, but the presenter forgot to mention that a deliverable needs a recipient.
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  Business Analyst Deliverables in Agile

 






 

Copyright 2006-2024 by Modern Analyst Media LLC