Agile teams: you need a BA!
For the BAs that have experience in agile, you’ll be aware the role is not explicitly included in a theoretical agile team.
The official Scrum guide states “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”, many interpret the “Development Team” as only developers, testers and DevOps. I like to challenge that assumption.
All development teams need a BA. Development demands requirements and requirements require a holistic view of the business. Perhaps you are thinking ‘well isn’t that the role of the Product Owner’, and that thought does have merit. However, through my experience, no matter how involved the PO is, they are not comfortable writing requirements, or more commonly they do not have the time to breakdown an Epic level requirement to its component user stories nor the time to elaborate on each requirement further than verbal communication. This is where BAs fits in.
The BA has a unique position on the team to bring the voice of the customer to the team, and a specialist skillset containing the analytical skills to break down user needs logically and the communication skills to elicit user needs and clearly convey them back to the business and the developing team.
So, why do you need a BA on your agile project?
- Being the conduit between the users and the development team.
Each requirement needs to be first derived from a specific user need. BAs should be out there talking to the end users and understanding what they need, not what a project team thinks they need.
The user need can then be socialised with the development team to evaluate its viability and options on how best to meet it. The BA reminds the development team of the ‘big picture’ and can communicate the team’s thoughts back to the end user and vice versa in an iterative cycle.
- Presenting user needs in a digestible and clear way.
BAs often hear a user say, “yeah I like that, but it would make my life easier if…”. That user need can be written into a requirement, although a purely written form of communication increases the risk in the reader interpreting the requirement differently than the author intended. BAs can communicate the user need in multiple ways to make it clear to the development team. User stories, visual user journeys, mock ups and wireframes are all tools in an agile BAs toolkit. Utilising these tools increases the chance of a common understanding of the requirement and thus a successful meeting of the user need.
- Providing constant, iterative feedback to the team.
Agile delivery requires an agile mindset. The business and the development team need to converse to be successful. Unfortunately, the PO often has other responsibilities and therefore isn’t always available for day-to-day discussions with the team. The BA can act on behalf of the PO to talk through user stories with the team, discuss ‘what good looks like’ during the development cycle and bring the voice of the customer into the conversation. This enables each user story output to be flexible through discussion and enables the developer to deliver the best feature for the user need, whilst increasing business acceptance and reducing the risk of re-work.
- Defining priorities with the PO
The BA works with the PO to prioritise requirements. The PO understands the business context and what is most important in their worldview and the BA will be working closely with the business and end users from across an organisation; furthermore, the BA often has a technical understanding of the product. Together the PO and BA can bounce ideas off each other and challenge the reasoning behind the priorities. This enables the development team to deliver the greatest value features fastest.
- Collating constant user feedback
Once a feature has been developed the BA can utilise their pool of end user contacts to test the functionality for their needs. The feedback can be recorded, elaborated and prioritised into the backlog to drive towards a greater user experience.
In summary, a business analyst will improve the products success of business acceptance, save the business time and money through reworking features and will enable a quicker production of the most valuable functionality.