Background
Business Analysts (BA) are present on many agile projects, but their role is often not defined well. Some organizations successfully use BAs to provide Product Owner support. Others, however, use BAs in counterproductive ways.
General
The Business Analyst role in Information Technology (IT) often involves personnel specializing in eliciting and documenting requirements, user stories, acceptance criteria, and other definitions of the work to be done. In industry, the BA role can be a long-term career path. Organizations such as the International Institute of Business Analysis (IIBA) provide various certifications and training for this role, and maintain standards and bodies of knowledge. Those involved in this profession may specialize in various domains, and become highly expert in analyzing business metrics, defining business rules/practices, drafting requirements for automation, creating data visualization.
BAs in the Agile World: Risks and Mitigations
In the world of Information Technology, Business Analysts often are employed to elicit and define requirements or user stories. While this skill is critical, having it rest primarily on the shoulders of a specialist can create problems; this is where agile practices may contradict the IIBA’s view of the BA role. Additional problems (but also potential opportunities) may arise when the BA is not from the development team’s organization.
Opportunities Include:
1. A well-trained BA may facilitate design meetings and ensure teams don’t “leap to coding.” This facilitation should be a knowledge transfer activity, not a permanent state of affairs. The BA’s conventional approach to Design must be adapted to the agile view that design artifacts are suspect over time and “the truth is in the code.”
2. The BA’s skills in elicitation and requirements management can buffer the tendency to “leap into design.” Since the Scrum Master and Product Owner should dampen that tendency, however, this is a redundant benefit.
3. A well-trained BA’s skills in elicitation can help during backlog grooming. The BA should be actively transition those skills to Developers, Scrum Masters, and others; the BA’s leading elicitation should not be a permanent state of affairs.
4. BAs often are not part of the team or its organization, and thus may be subject to less peer pressure to shortcut key agile practices.
Risks include:
1. Having a BA available may reinforce misperceptions from the Development Team’s management. Developers may be pressured to do “real work” and default key activities to the BA.
2. If the BA is not seen as an integral part of the team, s/he often has to negotiate with team members for cooperation.
3. The Development team members may abdicate their responsibility for eliciting and documenting good User Stories and technical stories. Many of them may never develop those skills.
4. The Development team members may fail to develop close relationships with their Product Owners (POs) and end users, having left those interfaces to the BA.
5. Existing over-specialization, hierarchies, information hoarding, hero worship, or other team-dynamics issues are fed by including yet another specialized role.
6. By having someone else define stories for them, the Development team members may become order-takers rather than proactive elicitors of customer needs; as a result, systems architecture decisions can fail to account for non-functional requirements.
7. Collaboration may suffer. The PO à BA à Developer communication path has two handoffs before information is given to the developers. For complex stories, this risks defect insertion. It risks needing additional time to get clarification, time extra that could have been avoided by direct communication.
8. Time needed for elicitation and elaboration may not be accounted for as a part of everyone’s work (“it’s someone else’s problem”), leading to over-optimistic estimates.
9. BAs often are junior people, and are thrown into “sink or swim” situations. Poor integration of the BA role in an agile development team can lead to uncertainty and avoidable errors in their work and costly turnover of BA personnel.
10. Epic/Feature/Story refinement may take excessive effort due to the BA’s not knowing the technical domain. Failing to prepare BAs to perform some technical activities in an IT environment often is a wasted opportunity. It also reinforces the habit of creating overly layered management structures and roles, which increases handoffs and inefficiencies.
11. An opportunity to abuse the BA role may be used as a cover for other poor practices. Such practices may include over-committing developers and Scrum Masters because the BA will pick up the slack in story development.
12. Many BAs have learned their roles in conventional SDLC contexts. Many of the skills have been included in university-level Systems Analysis and Design courses for decades, particularly:
Elicitation and Collaboration
Requirements Life Cycle Management
Strategy Analysis
Requirements Analysis and Design Definition
Solution Evaluation
While these skills are vital, learning them in a context alien to Lean and Agile principles can result in difficulties understanding how to apply them in real-life agile-based work. In such a situation the BA can become a blocker rather than an asset.
Recommendations
1. Provide BAs with a role guidance (or roles) that shadow other roles
a. Scrum Team member apprenticing technical roles
b. Agile Coach
c. Associate Product Owner
d. Associate Scrum Master
2. Hold the Product Owner, Coach/Scrum Master, and Development Leads responsible for ensuring Product backlog grooming takes place, not just Sprint backlog grooming. Also hold these persons responsible for the quality of Stories; do not lay responsibility for such quality at the feet of a BA.
3. Hold the Scrum Master and Product Owners responsible for understanding who needs to be present during various backlog grooming sessions and inviting those people specifically.
4. Ensure the BA does not perform work in a way that allows other role holders to abdicate their responsibilities
5. If BAs need to supplement the work of other role holders, give them clear authorization and support to do so
6. Provide adequate mentoring and guidance so that BAs do not accidentally (or under duress) perform work that undermines basic agile tenets and principles, in turn causing or allowing setbacks in reaping the benefits of agile approaches.
7. Ensure conventional BA knowledge areas are adapted to agile life cycles, including the principles of self-organizing, multi-disciplinary teams.
8. BAs should be trained and evaluated upon their ability to facilitate needs elicitation and story definition; they must not be directly responsible for those activities taking place.
9. Physically co-locate BAs with development team members; pair them with technical people on a rotational basis to improve their ability to perform work beyond the stereotypical “BA as scribe” role.
10. Ensure Developers invest their time scribing duties for defining requirements or User Stories. Having one person doing all the writing creates a bottleneck and lowers developer investment in the value of User/Technical Stories.
11. Consider people placed in the BA role as apprentice Developers, meaning they will, sometime in their career, perform some aspect of technical work. That work may be coding, data architecture, configuration management, etc., that directly ties into creating, assembling, testing, or deploying system components. A secondary track could be as apprentice Product Owners, but their having some technical know-how still would be useful.
~~~~~
Appendix: BAs and Agile Fundamentals
In cooperation with the Agile Alliance, IIBA has issued guidance on interpreting the BA role in agile environments. Our Agile Coaching group has successfully employed skilled BAs to serve as coaches and data analysists. In the general IT world, however, many BAs still have been trained in conventional SDLCs, and may default to Waterfall Life Cycle habits. The following components of fundamental Agile may impact how the role is interpreted.
