One symptom of this is the frequency with which authors of IT websites and books, as well as conference organisers take up the subject of analysis. The attitude of employers is also changing, and demand for specialists in this field keeps growing. At the same time, Agile methodologies of project management – such as Scrum, TDD, BDD and lean – are also gaining popularity.
How are these two popular trends related? To answer this question, we need to recall a bit of Scrum theory.
In projects that use the Scrum methodology, three roles are defined. Each is necessary if the project is to succeed. Every member of the project team is given one of these roles and the responsibilities associated with it:
- THE SCRUM TEAM (DEVELOPMENT TEAM / PROJECT TEAM) – evaluates tasks and makes incremental progress of the project in predetermined iterations (called Sprints)
- SCRUM PRODUCT OWNER (PO) is responsible for the project’s progress and for managing tasks (implementing changes and prioritising them)
- SCRUM MASTER – monitors processes and explains Scrum to other team members
It is worth noting that the role of Business Analyst is not one of the Scrum functions. However, companies which use Agile methodologies increasingly choose to include at least one analyst in the team. So, where is the proper place for the BA in this approach? Interestingly, the Analyst can perform any of the functions defined in Scrum, and also work outside the process.
BUSINESS ANALYST AS A MEMBER OF THE SCRUM TEAM
In this model, the Analyst is a full member of the project team. This means that his or her work is monitored and evaluated during Sprints and may include:
- Analyst’s work – providing a certain number of User Stories ready for implementation in future Sprints, working on one or more Spikes as part of research into a given topic
- Tester’s work – testing current tasks in Sprint
In this mode, the Analyst’s work must be very well planned and monitored, and there is not much room for doing things “on the side”. The key task is to complete the tasks the entire team has agreed to deliver as part of the current Sprint.
BUSINESS ANALYST AS THE SCRUM PRODUCT OWNER
In this case, the Analyst manages the tasks being performed as part of the project/Sprint, and also creates their specifications. This solution is suitable for internal projects, in which the PO is not the client’s representative.
The great advantage of this approach is that one person is able to answer immediately any questions the Scrum Team may have. This is possible because, as the Product Owner, he or she manages functionalities and their scope. It means that there is no additional time needed for consultations involving the Analyst and the PO. Moreover, the analytical experience of the analyst helps to assess how the above-mentioned questions – and any changes resulting from them – significantly impact the currently existing solutions. I am talking about changes in complexity, as well as processes or the need for additional work.
Therefore, the Analyst’s job carries great responsibility. After all, he or she determines what product functionalities – and in what order – will be implemented, and which may never be implemented due to various constraints (deadlines, human resources availability, cost, etc.).
BUSINESS ANALYST AS AN ASSISTANT TO SCRUM PRODUCT OWNER
This model is often used in projects, in which the PO comes from the client’s side and his or her availability to the Scrum Team is limited. In this case, the analyst (also called Proxy Product Owner in this model) can make key decisions without consulting the official PO. This greatly expedites the work of the team, reducing the time needed to complete current tasks. In this case, too, the Analyst’s role comes with significant responsibility. Therefore, he or she should have in-depth understanding of the client’s domain, plans/roadmap and priorities. It helps to estimate correctly the scope of changes which are the result of project decisions and check their accordance with PO’s vision.
BUSINESS ANALYST OUTSIDE THE SCRUM
In this approach, the Analyst is treated like any other external consultant/specialist, whose role is to support the work of the project team. He or she does not perform any specific tasks as part of the Sprint. The BA’s role is to advise the client, to maintain contact constantly and to provide the Scrum Team with task specifications. In theory, under this model the Analyst should not participate in the Sprint ceremonies (demo, retrospective, planning). In practice, however, his or her presence is strongly recommended, as the Analyst is one of the “external specialists” who are most involved in the project, as he or she works both with the client and with the Project Team and/or Product Owner.
BUSINESS ANALYST AS SCRUM MASTER
It should be pointed out that none of the above solutions preclude the Analyst from performing the additional functions of the Scrum Master. These roles are so different that one person may very well deal with both areas of the project – carrying out business analysis, supervising the process and educating the team about Scrum.
What to choose?
By analysing the above approaches, one can clearly see that there is no universal method of combining the role of BA with Scrum. Each option has advantages and disadvantages in equal measure. The choice is largely determined by factors that are sometimes outside our control, such as the availability of the client and the client’s team, the nature of the project, the team’s experience, etc.
Experience shows that it is best to define the rules governing the Analyst’s cooperation with the rest of the Scrum Team at the initial planning stage, i.e. when choosing the members of the team and the implementation strategy for individual functionalities. In the perfect world, team members would determine how they want to work with the Analyst. Indeed, the Scrum methodology assumes that the team is a self-organising group of experts, which should not have ready-made solutions imposed on it.
Read more about the roles in the Scrum Team by International Scrum Institute here