As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the business analyst (BA). Below are some steps to help business analysts navigate their way through the transition to agile and add the most value to their agile teams.
Understanding the Agile Mindset
Agile Manifesto
Any business analyst practicing in an agile environment must first have a basic understanding of the agile mindset and why it was established. The Agile Extension of the BABOK Guide describes Agile as a mindset that guides the way work is approached. Key characteristics of the agile mindset includes rapid delivery, increased collaboration, empirical learning, avoiding waste, and producing high-quality products. While agile practice date as far back as the 1960s, the mindset was formalized in 2001 when the Agile Manifesto was published as shown below.
12 principles behind the Agile Manifesto
In addition to learning the concepts of the Agile Manifesto, agile business analysis practitioners must also recognize the 12 Principles behind the Agile Manifesto. Understanding these principles will help agile team members determine how to facilitate the many interactions involved in software and project management. This is especially important in maintaining the overall essence of the framework. Less rule-based approaches can often be misconstrued if the founding principles are not emphasized.
Understanding Agile Frameworks
Another key component in agile business analysis is understanding that the term Agile is a high-level framework with various defined frameworks that fall underneath. Some of the most frequently used agile brands include Scrum (most common agile framework), eXtreme Programming (XP), Kanban, Crystal Methods, Scrumban, Feature Driven Development (FDD), Dynamic System Development Method (DSDM), Large Scale Scrum (LeSS) and many others. It is important to learn about the various agile frameworks because organizations need to assess the frameworks and employ the one (or combination) that best aligns with the organization. While there will certainly be shifts in organizational operations and culture during the transition to an agile environment, choosing frameworks that complement the existing environment may ease the process.
From the business analyst perspective, learning the roles and responsibilities within these frameworks will assist in setting the proper expectation for new roles or responsibilities. It will also help understand the intended value of the various ceremonies of the frameworks. The business analyst role is not distinguished in some agile frameworks; therefore, it is essential for BAs to understand where their skill set fits so they are able to add as much value possible.
T-Shaped Learning
Cross-functional Teams
In most agile frameworks variations of three key roles are recognized, which are Product Owner, Team facilitator, and Cross-functional Team Members. Business analysts in an agile environment typically fall into the cross-functional team member role. In order for the business analyst to be successful as a cross-functional team member, he or she must embrace a T-Shaped learning environment. This type of environment encourages team members to be crossed trained in multiple areas. Members add value because they have deep knowledge in one area supplemented by high-level knowledge in a broad range of other areas. This provides the flexibility for team members to pick up work throughout the entire software development life cycle as well as shift work to the highest priority tasks when needed.
Business analysts on agile teams who feel underutilized will need to discuss the issue with the team facilitator to determine what additional skills can be picked up to add more value to the team. Most cross-functional team members are composed of business analysts, developers, and testers. The image below illustrated the T-shaped learning model for a cross-functional agile team.
Business analysts in cross-functional teams can add significant value when they take on the following responsibilities:
- Train other team members on agile business analysis activities such as developing personas, storyboarding, writing user stories, defining acceptance criteria, story decomposition, and wireframing.
- Learning skills outside of the core business analyst skill set such as QA testing and coding
- Facilitate planning horizons
- Facilitate collaborative elicitation workshops
BA-Product Owner Relationship
Many business analysts have found that Product Owners (PO) have assumed many of the traditional BA responsibilities. This is another area where the business analyst skill set can add significant value. Many product owners are appointed because of their significant business knowledge, however, if not formally trained, many of them lack the project related skills to be fully effective. Team members with a BA background will need to train and support the PO on tasks such as developing business cases, writing user stories, cost/benefit analysis and writing test cases. Some business analysts in agile environments have even transitioned to the product owner role, however, it is generally best to keep the two roles separate.
One thing to note about the business analyst role in agile is that even though the BA title is marginalized, the BA skill set is emphasized. This means that the skill set and responsibilities of the traditional BA are distributed to many different roles on the agile team. Agile business analysis practitioners will need to become comfortable with the fact that requirement elicitation activities will no longer be the sole responsibility of the BA and other team members will need to be trusted with these tasks as well.
Agile Requirements Management
Less formal documentation
In agile environments, working software is valued over comprehensive documentation. Contrary to popular belief, this does NOT mean that requirements don’t need to be documented. However, this does mean that requirements are often less formal. Many agile frameworks manage requirements in the form of a product backlog. Here, requirements are usually represented in the form of user stories with acceptance criteria. The BA may need to support other team members to ensure that user stories are usable and that there is a sufficient amount of acceptance criteria to size the story and move it into the upcoming iteration. In addition, the stories in the backlog must be prioritized based on value to the business. While the product owner is generally responsible for the priority of the stories, the BA can add value by assisting the PO to determine the value (cost/benefit) of each story. An agile business analyst may also be a great resource to the product owner when determining the minimum viable product (MVP) for the project.
Working Software
Due to the fact that agile software development emphasizes elicitation through a working software, it would behoove the agile business analyst to sharpen up on wireframe and prototyping tools in an effort to quickly obtain rich feedback from the customers. In addition to obtaining feedback quickly, business analysis in agile environments involves adapting to a flexible scope. While there is some level of scoping in agile business analysis, the scope of the solution may change as new information is discovered or the organization's priorities change. This requires an agile BA to be flexible enough to quickly course correct, re-prioritize, and elicit new information based on what was learned from customer feedback.
Agile BA Techniques
Agile business analysis practitioners many need to expand their BA toolkit to include techniques that are more suitable for an agile environment. Agile business analysis techniques are less focused on research and more focused on experiments and collaboration. Agile BA techniques facilitate knowledge transfers between different planning horizons (Strategy, Initiative, and Delivery), where the feedback obtained in one horizon provides direction to another horizon before moving forward. Below are high-level descriptions of frequently used techniques in agile business analysis:
- Acceptance Criteria – Used to support user stories to determine when the story is complete and will achieve user acceptance.
- Backlog Management and Refinement – List of stories prioritized by the value added to the business or urgency in deployment. Backlog may be refined in an effort to ensure that the stories meet the team definition of ready prior to being moved into the next iteration for work.
- Behavior Driven Development – Focuses on customer behavior for the solution to address a customer need. Uses Gherkin Syntax to define acceptance criteria to define intended outcomes and outline test cases
- Job Stories – Used to represent product backlog items (PBI) that describe what a stakeholder needs and the motivation for that need. Job stories focus on the value to the customer while user stories focus on features that address a need.
- Kano Analysis – Used to display the customer's view of product features and determine those that are most significant. Product features are identified as one of the following categories: threshold (basic), performance, excitement or indifferent.
- Minimal Viable Product – Assesses and prioritizes features/stories to determine the minimum set of requirements that can be delivered to satisfy the business need in the shortest time.
- Personas – Creates that customer archetypes to provide additional context to align the solution to the customer needs.
- Product Roadmap – Documents and communicates the strategic vision and direction of a product or project as well as measure the progress towards that vision.
- Real Options – Used to determine the last responsible moment a decision can be made so that the team can focus on the highest priority issues.
- Relative Estimation – Uses previous experience to estimate the complexity, size, and uncertainty of stories and items in the backlog.
- Retrospectives – Lessons learned session at the end of each iteration to continuously learn and improve.
- Reviews – Demonstrations of work completed during an iteration or increment in order to obtain feedback from the stakeholders
- Spikes – Used to time-box research-based tasks or prototyping in an effort to determine the complexity or effort of a backlog item.
- Story Mapping – Provides a visual of the priority and sequence of stories that support a product or solution as well as communicate the functionality.
- User Stories – Statement of functionality needed to provide value. Written in the voice of the customer. The format includes a role/persona, necessary action, and the business value.
- Value Stream Mapping – Fact-based representation of the activities required to deliver a product to the customer. Analyzed in the current state to identify opportunities for improvement and defined in the future state to describe what the process will look like once improvements are implemented.
Closing Thoughts
In conclusion, the role of the business analyst in an agile environment is still vague to many organizations. This is partially due to the fact that the BA role is not distinguished in many of the branded agile frameworks. This does not mean that the business analyst is not valued in agile environments. As many organizations are finding, the business analyst skill set is even more critical in agile environments due to changing scopes and priorities, therefore, agile business analysis practitioners must be ready to step up to the challenge. To all my fellow BAs out there while your title may be changing, your ability to add value will be highly recognized as long as you understand where your skill set fits within the agile framework and are willing to embrace change.
Author: Michael F. White, Business Analyst and Founder of The Business Analysis Doctor, LLC
Michael has an extensive background in business analysis, project management and coaching. He has driven innovation at some of the top financial institutions in the nation and holds a Doctorate in Business Administration. To learn more about The Business Analysis Doctor, LLC visit https://thebadoc.com