Requirements in Agile(Brief Introduction)

Presented by Razvan Radulian

- ASPE Training -

Why [so many] Agilists are [so] wrong…

badges

“We don’t need no stinking… documentation!”

… REALLY?!?

Traditional/Waterfall or Agile…

Requirements are stillREQUIREMENTS!

Regardless of…

• Project methodology and/or mindset

• Who “does” them (having or not having the Business Analyst title)

Traditional/Waterfall AND AgileCommon attributes (regarding Business Analysis/Requirements)

A Requirement is…

An expectation about a system/solution, in regards to:

• What a Business organization wants to achieve

• What a User’s goals are & what s/he needs to do to achieve them

• Other Stakeholders’ interests, concerns, and/or rules regarding the system/solution under design

• What the system/solution should do (to achieve all of the above)

A [BA] Requirement is not…

• Technical specification

• Testing plans & test cases

• Project requirements

There are 3 Requirement Levels…

“Business Requirements”/Objectives

Stakeholder/User Requirements

Solution Requirements

…multiple Requirement Types…

Source: Why-What-How Consulting

Ho

w

Solu

tion

Wh

at

Sta

kehold

er/

user

Wh

y

Busin

ess

StaticBehavior

External Interfaces

Functions

Design Constraints

Quality AttributesData

ProcessesBusiness

Rules

Solution Ideas

Objectives(SMART)

Scenarios

… and many Requirement Formats!

• Process Models:• BPMN Process Models• Activity Diagram (UML)• Workflows/Flowcharts…• Use Cases/Scenarios• User Stories (3Cs)

• Business Rules:• Policies• Decisions/Rules• Guidelines

• Data:• Conceptual & Logical Data Models• Class Diagrams (UML)• Entity Relationship Diagram (ERD)

• Function(al) Reqs [“system shall…”]

• Other Non-Function(al) Reqs• Quality Attributes• Design Constraints• External Interfaces

• Transition Requirements

We [still] need “a” VISION…

Product Vision: WHAT we want…

Project Vision: …HOW we’ll build it!

… and a ROADMAP!

Stepping [mile]stones: •What we’ll build

•The order in which we’ll build them

•When we intend to build them

BABOK® Knowledge Areas still apply…Business Analysis

Planning and Monitoring

Strategy AnalysisRequirements

Analysis and Design Definition

Solution Evaluation

Elicitation and Collaboration

Requirements Life Cycle Management

Refers to BABOK Guide v3, Figure 1.4.1, Page 5

And so does theBACCM™… Change

ValueWHAT

ChangeWHY

Value

Let’s look at an Example!

● ATM, 1950s…

Let me tap into your imagination…

Imagine…● It’s 1950s

● You are a small local bank with

very happy customers

● Business hours: Mon-Fri, 9 – 5

● Customers must come inside the

bank and work with very friendly

Tellers

HOWEVER…

Just across street (or across town):

● Your main competitor has built

an ATM outside the bank

● Customers can withdraw cash at

the ATM, 24/7

● Each passing month, 5 to 10% of

your customers are switching to

your competitor

What would you do…

… to stop “bleeding” (i.e. losing customers)?

You MUST build an ATM, too!

Or, do you?

What’s the Business (i.e. Bank) trying to achieve?

Business Requirements/Objectives (S.M.A.R.T., right?):• Retain 90% of existing customers over 1 year period

• Attract 1000 new customers over next 2 years

• Increase customer satisfaction… how will we measure that? <TBD>

• Increase Tellers productivity by• 15% over 6 months• 20% over 1 year

• Reduce operational costs by 16.67% over 1 year

… are all these requirements EQUAL?

What’s our VISION for a fully-functional ATM?

Customers will be able to:

• Deposit money (cash, checks)• Withdraw cash (up to $500/day)

• Transfer money:• Between account• To/from other banks

• Check balance

• Get tickets at local concerts

• Buy stamps• Get coffee while waiting

• Reset phone PIN

• Get Annual Tax Mini Report…

Other requirements/features:

• ATM must authenticate/authorize users

• Intuitive, easy to use

• Access 24/7

• Fast (e.g. dispense cash within 30 sec)

• Data must be private and secure• Safe to use

• Robust (e.g. 30-minutes on own power source)

• Recover within 15-minutes after longer power outages

• …

Other requirements?

Business Data

• Customer info

• Account info

• Transaction info

• Partner Bank info

• Local concerts info

• Stamps info

• ….

Business Rules

• Max. $200 withdrawal/transaction

• Max. $500 withdrawal/day

• Lock account after 3 failed login attempts

• Audit & logout after Timeout

• Timeout = 10-minutes of inactivity

• Must provide zip code and phone# when requesting new PIN

So far, no difference between Traditional/Waterfall & Agile Requirements• Project/Business Objectives:

• e.g. Retain 90% of existing customers over 1 year

• Stakeholder/User Requirements [high-level]:• e.g. Customer withdraws cash

• e.g. ATM users must be authenticated/authorized

• Other requirements (e.g. Data, Business Rules, Quality Attributes) [high-level]

• e.g. Account info (account number, status, type, etc.)

• e.g. Cannot withdraw more than $500/day

• e.g. Must be available 24/7

Traditional/Waterfall vs. AgileDifferences between Traditional and Agile methodologies

Filling the Requirements Pyramid…

Traditional/Waterfall• By level/layer (top to bottom)

Agile• By slices (top to bottom)

Requirements Horizon…

Traditional/Waterfall• All requirements at same level

Agile• Elaborated/clarified over time

FOREST

FOREST

TREE

GREEN(Grass? Forest?)

MOUNTAIN

“All” Requirements (over time): Cone of Uncertainty

Un

cert

ain

ty

Time

Requirements Focus/clarity (over time)…Fo

cus/

clar

ity

Time

Requirements should be…

•Clear•Correct•Consistent•Complete•Concise

In Traditional/Waterfall:• ALL Requirements• ALL Up-front

• Same level of details (as much as possible): [Forest]

In Agile:• Based on Priority

• Just-in-time (BA 1+ cycles ahead of Dev Team)• Level of details:

• Near-future: a lot more than T/WF [Trees with flowers & leaves]

• Far in the future: a lot less than in T/WF[Trees, Forest, Green “stuff”]

ATM: Epics/Stories, Themes (Vision to Roadmap)

Goal: Withdraw $:Iteration 0:

- Convert accounts

- Generate ATM profiles

Iteration 1:- Login (valid credentials)

- Logout

Iteration 2:- Login (invalid credentials)

- Validate available funds

Iteration 3:- Check max. withdrawal/day

- Handle “blocked” account

Iteration 4:- Debit account

- Generate Mini-statement

Goal: Deposit $

Epics:- Deposit by cash

- Deposit by check

- Deposit by card

Goal: Xfer $

Epics:- Between accounts

- Between banks

Goal: Delighters…

Options:- Buy tickets at local

concert

Usability

Data privacy & security

Annual Report

Release 1/Qtr 1 Release 2/Qtr 2 Release 3/Qtr 3 Release 4/Qtr 4

… and Themes

Some Common Agile Myths(about Requirements)

T/WF: Use Cases vs. A: User Stories

• As high-level requirements, Use Cases and User Stories are very similar:• [UC] Withdraw money (Primary Actor: Customer)• [US] As Customer I want to withdraw money so I can pay cash when bank is closed

• As elaborated requirements:• Use Cases are elaborated and documented into Scenarios:

• Main Success Scenario• Alternate Scenario(s)• Exception Scenario(s)

• User Stories are also elaborated (in Conversation), but they may not be fully documented (pro and post-conditions should be captured as Acceptance Criteria)

There is nothing preventing Agile teams from documenting requirements in Use Cases/Scenarios!

User Stories vs. Tasks

User Stories:• Describe User’s goals:

“As a CustomerI want to withdraw moneyso I have cash when bank is closed”

• Captured/managed in the Product Backlog

• Owned/managed by Product Owner

Tasks:• To develop “Withdraw money” User

Story:• David will create table XYZ [est. 2 hrs]• Dana will write the Debit() function [est.

3-hrs]• Tess will write Test Case TC-067 [est. 1 hr]• Tim will execute TC-067 [est. 30 min]• Betty-Anne will update Training manual

[est. 2 hrs]

• Capture in the Iteration Backlog

• Owned/managed by Development Team

As a Customer

I want to login w. card/PIN

so that I can use the ATM

SP: 5

As a <user>

I want to <action>

so that <goal>

SP: ?

As a <user>

I want to <action>

so that <goal>

SP: ?

Epic example:

To Do Doing Done

As a Customer

I want to buy tickets

so that <goal>

SP: ?

Story Boards

As a Customer

I want to deposit

Travel checks

so that …

SP: 40

As a Customer

I want to deposit check

so that I can increase funds

SP: 13

As a Customer

I want to deposit cash

so that …

SP: 20

As a Customer

I want to deposit money

so that I can...

SP: 100

As an Admin

I want to create ATM acct.

so that Customer can

access his/her account

SP: 5

PRODUCT BACKLOG:

As a Customer

I want to login w. card/PIN

so that I can use the ATM

SP: 5

Anna:

2 hr

To Do Doing Done

Story/Task Board (aka “Kanban” Board …but not really a Kanban board!)

Anna

David

Ina

Tess

Team

members:

As a Customer

I want to deposit check

so that I can increase funds

SP: 13

David:

3 hrs

Tess:

4 hrsAs an Admin

I want to create ATM account

so that Customer can use the

account

SP: 5

Andy:

1 hr

Dan:

8 hrsTess:

6 hrs

SPRINT

BACKLOG:

Team velocity: 25 SPs

Andy

Dan

Tim

User Stories: 3 = 4?

User Stories’ 3 Cs:

• Card

• Conversation

• Confirmation

Actually…

• Conversation = 2 Conversations• Product Owner with Business Stakeholders

• Product Owner with Dev. Team

When do Product Owner/BA elaborate the User Stories/Requirements?Myth:

• During current iteration/sprint

Reality (if done right):

• 1-2 iterations/sprints ahead of the current iteration/sprint (during BA & Sprint Refinement/Grooming)

Sprint Activities2 weeks iteration example

Daily

Scrum

Daily

Scrum

Daily

Scrum

Daily

Scrum

Daily

Scrum

Daily

Scrum

Daily

Scrum

Daily

Scrum

Self-organized/

managed work

Self-organized/

managed work

Product Backlog

Grooming (1-2 hrs.)Product Backlog

Grooming (1-2 hrs.)

Spri

nt P

lan

nin

g

2-4

hrs

.

Revie

w

1-2

hrs

.

Dem

o

1 h

r.

Retr

osp

ective

1 h

r. W

ee

k-e

nd

Wrap-up: We only scratched the tip of the iceberg…There is a lot more to Agile Requirements!

Q&A, Contact…• Q&A:

Live or send me an email

• ASPE Training’s 2-day “Collaborating and Communicating Agile Requirements” class:

http://aspetraining.com

• Contact:

Razvan Radulian

razvan@why-what-how.com

Thanks :-)