BA responsibilities in an Agile environment in software development are a popular subject. In this article we will discuss a part of it, trying to answer the question: ‘How can a BA contribute to the delivery of a software project, in a SCRUM team?’.
To narrow even more the subject of this article, we will discuss only about the way a BA can help the SCRUM team in an outsourcing software company. This niche allows us to ‘open the path’ for discussions, with the starting point described in this article.
One of the most common first reactions is the one described above. What is a BA good for? The SCRUM Team has a PO – usually on customer’s side –, a Scrum Master, a PM, and a backlog. Thus, everything’s in place, we have the object of the work, we have the roles that coordinate the work, and we have a role to report to, responsible for the final product.
The BA is already there, although not in person, but in responsibilities and attributions. The BA responsibilities are fulfilled by different persons according to the situation – some by senior developer / QA engineer, some by the PM / SM, some by the PO. This addresses the ‘fit in’ part. But taking some responsibilities from a TEAM member can be a hard task, for an extern. What can be done?
For starters, the BA must earn the trust of the team. In order to earn it, he must know how the team works – not from the perspective of methodology, but from its internal relations and processes. Discussions with the senior members of the team, both developers and QA engineers, about the project, openness, self-study about the business domain, understanding the needs of an active company in that field, learning the customer’s particularities along with the ‘classic’ attributes of a BA (communication skills, methodology knowledge, attention to details, etc.) can be used to increase the level of trust in the BA-SCRUM team relationship.
Secondly, the BA must identify and address the pain points of the project, below are some of the most frequent:
Last but not least, attitude. A BA can be successful in the integration task if, and only if, she/he lets the team members know that she/he appreciates the effort they put into the product, the knowledge they have about it, and is willing to put the pieces together in order to make things better for the team.
As a first conclusion, a BA can:
The BA, using the previous experiences, should be able to learn quickly the new tools, if needed, or propose the ones he knew. As mentioned above, the BA can improve various aspects of the project and work.
This might be an issue in any organization, because most of the times, the processes within the team are a mix between the internal and customer’s processes, and usually the mix is not a good solution. The BA must understand the reasoning behind the process approach, and after that, must try to propose small changes (biggest impact on the team – first). This will address the team integration effort and increase the trust level of both the team and customer. The BA can use diagramming tools (such as Visio), Office suites (Microsoft, Open, Libre).
BA can also improve customer organization’s processes in the later phases of his assignment, after she/he gained enough influence and trust from the PO and stakeholders.
The documentation for a project has almost always aspects to be improved, such as structure, updates, integration with the processes and tools, accessibility. In order to improve documentation, the BA should analyze the current state, and then propose solutions. The solutions can be: central repository (subversion folder or wiki) with cross references to task tracking tools, task tracking tools issues description: Atlassian Confluence, SharePoint, Github, Atlassian JIRA, VersionOne. The documents themselves can be created with aforementioned Office suites.
Of course the extremes can be no documentation and just-enough documentation, but there is always room for improvement.
In order to improve this aspect of the project, several pre-requisites must be fulfilled. The BA must know who the stakeholders are, must identify the channels of communication with them, and must be empowered to do it.
The foundation for this comprises in stakeholders RACI / RASCI (Responsible-Accountable-Consulted-Informed/ Responsible-Accountable-Support-Consulted-Informed) matrix and communication plan, created or assessed by BA.
The team and product backlog are sensitive areas because they include the inherited (thus hard to change) habits and procedures. They must be addressed with caution and any change should be backed up by solid arguments and reasoning.
Alignment with the methodology, consistence, structure, clarity and content improvement for the Epics, User Stories, and Tasks as well as for their corresponding specifications are aspects that must be taken into consideration and used as arguments for any proposed change.
One of the positive challenges for the BA in a new project consists in the lack of clarity in the requirements, in absence of specifications and design.
The BA can use one of the tools from a large palette of tools for creating mock-ups and rough UI designs, such as Balsamiq, moqups, Just in Mind (for creating prototypes and mock-ups), Photoshop, Paint.Net, Gimp (for UI designs). While using this, there are some factors that must be taken into consideration, such as: the current UI style guide for the application, the stakeholder for UI on customer’s side (PO, UI designer, UX designer).
One of the most powerful tools in a BA portfolio is the ability to identify the User Stories that require such details and refine them with the PO, and then present them to the team.
The team should be informed about the important changes that occur in the client’s organization, about the plan for the future. This is a way to make everybody in the team aware of the importance they have for the product and take pride in their work, as well as a step to gain the trust of the team.
Presentations, regular interactions, ad-hoc discussions are powerful tools for building the awareness of the team.
As seen above, the BA has a wide range of opportunities for integration in a SCRUM team, as she/he masters the aforementioned set of tools and skills. She/he can influence both the team and the customer, internal and external processes, SCRUM artefacts and historical documents
The integration in the team is just the first step of the BA contribution to the team added value, as well as one of the early stages of her/his contribution to the added value for the project and for the customer organization.
The feedback on this article is appreciated and will be considered as input for the future articles about the benefits of having a BA in an outsourcing SCRUM project.
by Peter Lawrey
by Răzvan Costa
