Get Real Using Examples

In agile approaches, in order to elicit and validate product needs business analysis practitioners use real customer examples to communicate with the team, including the customer. Real examples serve to bridge understanding of the customer's business and how they see the product serving a future state need. Analysis models can be concurrently developed and elaborated using these same examples.

Models may be useful for the team but examples are more concrete for the customer. The techniques are used iteratively by alternating between examples and analysis models to explore multiple

dimensions (for example, user role, user actions, data, and business rules) of a product need. This is a continuous practice that builds a shared team understanding of product needs useful for both planning and delivery. These techniques engage customers in requirements elicitation, analysis, and validation.

Examples and models should be at a level of granularity that is appropriate for the outcome you seek. When planning the product, models are used to set context and help the team and customer identify scope. These models are more abstract and provide a broad perspective of the problem domain. When delivering the product, the same model can be progressively elaborated and related examples are elicited and specified to launch into a deeper discussion of the

dimensions. The examples can be used to derive acceptance criteria,

The Delivery Framework Agile Techniques

help the developer design the solution, and provide a foundation for functional testing.

The following sections describe commonly used techniques for this principle:

• Behaviour Driven Development.

There are other techniques within the Agile Extension to the BABOK^® Guide, the BABOK^® Guide, and other ad hoc techniques that can be utilized here as well.

.1 Behaviour Driven Development (BDD) Purpose

An approach that enhances the communication between stakeholders and project team members by expressing product needs as concrete examples.

Description

Traditional business analysis techniques often involve creating analysis models. In addition to analysis models, agile techniques favour communication using examples which are more concrete for the customer. Many people are uncomfortable with abstractions and prefer to work with real examples.

Examples tend to be additive (growing in both clarity of the need and detail of the solution as the project progresses) and can form a

specification. They can be used during agile planning and delivery work to help clarify and describe the requirements for the product being built. As models change, examples can be refined by building on previous examples. In agile, it is helpful to iterate between using examples and analysis models encouraging them to compliment each other. Progressive elaboration leads to richer exploration of multiple dimensions (for example, user role, user actions, data, and business rules) related to the example.

Supplementing product need discussions with examples creates a much more stable set of requirements than using a model alone.

Examples feed smoothly into a behaviour/test driven development approach.

Agile Techniques The Delivery Framework

Elements Examples

Examples may also be known as scenarios. Examples should not be artificial or made up. They should be real life business scenarios provided by the business users. Business analysis activities help to facilitate the discovery of the examples and ensure that the set of examples is comprehensive. Not all examples identified will necessarily be within the scope of a development effort.

Behaviour Driven Development

Behaviour driven development provides a simple grammar format that allows real scenarios to be filled in. This takes the form

• GIVEN <a context>

• WHEN <an event>

• THEN <an outcome>

Both GIVEN statements and multiple THEN outcomes for a single scenario could be compound conditions linked with AND statements.

There is normally only one WHEN event that triggers the scenario.

For example, an ATM.

Scenario 1: Account has sufficient funds.

• GIVEN: I'm in credit

• AND the ATM has sufficient cash available

• WHEN: I request $20

• THEN: I receive $20

• AND: my account balance is reduced by $20

• AND: my card is returned

Scenario 2: Account has insufficient funds.

• GIVEN: I'm in overdrawn

• AND the ATM has sufficient cash available

• WHEN: I request $20

• THEN: I receive no money

• AND: my card is returned

Scenarios that are written in a behaviour driven development format specifying events, conditions, and actions are verifiable. They can serve as acceptance criteria for stories [See “Story Elaboration” on

The Delivery Framework Agile Techniques

page 68] and serve as tests in support of Acceptance Test Driven Development (ATDD) that drive a common understanding of requirements and future product needs.

The terms BDD, ATDD, and Specification by Example tend to be used interchangeably in general use.

Testing

There are now a number of software products that will take examples in this format (but may have their own specific syntax and structure) and allow them to be easily converted into automated tests, thus enabling more agile delivery. With a comprehensive set of examples that can be executed as automated tests, business analysis and testing activities can be more tightly coupled.

Usage Considerations

BDD is a technique to make needs clear and is designed to improve communication and understanding across all members of a project team. Technical team members use the examples to understand what the product needs to do (development) and how to ensure that it does what is needed (testing). Customer representatives provide the

examples and clarify their thinking by doing so. Business Analysis entails identifying the scenarios by asking many “what‐if” question to expose additional scenarios and expressing these as additional

examples.

Advantages

• BDD expresses customer needs in natural language, in a format that all team members should be able to easily understand.

• The structure of BDD lends towards acceptance test automation and supports the production of effective test cases.

• Tools exist to support the use of BDD in projects, and these provide additional metrics such as test case coverage or requirements.

• Scenarios can be easily prioritized which supports the iterative, incremental nature of agile projects.

Disadvantages

• It is possible to miss important scenarios unless there is someone who actively asks the “what if” and “what about” questions.

• Where business rules are very complex there could be too many scenarios to easily manage and track without tool support.

Agile Techniques The Delivery Framework