The Role of a Business Analyst in an Agile Project

The role of a Business Analyst in an Agile project is not well-defined just as there is no defined role for a Project Manager on an Agile project. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.

The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects. I recently had to create a job description for hiring a BA on an agile project – here’s what I came up with as the primary skills needed:

  1. Analyzing a broadly-defined area and using functional decomposition to define high-level epics and stories to create a well-organized, value-driven framework to provide the required business value in the Product Backlog.If the stories and epics follow a logical functional hierarchy it provides a mechanism for better understanding the relationship of the stories and epics to each other and for satisfying overall business goals.
  2. Writing individual stories that are very clear and concise and are easy to understand and implement by the development team.Writing effective user stories is a skill that is often taken for granted. What is often overlooked in good stories is the “why” or the “so that” clause that expresses the business value the story is intended to provide. A good BA can provide that perspective that is difficult for a developer to provide.
  3. Identifying related user stories and epics, grouping them into themes as necessary and documenting the interrelationship and associated business process flows as necessary.The interrelationship of user stories and epics should be well-understood and the implementation of stories across different functional areas may require some planning and coordination so that they are consistently implemented. This overall framework can provide a mechanism for easily identifying any inconsistencies and/or missing functionality.
  4. On large projects, there may be a need to integrate the needs of related projects as well as the needs of a number of different stakeholders to produce an overall solution.

The key point is that if a Business Analyst is involved at all in an Agile project, he/she should add value in some way and should not be just an intermediary between the development team and the business users and stakeholders.

5 thoughts on “The Role of a Business Analyst in an Agile Project”

  1. This is slightly off topic but I’m really interested in what exactly you mean by “If the stories and epics follow a logical functional hierarchy it provides a mechanism for better understanding the relationship of the stories and epics to each other and for satisfying overall business goals.” How would you go about doing this?

    I’m working on a similar approach but have yet to meet anyone else in this area using this language. It seems to me the relationships between different stories and where they fit within a goal driven hierarchy is immensely powerful for a number of reasons. All I tend to see is people struggling with how to decompose PostIt Notes into more PostIt Notes and getting pretty well confused! 🙂

    1. “Functional Decomposition” is a standard business analysis technique that has been around for a long time. It involves a top-down approach of starting with high-level business objectives and progressively decomposing those high-level business objectives into lower-level requirements that are needed to fulfill those objectives (in Agile terminology that would typically be epics and stories).

      The problem with many Agile implementations is that it is many times perceived as an “all-or-nothing” proposition (either you’re totally Waterfall or totally Agile) and you have to throw out anything you’ve ever learned about plan-driven approaches to become Agile. That might work for small, simple Agile projects, but it doesn’t work well at all when you attempt to scale Agile to large, complex enterprise-level initiatives. That kind of project typically requires managing the effort at multiple levels (not just the development process) and requires mixing-and-matching plan-driven principles and practices with Agile principles and practices in the right proportions to fit the situation. That is not an easy thing to do – it requires more skill to do that than it does to force-fit a business or a project to some kind of canned methodology, but it can be done. That is the essence of what my new book is all about.

  2. I saw your post on the Job Description of an Agile Project Manager. Do you happen to have the Job Description of the Agile Business Analyst?

Leave a Reply

Your email address will not be published. Required fields are marked *