Purpose
The aim of this document is to create a single source of truth on what the Business Analyst (BA) function is meant to accomplish in the Banno/Digital teams and how people in that role can meet the expectations of the role. The need for such a definition arises from conversations with BA team members who all seem to agree that their roles are not always clear to them. It is understood that BAs at different levels in their career will have different responsibilities, but the core role definition is still a good starting point for having a discussion on how a BA’s role might evolve as they progress in their career. The intent of the document is to state which responsibilities are specifically given to someone with the BA title.
BA Responsibilities
Domain Knowledge and Documentation
Documentation Plan for Team Domains
The BA will be responsible for the documentation of existing domains. The BA will work with management to put in place a plan to document the team’s domains, and in the process of documenting, become a domain expert for the team. The BA will partner with engineers when needed to obtain the required information.
Cross-team Domain Documentation
In addition, the BA will understand how their team’s domains integrate with other domains and 3rd party products, working across team lines to produce documentation where necessary. This is an opportunity to partner with other BAs as well.
Example: A BA on the accounts domain will aim to also acquire understanding of services like jxchange and symxchange, as that knowledge will be critical when planning changes to the way the accounts domain works.
Documentation Review
The BA should review existing api documentation, and participate in peer reviews of changes to the documentation.
The goal of this work is to:
- Build up the BA’s knowledge of relevant domains
- To share this knowledge with others via quality documentation
Requirements Discovery and Gathering
Partner with Product to Define Requirements
The BA(s) will work closely with the product manager to flesh out the requirements for a new project. This phase of the project should result in a Product Requirement Document (PRD) that is comprehensive enough for engineers to start planning out the tasks needed to complete the project. The BA will follow up with Product in order to work through any ambiguities in the requirements and ensure the engineering team has a clear understanding of the specification. Where appropriate, the BA will work with Product, engineering and management to refine the scope of the project and define the priority with respect to other ongoing projects.
Create Technical Requirements with Engineering
Once the PRD is sufficiently fleshed out, the BA will work with engineering to define the technical requirements. BAs and engineers will work on putting together the appropriate technical requirement documentation when appropriate(TRD, example). This includes documenting requirements, changes to existing api contracts, new api contracts and creating a sequence diagram of the solution when necessary. Acceptance criteria will be defined in this phase as well. The need for documentation of the technical requirements will be left to the team’s appreciation.
Participate in Discovery Sessions
Fleshing out the requirements as mentioned above will also require participating in discovery sessions with Product and the various engineering teams. The BA will help to drive progress by making sure all ambiguities are documented and addressed during the meetings or in subsequent discussions.
Quality Assurance
Test Plan Creation
As implementation is progressing towards completion, the BA will create a test plan with scenarios that will verify that the implementation is working as expected from the functional and technical requirements laid out in the PRD and TRD.
Test Plan Execution
Once the test plan is written, the BA will execute it on the finished implementation in the appropriate environment and report the results to the team. This can occur as a pre-requisite for acceptance testing, or be done at the same time if that is appropriate.
The BA will work with the engineering team to ensure that the issues found during testing are addressed prior to release.
Ops Documentation Creation
The BA will work with Product Management and Engineering to create an Ops doc prior to releasing a feature. Responsibilities for drafting / documenting the Ops doc on the BA side will include the following:
- feature configuration details
- rollout details
- sequence diagrams and api contracts when necessary
- any corner cases and usage details that customers need to be aware of
Throughout the process the BA can lean on Engineering to provide technical support as needed. It is outside the scope of the BA’s responsibilities to finalize and publish the operations document. This responsibility would lie with Product, who would be responsible for coordinating all activities required to finalize the documentation.
Arbitrating Responsibility Concerns
There will be times where the responsibility for an item is not clear and/or the BA is asked to do something that falls outside the scope of responsibilities previously agreed upon.
The BA should not hesitate to involve their management in order to help resolve situations as they come up.
A note on Project Management
It is outside the scope of the BA’s role to be responsible for managing the project and ensuring that all milestones and deliverables are met. This is a concern that has come up several times for BAs and needs some clarification. Each project should have a project sponsor responsible for overseeing the completion of the project. This sponsor would typically be one of the following roles:
- Director
- projects spanning multiple teams and product domains
- Staff (and above) Engineer
- projects spanning multiple teams and product domains with a high degree of technical uncertainty (typically greenfield development or complex changes to existing architecture)
- Product Manager
- projects spanning a single product domain
The project sponsor would be responsible for verifying the following items are completed:
- The project expectations (“the ask”) is clearly defined (typically via a PRD)
- The project has been appropriately prioritized against our roadmap
- The right teams have been identified and looped in
- Teams have planned out the work
- Dependencies between teams have been identified and documented (typically through Jira)
- Recurring meetings have been set up to make progress towards the goal
- Blockers are being addressed in a timely manner
- QA has been performed and the solution has been validated prior to release
- Once development is completed, operations documentation has been produced, reviewed by the implementation team (and possibly customer support team) and is ready to be distributed to customers