11. Perspectives

11.1 The Agile Perspective

BABOK® Guide

IIBA.org KnowledgeHub A Guide to the Business Analysis Body of Knowledge® 11. Perspectives 11.1 The Agile Perspective

The Agile Perspective highlights the unique characteristics of business analysis when practiced in the context of agile environments.

Agile is about having a flexible mindset, embodied in a set of values and principles and exhibited by a variety of complementary practices. Agile initiatives involve constant change. Business analysts working on agile initiatives continually reassess, adapt, and adjust their efforts and tactics. Business analysts conduct analysis and deliver work products at the last responsible moment to continually allow flexibility for change; detailed analysis work is not done ahead of time, but just in time to be effectively utilized by the agile team.

Agile business analysis ensures that information is available to the agile team at the right level of detail at the right time. Business analysts help agile teams answer these questions:

What need are we trying to satisfy?
Is that need worth satisfying?
Should we deliver something to satisfy that need?
What is the right thing to do to deliver that need?

Business analysis work is performed continuously throughout an agile initiative and relies heavily on interpersonal skills such as communication, facilitation, coaching, and negotiation. Business analysts are active members of an agile team and often facilitate planning, analyzing, testing, and demonstrating activities. In an agile team, business analysis may be performed by a product manager/owner, business analyst, or by other defined team roles. Business analysts help the team identify modifications in assumptions and other project variations that emerge.

Refer to the Agile Extension to the BABOK® Guide for an expanded treatment of the role, mindset, and practices of business analysis in agile approaches, as well as details on the values and principles of the Agile Manifesto (www.agilemanifesto.org).

11.1.1 Change Scope

Business analysts working on agile initiatives engage with the business sponsor on a strategic level and assist with defining how the proposed product or feature aligns with the organization's objectives. They collaborate with various stakeholders and the change team to break the product vision down into a prioritized list of desired work items to be completed. The prioritized items (or prioritized backlog list) usually focus on the capabilities needed in the resultant product, with emphasis on the highest value items first.

Business analysts may act as a stakeholder proxy, or work directly with the sponsor or product owner.

In agile environments, change and rapid response to change is expected. Agile teams deliver small, incremental changes and commit to prioritized work items for only one iteration at a time. This allows the agile team to handle emerging changes for the upcoming iteration with minimal impact. An iteration is an agreed period of work time.

Requirements are developed through continual exploration and analysis of the business needs. It is important to note that though most agile approaches are iterative, not all iterative approaches are agile. There are also several agile approaches that are not iterative, such as the kanban method.

During agile initiatives, scope is constantly evolving. This is managed by the backlog list which is continually reviewed and re-prioritized. This process contributes to the refinement and redefinition of scope in order to meet the evolving and emerging business need.

If a major change emerges that significantly impacts the overall value and goals for the project, the project can be adjourned and reassessed.

.1 Breadth of Change

Agile approaches are used to address a variety of needs in an enterprise. The most common use of agile practices is in software development projects. However, many organizations have started to apply agile principles to non-software related change such as process engineering and business improvement. Initiatives using agile approaches can be undertaken within a single department or can span across multiple teams, departments, and divisions of an organization.

For organizations new to the agile mindset and practices, a focus on continuous improvement, ongoing changing behaviour, and making progress enables the organization to move towards culturally adopting the agile mindset. Adopting the agile mindset refers to the cultural adoption of agile principles as opposed to the organization considering agile as a methodology or practice to be implemented.

.2 Depth of Change

Initiatives using an agile approach are frequently part of a larger program of work, which can include organizational transformation and change, business process re-engineering, or business process change. The agile work stream is frequently, but not always, centered on software development. The other elements of the program can be developed using agile or another methodology that is appropriate for the need. Agile principles and practices are often successfully applied in initiatives where:

there is a clear commitment from the customer and engagement by empowered subject matter experts (SMEs),
the business need or proposed solution is complex or complicated, and
business needs are changing or unknown and are still emerging.

Agile approaches can be used for initiatives that are developing a solution for the first time, or for maintaining and enhancing an existing solution. For example, if the change is mission critical then processes can be added to address regulatory requirements and to deal with the mission critical aspects of the project.

.3 Value and Solutions Delivered

The value and solutions delivered in an agile initiative are similar to any other initiative. The difference with an agile approach is the emphasis on delivering value early in a highly collaborative manner, using adaptive planning that has a focus on continuous improvement.

An agile initiative provides value by virtue of the approach taken by an agile team through ongoing review and feedback of the work performed. Stakeholders get the opportunity to frequently review the product, which allows them to identify any missed requirements early. The solution evolves over time with an expectation of rapid and flexible response to change. Clarity and visibility of all communications is of the utmost importance to ensure the agile team’s efforts align with the organization’s needs and expectations.

In a new team, the business analyst often plays a central role in building rapport and trust amongst the agile team members and external stakeholders to help enable ongoing collaborative discussions and engagement. This interaction enables the agile team to accurately deliver value that meets evolving stakeholder needs.

.4 Delivery Approach

Agile approaches focus on people interactions, transparent communications, and ongoing delivery of valuable change to stakeholders.

Each agile approach has its own unique set of characteristics that allows teams to select an approach that best suits the initiative at hand. Some agile teams have found that a hybrid or combination of approaches is necessary to work within the constraints of their environment.

Refer to the Agile Extension to the BABOK® Guide for a description of different agile delivery approaches.

.5 Major Assumptions

The assumptions in place in agile environments frequently include:

Changing requirements are welcome, even late in development.
The business problem can be reduced to a set of needs that can be met using some combination of technology and business process change.
Agile initiatives have fully engaged customers and empowered SMEs with complete buy-in to the agile approach.
Ideally, team membership is constant and members are not continually being moved to other teams.
There is a preference for multidisciplinary and co-located teams encouraging more efficient and effective face-to-face conversation. However, agile approaches can work well with distributed teams provided appropriate support and communication channels are in place.
Team members may perform more than one role within the team if it is required, and provided that the team has the appropriate skills (for example, cross-functional teams).
Team members have a mindset for continuous improvement and successful value delivery through regular inspection.
Agile teams are empowered and self-organizing.

11.1.2 Business Analysis Scope

.1 Change Sponsor

It is important that a sponsor of an agile initiative be familiar with the agile philosophy, mindset, and approaches, and also be open to the constant feedback that will require trade-offs from the stakeholders.

An agile sponsor understands and accepts the:

use of adaptive planning over predictive planning,
use and value of a fixed period of time for a work cycle, and
need and value of the sponsor’s involvement.

The sponsor’s (or empowered SME's) active involvement with the agile team is critical to providing the sponsor with the ability to preview and understand the product being developed, as well as allowing an opportunity for the sponsor to provide continuous feedback to the team and adjust the product as needs change.

.2 Change Targets and Agents

Agile approaches are most successful when the organizational culture and working environments lend themselves to intensive collaboration, frequent communication, and a strong disposition towards incremental delivery of appropriate solution value.

Agile teams are frequently either small or around teams of small teams. The simpler and flatter structure doesn’t change the fact that the deliverables may affect a large group of stakeholders. The change agent, also considered a stakeholder, is not different because the project uses agile. The primary agents for a change using an agile approach can include:

Agile team leader: the facilitator of the work of the team. An agile team leader frequently shares the same soft skill set of a project manager, but completely delegates the tasks of planning, scheduling, and prioritization to the team. Rather than traditional command-and-control management, servant leadership is preferred in all the agile approaches. Depending on the approach, this role may be called scrum master, iteration manager, team leader, or coach.
Customer representative or product owner: the active team member responsible for ensuring that the change being developed addresses the requirements for which it has been mandated. In Scrum this role is called the product owner. The dynamic systems development method (DSDM) refers to this role as that of a visionary, and extreme programming (XP) refers to it as a customer representative.
Team members: the specialists or domain experts that include both technical and customer representation. Depending on size and particular context of the initiative, individuals within a team have different specialties. Usability experts, technical architects, and database administrators are just a sample of such specialized roles that provide support to the team as needed.
External stakeholders: all of the remaining stakeholders who may not be considered team members, but are an interested party in the outcome of the project or simply required for its completion, playing what can be considered a supporting role in the team.

.3 Business Analyst Position

An agile team may have one or more team members with business analysis skills who may or may not have the job title of business analyst. This recognition of cross-skilled team members expands the practice of business analysis beyond that of a single specialist role.

On agile teams, business analysis activities can be performed by one or a combination of:

a business analyst working on the team,
the customer representative or product owner, or
distributing these activities throughout the team.

Refer to the Agile Extension to the BABOK® Guide for more details.

.4 Business Analysis Outcomes

In an agile environment, business analysis brings people together and ensures that the right stakeholders are involved with the agile team at the right time. Open communication and collaboration is one of the principal outcomes of successful business analysis in an agile project.Business analysts ensure that the project's vision and direction are in strategic alignment to the organizational goals and business need. The business analyst holds shared responsibility in defining strategic criteria for project completion and during the project assists with defining acceptance criteria. They also facilitate the articulation of the product vision statement. The product vision statement is a common initial deliverable.

Documentation rigour and style is highly dependent on the purpose and the context in which it is produced. Agile approaches favour just enough and just-in- time documentation rather than establishing predefined models for documentation to be delivered. This documentation approach allows for the documents to incorporate as much of the change introduced as possible while keeping the cost of change low. Mandatory documentation, such as that required for auditing or compliance reporting, are still produced as part of each delivery cycle. It is important that documents address an identified need and deliver more value than the cost incurred to produce and maintain them.

11.1.3 Approaches and Techniques

.1 Approaches

Agile is an umbrella term for a variety of approaches. All agile approaches practice business analysis but only a few explicitly define the business analysis role. The primary characteristic of any agile approach is its alignment to the values and principles of the Agile Manifesto. An agile team may implement or evolve to use a combination of approaches which enables them to deliver value more effectively given their project type and work environment.

Table 11.1.1: Agile Approaches

Approach

Brief description

Crystal Clear

Part of a family of Crystal methodologies which are defined based on hardness and colour. The hardness refers to the business criticality or potential for causing harm, which amounts to more rigour and predictive planning being required as the criticality increases. Colour refers to the heaviness of the project across a number of dimensions including number of people required and risk elements in the project.

Disciplined Agile

Delivery (DAD)

A decision process framework which incorporates ideas from a variety of other agile approaches. It is intended to support a project from initiation through delivery. DAD is not prescriptive and allows for teams to customize their own life cycles and approaches.

Dynamic Systems Development Method (DSDM)

A project delivery framework which focuses on fixing cost, quality, and time at the beginning while contingency is managed by varying the features to be delivered. MoSCoW prioritization technique is used for scope management. Time boxes, or short focused periods of time with clearly defined outcomes, are used to manage the work.

Evolutionary Project Management (Evo)

A project management method for developing and delivering a system incrementally. It has a strong focus on quantifying value for multiple stakeholders and planning increments based on delivery of that value (which can be measured). It uses impact estimation tables as a formal technique for assessing solutions for their ability to deliver value to multiple stakeholders for a given cost.

Extreme

Programming (XP)

Named for the concept of taking beneficial software engineering techniques to the extreme. This concept focuses on the technical development processes and features pair-programming, test-driven development, and other craftsmanship approaches to the technical practices. XP technical practices are often used in conjunction with one of the agile management frameworks.

Feature Driven Development (FDD)

Focuses on a client valued functionality perspective to develop working software. For example, following a high- level scoping exercise, a feature list is identified and all planning, design, and development are performed based on feature sets.

Kanban

Does not require fixed iterations. Work moves through the development process as a continuous flow of activity. A key feature is to limit the amount of work underway at any one time (referred to as the work in progress limit or WIP). The team works only on a fixed number of items at any one time and work may begin on a new item only when it is required to maintain flow downstream and after the previous item has been completed.

Scaled Agile Framework® (SAFe™)

A framework for implementing agile practices at enterprise scale. It highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team to program to the enterprise level.

Scrum

A lightweight process management framework based on empirical process control. Work is performed in a series of fixed length iterations, called Sprints, which last one month or less. At the end of each sprint the team must produce working software of a high enough quality that it could potentially be shipped or otherwise delivered to a customer.

.2 Techniques

The following table lists techniques commonly used within agile approaches. Refer to the Agile Extension to the BABOK® Guide for a more detailed description of these techniques.

Table 11.1.2: Techniques used within Agile Approaches

Technique	Brief Description
Behaviour Driven Development (BDD)	An approach that enhances the communication between stakeholders and team members by expressing product needs as concrete examples.
Kano Analysis	A technique for understanding which product features will help drive customer satisfaction.
Lightweight Documentation	A principle that governs all documentation produced on an agile project. The purpose is to ensure that all documentation is intended to fulfill an impending need, has clear value for stakeholders, and does not create unnecessary overhead. For example, a system overview document may be written towards the end of a project based on stable content and acceptance tests written as part of the product testing.
MoSCoW Prioritization	A method to prioritize stories (or other elements) in incremental and iterative approaches. MoSCoW (must have, should have, could have, won’t have) provides a way to reach a common understanding on relative importance of delivering a story or other piece of value in the product.
Personas	Fictional characters or archetypes that exemplify the way that typical users interact with a product.
Planning Workshop	A collaborative workshop that is used to allow an agile team to determine what value can be delivered over a time period such as a release.
Purpose Alignment Model	A model that is used to assess ideas in the context of customer and value.
Real Options	An approach to help people know when to make decisions rather than how.
Relative Estimation	Team estimation techniques using either story points, which represent the relative complexity of a user story to develop, or ideal days, which represent the amount of total effort a story would take to develop.
Retrospectives	A similar term for the Lesson Learned technique. Retrospectives focus on continuous improvement of the teamwork process and are held after every iteration on agile projects.
Story Decomposition	Ensures that the requirements for a product are represented at the appropriate level of detail and are derived from a valuable business objective.
Story Mapping	Provides a visual and physical view of the sequence of activities to be supported by a solution.
Storyboarding	Detail visually and textually the sequence of activities that represent user interactions with a system or business.
Value Stream Mapping	Provides a complete, fact-based, time-series representation of the stream of activities required to deliver a product or service to the customer.

11.1.4 Underlying Competencies

Agile is a mindset. Agile business analysts embody the values and principles of the Agile Manifesto which are based on a humanistic view of product development as a process founded in communication and collaboration. Refer to the Agile Extension to the BABOK® Guide for a description of the principles for business analysts. In adopting the agile mindset and philosophy, the business analyst develops competencies in:

Communication and collaboration: the ability to communicate the sponsor’s vision and needs; assist in influencing others to support the vision; participate and possibly facilitate negotiation of priorities; and facilitate collaborative agreement on solution outcomes.
Patience and tolerance: the ability to maintain self-control under pressure and keep an open mind when interacting with others.
Flexibility and adaptability: cross-functional skill sets that allow the business analyst to step outside their specialization in order to support other team members.
Ability to handle change: the ability to quickly assess the impact of change and determine what provides business value amongst frequently changing requirements, and assisting with, or maintaining, the re- prioritization of the to-do work list.
Ability to recognize business value: the ability to understand how changes and new features can achieve business value and support the vision.
Continuous improvement: periodically review with the agile team how to become more effective.

11.1.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within agile are mapped to business analysis tasks and practices as defined by the BABOK® Guide. It also describes how each knowledge area is applied or modified with the agile discipline.

Each knowledge area lists techniques relevant to an agile perspective. BABOK® Guide techniques are found in the Techniques chapter of the BABOK® Guide. Agile Extension techniques are discussed in detail in the Agile Extension to the BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

In agile approaches, detailed business analysis planning can be deferred until work on an activity is ready to begin rather than done upfront as in predictive projects.

An initial plan for business analysis activities is developed at the beginning of the project. The plan then gets updated prior to the start of each cycle to account for change and to ensure that the plan is always up to date. Stakeholder involvement and engagement is key to the success of agile projects. Business analysts proactively plan to involve, engage, and collaborate with stakeholders. Communication is commonly much less formal and business analysis deliverables are often interactions and collaboration with less emphasis on the written documents.

BABOK® Guide Techniques

Agile Extension Techniques

Lightweight Documentation
MoSCoW Prioritization
Personas
Relative Estimation
Retrospective

.2 Elicitation and Collaboration

Progressive elicitation and elaboration occur throughout an agile initiative. The most common pattern is an initial elicitation activity that establishes the high-level vision and scope of the solution, and an initial milestone-based plan for the delivery of the product. In every cycle there is more detailed elicitation for the backlog items that will be developed in that cycle. The intent of elicitation activities is to generate just enough detail to ensure that the work at hand is performed correctly while aiming towards the goals. Agile approaches aim to minimize the time between the elaboration of needs and their implementation in the solution. There is a strong focus on collaborative
elicitation approaches such as workshops with stakeholders.

BABOK® Guide Techniques

Agile Extension Techniques

Behaviour Driven Development
Lightweight Documentation
Persona
Storyboarding
Story Mapping

.3 Requirements Life Cycle Management

As agile initiatives unfold, the scope is defined with increasing specificity. The expectation is that the needs will change and that the design will evolve over the course of the project. Prioritization of features based on value and development priority drives the work done in each cycle. Validation of the evolving solution with the stakeholders occurs at the end of every iteration in place of a formal requirements approval process.

BABOK® Guide Techniques

Agile Extension Techniques

Kano Analysis
MoSCoW Prioritization
Story Decomposition
Story Mapping

.4 Strategy Analysis

Agile approaches are often used when there is uncertainty about the needs, the solution, or the scope of change. Strategy analysis is a constant part of an agile initiative to ensure that the solution delivered continues to provide value to stakeholders. Agile team members use strategy analysis to help understand and define product vision, and develop and adjust the development roadmap, in addition to conducting ongoing assessments of related risks. For every iteration, the proposed solution is reassessed against the current business context to ensure that it will effectively meet the business goals. The adaptive nature of agile projects means that adapting the project to changes in the organization's goals is not disruptive; rather, it is an expected part of the process.

BABOK® Guide Techniques

Agile Extension Techniques

Kano Analysis
Personas
Purpose Alignment Mode
Concept Modelling
Metrics and Key Performance Indicators (KPIs)
Scope Modelling
Workshops
Real Options
Value Stream Analysis

.5 Requirements Analysis and Design Definition

Needs are progressively elaborated during an agile project. Analysis and design are performed on a just-in-time basis, either just before or during the iteration in which the solution component will be developed.

Analysis performed just before the iteration is to provide the team with enough information to estimate the planned work. Analysis performed during the iteration is to provide the team with enough information to construct or deliver the planned work.

Models and other analysis and design techniques are typically used informally, and may not be maintained once they have served their purposes. The analysis and design approach used should support progressive elaboration, be adaptable to change based on learning, and not cause the team to select solutions prematurely. Agile teams tend to use user stories at the lowest level of decomposition, usually supported by acceptance criteria which capture the analysis and design details regarding how the stories should behave when implemented. Validation of the evolving solution is performed with stakeholders at the end of every iteration.

BABOK® Guide Techniques

Agile Extension Techniques

Behaviour Driven Development
Kano Analysis
Lightweight Documentation
MoSCoW Prioritization
Purpose Alignment Model
Real Option
Story Decomposition
Story Elaboration
Story Mapping
Storyboarding
Value Stream Analysis

.6 Solution Evaluation

Throughout an agile project, the stakeholders and agile team continually assess and evaluate the development solution as it is incrementally built and refined. Evaluation of the evolving solution with the stakeholders occurs at the end of every development cycle to ensure the deliverable meets their needs and satisfies their expectations. The business analyst ensures that the product meets expectations before a product is released, and identifies new opportunities that will add value to the business.

BABOK® Guide Techniques