Agile Requirement Development - A Breathtakingly Quick Introduction

Agile Requirement Development

A Breathtakingly Quick Introduction

By Juhani Lind, Agile Trainer and Coach

Positioning Requirements and Agility

• Neither of the extremity is great

• Requirements seldom have absolute value in themselves!

• The primary goal should always be to target the working solution

• Requirements and specifications are an invaluable vehicle to achieve this

since the WHAT question stills needs to be answered before HOW

Start coding NOW.

I check what the

customer wants.

Wait … WAIT.

I need to first

figure out ALL the

requirements.

v 1.0 Agile Requirement Development

2

Agile or Not – The System Context Matters!

v 1.0

3

System

Under

Development

Constraints.

Standards.

Regulations.

Legislation.

Features.

Functionality.

Quality Requirements.

Security.

Data Requirements.

External Interfaces.

Services.

Business Opportunities.

Business Needs.

Stakeholders.

User Roles.

Personas. Processes.

Business Rules.

User Experience.

User-Interface.

Reports.

External/Internal Events.

State Transitions.

Traceability.

System Life-Cycle.

Maintenance.

System Criticality.

Development Risks.

System Size.


Examples Agile Practices On Different Levels

v 1.0

4

Steering Development

For example Scrum and Kanban:

Definition of Done, Product Owner, Review Meeting, Retrospective, Vision …

Common Practices

Agile Modeling, Daily Meeting, Effort Estimation, Pair Working,

Prioritization, Provide Continuous Feedback, Test Automation, Test-First Strategy …

Architecting

Design

Implementation

Testing Requirement

Development

Acceptance Criteria/Tests

Definition of Ready

Illustrating with Examples

Specifying Collaboratively

Splitting Requirements

Validating Frequently

Coding Standards

Continuous Integration

Refactoring

Test Driven Development

…

Agile Test Strategy

Exploratory Testing

…


Requirement

Specification

Requirement

Analysis

Requirement

Elicitation

(Discovery)

The Good Old Requirement Development

Activities Are Still Here!

v 1.0

5


Applying Agility To The Activities!

v 1.0

6

Performing activities

just-in-time.

Eating the elephant

one piece at a time.

Activities are

a team effort

involving all the roles.

1

2

3

4

Ruthlessly prioritizing

the requirements.

Writing requirements

in a concise way

favouring

- pictures

- charts, diagrams

- lists

- tables

over long text.

Clarifying and refining

requirements by

discussing with

customer representatives.


Enabling Smooth Development

v 1.0

7

Analyze.

Specify.

Design.

Build.

Test.

Analyze.

Specify.

Design.

Build.

Test.

Next Backlog Item

Look for opportunities to develop a single requirement in small pieces

and to get feedback.


Example:

Scrum and Requirement Development

Potentially

shippable

increment of

functionality

Retrospective 8

Sprint planning

Product

Backlog

Sprint

Backlog

Daily

Scrum

1.A… 8

2.B… 13

3.C… 5

4.D… 20

5.E… 13

6.F… 40

7.G… ?

1.A… 8

2.B… 13

3.C… 5

Plan

Sprint review

(Elicitation)

Analysis

Specification

Elicitation, Validation

(Elicitation)

Analysis

Specification

Elicitation


8

Classic Requirement Modeling Techniques

• There are plenty of modeling techniques that help analyze and

understand requirements

• These are applicable also to Agile Requirement Development

v 1.0

9

Context Diagram.

Process Maps.

Process Diagrams.

Activity Diagrams.

Prototypes.

UI Wireframe.

Entity/Relationship Diagrams.

Class Models.

Class-Responsibility-Collaboration (CRC) Cards.

Event-Response Tables.

Decision Tables.

Decision Trees.

Feature Trees.

Use Case Diagram.

Story Map.

Dialog Map.

Examples.

Scenarios.

Sequence Diagrams.

Collaboration Diagrams.

State Diagrams.

Timing Diagrams.


Agile Modeling Principles and Practices

Supporting Requirement Analysis

Principles

• Assume Simplicity

• Embrace Change

• Enabling the Next Effort is Your

Secondary Goal

• Incremental Change

• Maximize Stakeholder ROI

• Model With a Purpose

• Multiple Models

• Quality Work

• Rapid Feedback

• Working Software Is Your Primary

Goal

• Travel Light

Practices

• Active Stakeholder Participation

• Apply the Right Artifact(s)

• Collective Ownership

• Create Several Models in Parallel

• Create Simple Content

• Depict Models Simply

• Display Models Publicly

• Iterate to Another Artifact

• Model in Small Increments

• Model With Others

• Prove it With Code

• Single Source Information

• Use the Simplest Tools

v 1.0

10

Source: Agile Modeling website http://www.agilemodeling.com/


Practice:

Specifying Collaboratively

• Requirements development is

like any other development

activity – a team effort

• Every team member can

contribute!

• A great way to build a shared

understanding among all parties

involved in the development

• What needs to be accomplished

• Covering all the different

aspects of a system

• Collaboration leads to

requirements that are easy to

understand

• Typical collaboration models:

• All-Together Workshops

• Small Workshops

• One representative from every

development discipline

• Pair Writing

• Frequent, informal discussions

with Customer Representatives

• Choosing an appropriate model

• The maturity of the product

• The level of domain knowledge

in the team(s)

• Estimated analysis effort

• How readily Customer

Representatives are available

v 1.0

11


Practice:

Splitting Requirements • Originally requirements may be

large and vague (so-called epics)

• But eventually requirements should be small and compact enough to enable estimation and development

• Appropriately sized requirements improve transparency, manageability and steering

• That is enhanced risk management!

• Nevertheless each split requirement has to deliver valuable functionality for the customer

• Different ways to split requirements are for example

• By workflows

• By usage scenariosn

• By input, output and configuration types

• By data presentation formats

• By data classification

• By creating, searching, updating and deleting data

• By user roles

• By system operations

v 1.0

12


Practice:

Acceptance Criteria • A classic, but sadly forgotten,

requirement for requirements and features is they can be verified and preferably validated as well

• Building the right thing the right way –thinking

• Acceptance criteria capture how the customer knows that a requirement or a feature works as intended

• Conditions that software must satisfy to be accepted

• Explicitly stated criteria are a quality tool for knowing what needs to be accomplished

• Acceptance criteria assist in writing high-quality specifications because they force developers to think what is truly needed or required

• Acceptance criteria can address both functional and non-functional (quality) aspects

• The SMART acronym might be used as a guidance for writing great acceptance criteria

• Specific – Measurable – Achievable – Relevant – Time-bound

• Acceptance criteria can be elaborated to automated acceptance tests

v 1.0

13


Practice:

Illustrating with Examples

• Examples are actually used almost automatically when

discussing requirements!

• The power of the examples in Requirement Development

is based on

• understandability

• ability to dispel ambiguities

• possibility to enhance communication and collaboration

• ability to make requirements concrete and inspire discussion

v 1.0

14

• A good example to illustrate and clarify a requirement should be

• accurate and precise

• complete and comprehensive

• as concrete as possible

• realistic

• and understandable to

different stakeholders


Journey To Done via Definition of Ready


15

Definition of Ready targets to ensure that the

specification for a Product Backlog Item is good

enough in terms of further development

• Understood well enough

• Granular enough for planning and design

Getting Started with


v 1.0

16

Apply the Agile Principle #12!

• Regular retrospective meetings are great places to discuss and analyze

• What is working

• What is not working

• What could be improved

• What should we start doing

• What should we stop doing

• What have we learnt

• W Edward Deming’s PDCA Cycle is a useful tool for continuous improvement

• P = Plan

• D = Do

• C = Check

• A = Act

12. Team reflects regularly

where and how to improve


17

Few Suggestions How to Proceed

v 1.0

18

Keep the Improvement Backlog public

Tackle only few improvements at a time

Have courage to experiment

Proceed with small steps to get feedback and to learn

Remember to celebrate successes!


Involve All Stakeholders to Get

Feedback and Comments

v 1.0

19

Customer

Representatives Requirement

Engineering

Architecting

Design

Implementation

Testing

Maintenance

Application Management


Helsinki, Tampere, Tukholma, Göteborg

Thank You!

For further information please visit us at

www.tieturi.fi

and

Agile Requirement Development Course (in Finnish)


v 1.0

20

http://www.tieturi.fi/

http://www.tieturi.fi/haku.html?qc=ketter%C3%A4+m%C3%A4%C3%A4rittely&start=&end=&place=&scat=

Technology

Agile Requirement Development - A Breathtakingly Quick Introduction