Application Services provides a platform for IT Development and Maintenance professionals to discuss and gain insights into best practices, process innovations and emerging technologies that will shape the future of this profession.

« How enterprises can transition from traditional methods of software development to Agile methodology? | Main | Striking the Balance: Waterfall and Agile - Part 2 »

How Business Analyst can add value to an Agile Scrum project?

In traditional software development model like Waterfall a BA's foremost responsibility would be to spearhead the Requirements phase. As a part of this he/she would identify the right business stakeholders usually from cross functional departments, set up workshops to gather requirements, read through hundreds of pages of enterprise process documents, clarify issues, ambiguity in requirements, document and review them over multiple calls, iterate the whole process as required and finally publish them after receiving a sign-off from all the stakeholders. Then the next phase of handover begins by conducting calls with development and testing teams to make them understand the requirements which results in design and test case documents from the respective teams.

On the other hand Agile mode of software development consists of a self-organizing cross functional team where the typical roles involved are Product owner, Scrum master, developers and testers. In addition, one of the core principles mentioned in the Agile Manifesto is "Working software over comprehensive documentation" the significance of which is that business need only to encourage activities that add value and so there is no place for effort being spent on producing tons of documentation which may not even be used by enterprises later. In this context, how can a BA be a part of a self-organizing team which does not require an elaborate requirement document to start off on the development?

Let's first understand how Agile is conducted and then we will explore areas where a BA can add value.

Agile Overview:

One of the important artifact of Agile development is the Product Backlog. A product backlog consists of epics, user stories that needs to be realized. These are prioritized according to the business need and are estimated in terms of story points. The product backlog is improvised incrementally and is owned by the product owner. The product owner plans future releases which aim to launch significant features with every release. These releases are made of multiple sprints where each sprint has a duration of 1 week to 4 weeks. So for ex: If a sprint is for 2 weeks then a release can be planned every month or two depending upon the substance of the features launched. Before a sprint can start, a sprint planning is conducted which is typically 4 hrs. for a 2 weeks sprint. During the sprint planning meeting the team commits for the user stories to be developed for that sprint. Once committed the team then focuses on the sprint goal with a checkpoint daily called the 'daily scrum call' to take stock of the situation. At the end of the sprint the team conducts a sprint review meeting where the team demonstrates the functionality implemented during the sprint to all stakeholders. After this a sprint retrospective takes place which identifies improvement areas for the team in the coming sprints.

Product backlog:

An Agile BA's goal is to add value to business and hence he needs to understand the overall business problem to be solved with end picture in mind and at the same time work on adding user stories or detailed tasks to the product backlog and prioritize the PBI's (product backlog items) in consultation with the product owner. Although a product owner owns the product backlog usually he/she would be responsible for multiple product lines and so may not maintain the product backlog on a day to day basis. A BA needs to improvise the product backlog incrementally and review it with product owner once during a sprint.

Agile ceremonies:

A BA can also play the role of scrum master during sprint planning, daily sprint calls, sprint review and sprint retrospective meetings.

During the sprint planning meeting the BA encourages team to discuss the user stories and clarifies or removes any misconceptions they have. He is responsible to provide as much details as possible to enhance the teams understanding on user stories which requires the BA to be well prepared before the meeting. He may/may not be involved in the estimation process depending on his background relevance to software development.

A BA should work to remove any obstacles faced by team members which are preventing them towards achieving their sprint goal. These could be day to day issue like lack of access to facilities, external hijacking for work unrelated to sprint goals etc. During the sprint BA can work with QA team to come up with test scenarios and test cases for the user stories. In the sprint review, he/she demos the features realized during the sprint to all the relevant stakeholders and takes their feedback. This feedback is then quickly analyzed to update the product backlog in the form of new user story addition or a new work item. Every agile team should at the end of the sprint care about retrospectives but teams are so busy in the delivery work that they need someone to remind them to inspect and adapt. A BA should be the proponent of regularly focusing the team where it can improve.


A major responsibility of a BA is to facilitate discussions between product owner and agile team including developers, testers etc. As the BA has good business domain knowledge he can understand the requirements from product owner and write them in a format which can be understood by developers although in the form of user stories and in a JIT (Just-In-Time) fashion unlike the traditional model of elaborate documentation. A BA needs to understand the agile team dynamics and collaborative decision making while coming up with user stories and involve the agile team during the process.

In a collaborative environment, ability to steer a conversation towards an agreement is a key skill that a BA can possess. Whether it is agile or not, when you have a group of people together with different ideas, there should be a referee to decide. This ensures that everyone's perspectives are taken into account and that realistic solutions are actually discovered. Also a BA can support product owner in coming up with release/sprint burndown/burnup charts to track the velocity of the team.

Innovation & Leadership:

While the agile team works re-actively on the sprint backlog, a BA should continuously find new ways to solve business problems and try to come up with new way of doing things that can add value to the end customer of the product. Although a BA may not lead a team officially he needs to learn to influence teams to buy his ideas by inspiring them through his actions and thoughts.

Going beyond the role definition and Adapt:

Many BA's will find themselves going beyond the role definition be it assisting project sponsors in coming up with the business case for the product or doing functional testing at the end of project. In fact where ever there are white spaces left which nobody on the team does should be filled by BA. The project successes ultimately matters and for this a BA has to go that 'extra mile' to accomplish anything that takes the team a step closer to realizing the vision of success. 



It is the useful information for the Business Analyst.

Great post and its really informative content.Thanks for sharing

Hi, In this article u shares an information about the ba in usa,uk and all over the globe with professionals.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.