Chapter 11 – 11.1 – The Agile Perspective – Part 3/3

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.

Approach Brief description
Crystal Clear Part of a family of Crystal methodologies which are defined based on hardness and color. The hardness refers to the business criticality or potential for causing harm, which amounts to more rigor and predictive planning being required as the criticality increases. Color 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.

Table 11.1.1: Agile Approaches

.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.

Technique  Brief Description
Behavior 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.

Table 11.1.2: Techniques used within Agile Approaches

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 reprioritization 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

  • Backlog Management (p. 220)
  • Collaborative Games (p. 243)
  • Estimation (p. 271)
  • Metrics and Key Performance Indicators (KPIs) (p. 297)
  • Mind Mapping (p. 299)
  • Prioritization (p. 311)
  • Scope Modelling (p. 338)
  • Stakeholder List, Map, or Personas (p. 344)
  • User Stories (p. 359)
  • Workshops (p. 363)

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

  • Acceptance and Evaluation Criteria (p. 217)
  • Backlog Management (p. 220)
  • Brainstorming (p. 227)
  • Collaborative Games (p. 243)
  • Concept Modelling (p. 245)
  • Interface Analysis (p. 287)
  • Mind Mapping (p. 299)
  • Non-Functional Requirements Analysis (p. 302)
  • Process Modelling (p. 318)
  • Prototyping (p. 323)
  • Reviews (p. 326)
  • Scope Modelling (p. 338)
  • Stakeholder List, Map, or Personas (p. 344)
  • Use Cases and Scenarios (p. 356)
  • User Stories (p. 359)
  • Workshops (p. 363)

Agile Extension Techniques

  • Behavior Driven Development
  • Lightweight Documentation
  • Personas
  • 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

  • Acceptance and Evaluation Criteria (p. 217)
  • Backlog Management (p. 220)
  • Collaborative Games (p. 243)
  • Prioritization (p. 311)
  • Reviews (p. 326)
  • Workshops (p. 363)

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

  • Backlog Management (p. 220)
  • Brainstorming (p. 227)
  • Business Capability Analysis (p. 230)
  • Collaborative Games (p. 243)
  • Concept Modelling (p. 245)
  • Metrics and Key Performance Indicators (KPIs) (p. 297)
  • Scope Modelling (p. 338)
  • Workshops (p. 363)

Agile Extension Techniques

  • Kano Analysis
  • Personas
  • Purpose Alignment Model
  • 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

  • Acceptance and Evaluation Criteria (p. 217)
  • Business Capability Analysis (p. 230)
  • Business Rules Analysis (p. 240)• Collaborative Games (p. 243)
  • Concept Modelling (p. 245)
  • Interface Analysis (p. 287)
  • Non-Functional Requirements Analysis (p. 302)
  • Prioritization (p. 311)
  • Process Analysis (p. 314)
  • Process Modelling (p. 318)
  • Scope Modelling (p. 338)
  • Use Cases and Scenarios (p. 356)
  • User Stories (p. 359)
  • Workshops (p. 363)

Agile Extension Techniques

  • Behavior Driven Development
  • Kano Analysis
  • Lightweight Documentation
  • MoSCoW Prioritization
  • Purpose Alignment Model
  • Real Options
  • 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

  • Acceptance and Evaluation Criteria (p. 217)
  • Business Capability Analysis (p. 230)
  • Metrics and Key Performance
    Indicators (KPIs) (p. 297)
  • Non-Functional Requirements Analysis (p. 302)
  • Process Analysis (p. 314)
  • Prototyping (p. 323)
  • Reviews (p. 326)
  • Stakeholder List, Map, or Personas (p. 344)
  • Use Cases and Scenarios (p. 356)
  • User Stories (p. 359)
  • Workshops (p. 363)

Agile Extension Techniques

  • Personas
  • Value Stream Analysis

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *