In recent years many companies have incorporated agile methodologies in their management and production processes, especially in IT environments. Along with the cultural change that this involves, the main challenge that organisations face is having people with suitable skills for undertaking these projects successfully. Without doubt, one of the critical capacities which must be present (and not only in agile environments) is Business Analysis as a link between the business and technological solutions.
As a Business Analysis trainer and mentor, I frequently answer questions on who should undertake this in agile environments. Is business analysis the responsibility of the Product Owner? Should there be someone qualified as a Business Analyst? As there are no written requirements, only User Stories, are analysts necessary? In this article I will try and shed some light on these questions.
Firstly, I believe that it is important to understand that rather than people, we are talking about competencies, knowledge and skills. In agile projects, as with other projects, business analysis competencies are key to the success of the project. Therefore, they must be present, sometimes centralised in one person and normally distributed between the people on the team. Don’t forget that Agile is a collaborative approach oriented towards teamwork. No one wins if we do not all win.
That said, according to the Scrum Guide from the Scrum Alliance, the “Product Owner is responsible for maximising the value of the product and the work of the Development Team”. They are one person and are responsible for the management of the Product Backlog. This makes them key and critical, and certainly the most difficult role to find.
According to the guide, it may be a single person who manages the backlog, or they may be supported by others, but always having full responsibility. It is a decisive role. In the field of the product and the Project on which they are working, they may make the main decisions related to the development of the product. In other words, they are a manager of the scope of the project. They identify and decide what must be included in the product in each iteration, and check that the result provides the expected value. They do so by consulting the appropriate interested parties.
In other words, they are “the voice of the client” within the team. It is a role equivalent to what other agile methodologies such as XP call Customer Representative, or Business Ambassador in DSDM. However, there will surely be other roles linked to the product and the business, not directly forming part of project teams but with a more strategic vision, such as Product Manager, Business Visionary and Business Sponsor.
To carry out their function, a Product Owner must have the following characteristics:
- They must know about the business
- Effective communicator
- Able to analyse and integrate the opinions of different interested parties
- Empowered for making decisions
- Clear about the vision of the product
- Able to define requirements and User Stories
- Able to define what is a successful result
- Available for the development team
Ultimately, the more experienced the business analyst, the better the Product Owner they will be.
But how many people do we know who combine all these characteristics? Surely not many.
On the courses I also insist that an analyst is not the person who has the answers, but the person with the best questions. An analyst, by definition of the role, does not have the capacity for decision making, but instead allows the best decisions to be made for the business. A Product Owner must define requirements and then validate them. They are like a judge, and part of the whole process, which also makes it more complicated for this role to fall upon a single person. That is, the role of Product Owner is not (only) a business analyst role.
For this reason, a common structure, especially when we begin to work with Agile, is to have a proxy, someone who acts as a link between the team and Product Owner, who provides analysis skills and methods, although the Product Owner continues to maintain their capacity for decision making. This proxy is a business analyst.
Finally, I would also like to say that defining requirements on agile projects is not only writing User Stories. The requirements, more or less formal, will end up having different forms as user stories, use cases, type diagrams, workflows, etc. Therefore, the analysis work will be for the Product Owner, but also for the team, regardless of whether or not there is an analyst designated.
To finish the article, as a conclusion, we can answer the questions raised at the beginning:
- Is business analysis the responsibility of the Product Owner? Not exclusively. There may be other individuals within or outwith the development team, who provide the knowledge and skills necessary for identifying requirements, analysing and designing the solution, and validating the product.
- Should there be someone qualified as a Business Analyst? It is not essential. Qualifications are not as important as the skills present. There are agile frameworks, such as DSDM, which explicitly include the role of Agile BA as part of the project team.
- As there are no written requirements, only User Stories, are analysts necessary? It is not true that all requirements end up as User Stories. User stories are a way of structuring, prioritising and managing the work to be carried out in each iteration, and allow a productive conversation to be started between business and IT to ensure that the solution will provide the expected value. To understand the work better, business analysts and the team will need to apply other analysis techniques (for example, Use Case Diagrams, workflows or Type Diagrams).