Agile requirements, slide archive

© 2014 Tom Grant

Requirements on the verge

of a nervous breakdownTom Grant

Senior Consultant

Agile 2014

© 2014 Tom Grant

Thank You!

Tom Grant

[email protected]

@TomGrantPhD

2

© 2011 Israel Gat


100% of ALM

assessments

uncover

serious

problems

that start in

requirements

© 2011 Israel Gat 5

Stakeholders want more from their

© 2011 Israel Gat


“Which of the following technology

inititiatives are you asking IT to prioritize over

the next 12 months?”0% 10% 20% 30% 40% 50% 60%

Improve the use of data and analytics to improve business

decisions and outcomes

Improve IT project delivery performance

Develop new skills to better support emerging technologies and

business innovation

Help the organization better manage and integrate its partners

and suppliers

Improve IT budget performance

High priority

Critical priority

Base: 3,616 business decision-makers world-wide.

Source: Forrsights Business Decision-Makers Survey Q4 2012

Business needs results from software investments.

Right now.

© 2011 Israel Gat


“For each pair of statements, which best describes your firm?”

Base: 3,616 business decision-makers world-wide.

Source: Forrsights Business Decision-Makers Survey Q4 2012

Our business environment/industry

is stable / Our business

environment/industry is rapidly

changing

19% 32% 49%

Stable Industry Changing

Business processes are consistent

across groups / Business processes

are diverse across groups

22% 35% 43%

Consistent Neutral Diverse

Not just any software will do.

© 2014 Tom Grant

“How would you rate the quality of your team’s working

relationship with other parts of your company?”

0.0% 20.0% 40.0% 60.0% 80.0%

Testing/QA

Other development teams

IT operations

Product management

Business users

Support/help desk

Executive management

Business analysts

Business unit managers

Enterprise architecture

Security/risk management

Marketing

Program/portfolio management …

4

5 (Very good)

Base: 1,614 software development professionals.

Source: Forrester Q4 2012 Developer Survey

Software professionals don’t have a great affinity with the business.

© 2011 Israel Gat

Requirements need attention right now

Source: Q1 2011 Global Application Development & Delivery Organization

Structure Online Survey; Getty Images (http://www.gettyimages.com)

Improving requirements cited more frequently (66%) than any other area needing attention

© 2011 Israel Gat


Agile has accelerated this crisis

Can requirements

keep pace with

Agile?

© 2011 Israel Gat


AGILE PRACTICES

IN THE DEV TEAM

CONTINUOUS

DELIVERY

DEVOPS

REQUIREMENTS

© 2011 Israel Gat

Requirements often slow Agile teams

WATER SCRUM FALL

© 2011 Israel Gat


How do we avoid a breakdown?

© 2011 Israel Gat


1. Requirements must define value

2. Build better requirements toolkits

3. Find the right cadence

4. Ask more of requirements professionals

© 2011 Israel Gat

REQUIREMENTS MUST DEFINE

VALUE

© 2011 Israel Gat

We build software for people unlike us

© 2011 Israel Gat


Requirements explain value

› How software helps business outcomes

› What elements make it less helpful

› Why users adopt

› How users adopt

© 2011 Israel Gat

We need more regular feedback

© 2011 Israel Gat

Design thinking and visualization accelerate

feedback

© 2011 Israel Gat


We need better insights

© 2011 Israel Gat

Change the conversation

Android app for activity management

Custom pipeline stages

More complex lead-scoring options

More canned reports

Define and manage teams

Easy clean-up of bad or duplicate data

Activity entry via email

Associate teams with prospects

$5,000

$2,000

$3,500

$1,500

$4,750

$2,500

$3,250

$1,250

FEATURE COST-

$500

-

$300

$2,000

$2,500

-

-

SPENT

© 2011 Israel Gat

WE NEED BETTER

REQUIREMENTS TOOLKITS

© 2011 Israel Gat


Themes?

Epics?

Use

cases?

User

experience?

Visualization?

© 2011 Israel Gat

Requirements aren’t simple

Actionable

Contextual

Descriptive

What is the

customer

asking for?

How

should we

meet the

customer’s

request?

What is the customer really

asking for?

© 2011 Israel Gat

Actionable

Contextual

Descriptive

Translation is necessary

© 2011 Israel Gat

Requirements are a toolkit

Actionable

Contextual

Descriptive

User

stories

Personas, use

cases, busine

ss problems

Themes, e

pics

Enhancem

ent

requests, c

hange

requests, i

deas

Traditional

requiremen

ts

© 2011 Israel Gat


The toolkit must evolve

Faster feedback

More reliable

feedback

Faster translation

Better

communication

Greater re-use

Visualizations, pr

ototypes, storyb

oardsRequirements

tools

Faster

requirements

development

Better planning

Epics, themes

Serious games

Video/audio

interviews

CHALLENGES TECHNIQUES

© 2011 Israel Gat


The toolkit must evolve

Faster feedback

More reliable

feedback

Faster translation

Better

communication

Greater re-use

Visualizations, pr

ototypes, storyb

oardsRequirements

tools

Faster

requirements

development

Better planning

Epics, themes

Serious games

Video/audio

interviews

© 2011 Israel Gat


Epics

Themes

Release

planning

Bu

sin

ess v

alu

e

Resourcing

© 2011 Israel Gat

Contextual information is crucial

DECISIONS

DESIGNREST OF

THE VALUE

STREAM

CUSTOMER

CONVERSATIONS

© 2011 Israel Gat

FIND THE RIGHT CADENCE

© 2011 Israel Gat

LONG-TERM

MEDIUM-TERM

SHORT-TERM

Entire project/product timeline (years)

Next user-relevant landmark (months)

Next dev-relevant

landmark (weeks)

© 2011 Israel Gat

When do we need the requirements? (examples)

LongProject/product

planInitial backlog Personas

Descriptive Actionable Contextual

MediumRe-prioritized

backlogThemes/epics Use cases

ShortUser stories

(prioritization)User stories

(design)User feedback

© 2011 Israel Gat

“Just in time” requirements take skill

Cultivate the right sources

Identify the right source to

answer the question

Triangulate using multiple

sources

Deliver the actionable and

contextual content that

people need

© 2011 Israel Gat

ASK MORE OF REQUIREMENTS

PROFESSIONALS

© 2011 Israel Gat

More skills and experiences needed

Actionable

Contextual

Descriptive

ECONOMICS

COMPUTER

SCIENCE

ANTHROPOLOGY

© 2011 Israel Gat

We need negotiators, not order takers

© 2011 Israel Gat

The BA job must change

Old BA World New BA World

• Order takers • Business partners

• Everything must be on the list • It’s on the list if it provides

mutual value

• Projects • Products

• Focus on documentation • Focus on information

• Requirements as a weapon •Requirements as a resource

© 2011 Israel Gat

BAs need support and investment

The top 5 challenges for both product managers and

business analysts are soft skills.

Product managers and business analysts say that soft skills are more important than

technical domain knowledge.

© 2011 Israel Gat

HOW DO YOU KNOW YOU’VE

IMPROVED?

© 2011 Israel Gat

How do you know you’re doing well?

If you treat requirements

as a . . .

Necessity

Catalyst

Asset

You might find yourself saying . . .

“Thank God that’s done. Now, on to coding!”

“Wow, that new persona made me rethink our

app.”

“When was the last time we looked at those user

stories?”

And you’ll share them with . . .

Just the development team.

The next person you’re trying to convince.

Everyone, in a format that makes sense to them.

© 2011 Israel Gat


QUALITATIVE

QUANTITATIVE

Ask the community.

Call “go to” users or

stakeholders.

Review personas, use

cases, other existing

content.

Collect usage stats.

Do a quick poll.

Analyze data from public sources

(blogs, communities, etc.).

Answer a question in less than a day.

© 2011 Tom Grant

SLIDE ARCHIVE

44

© 2011 Tom Grant

Software professionals are better inventors than innovators

© 2011 Tom Grant

Many problems that start in requirements

Many sources of problems

• Little or no business justification

• Wrong prioritization

• Mistaken design choices

• Insufficient functionality delivered

• Too much functionality delivered

All boil down to some familiar measures of failure

• Re-engineering, business/IT misalignment, etc.

© 2011 Tom Grant

Business problems putting stress on requirements

Requirements tools are one of the most rapidly-evolving parts of the ALM market

© 2011 Tom Grant

But wait…Wasn’t Agile supposed to fix

everything?

Even though Agile is

certainly mainstream

(39%+ of teams), the

voice of the customer

is frequently not heard

or understood

Agile is a set of powerful, effective team-level practices for software development.

It is not a silver bullet for every problem.

© 2011 Tom Grant

It’s easy to lose track of the customer

© 2011 Tom Grant

How do we fix this situation?

Make the information more accurate

Make the information more timely

Make the insights more profound

Make the information load lighter

© 2011 Tom Grant

© 2009 Forrester Research, Inc. Reproduction Prohibited

Accurate

© 2011 Tom Grant

Feedback loops? Really?

© 2011 Tom Grant

Eating your own dog food is not enough

Because you’re not a dog

© 2011 Tom Grant

Waterfall trained us to be fatalistic about

requirements

© 2011 Tom Grant

Design thinking and visualization accelerate

feedback

Push design earlier in the process.

Push feedback earlier in the process.

© 2011 Tom Grant

Feedback is fine, but…

Do we know in advance the right

questions to pose?

© 2011 Tom Grant

Requirements aren’t simple

Actionable

Contextual

Descriptive

What is the

customer

asking for?

How

should we

meet the

customer’s

request?

What is the customer really

asking for?

© 2011 Tom Grant

Requirements are necessary

We get

through this

as quickly as

possible…

…So that we

can get on

with this

Actionable

Contextual

Descriptive

© 2011 Tom Grant

Actionable

Contextual

Descriptive

Requirements are an exercise in translation

© 2011 Tom Grant

Actionable

Contextual

Descriptive

Requirements are a toolkit

User

stories

Personas, use

cases, busine

ss problems

Themes, e

pics

Enhancem

ent

requests, c

hange

requests, i

deas

Traditional

requiremen

ts

© 2011 Tom Grant

Contextual information is crucial

Contextual information improves

decision-making

– Reduces the number of options

under consideration

– Leads to better design decisions

– Improves communication with

customers

© 2011 Tom Grant

Contextual information lost at every toss

BUSINESS

ANALYST

“Here’s the actionable

requirement”

DEVELOPER

“What should the software do?

Within what parameters for

security, performance, etc.?”

TESTER

“Out of all the tests I might

do, which represent the software as

someone will actually use it?”

UX DESIGNER

“What sort of user experience

does the user expect? What

would really win them over?”

© 2011 Tom Grant

But accuracy isn’t everything

Accuracy is fine, but we do need to get on with the work.

© 2011 Tom Grant


Timely

© 2011 Tom Grant

Requirements can slow Agile teams

WATER SCRUM FALL

© 2011 Tom Grant

When do we need the requirements, really?

LONG-TERM

MEDIUM-TERM

SHORT-TERM

Entire project/product timeline (years)

Next user-relevant landmark (months)

Next dev-relevant

landmark (weeks)

© 2011 Tom Grant

When do we need the requirements? (examples)

LongProject/product

planInitial backlog Personas

Descriptive Actionable Contextual

MediumRe-prioritized

backlogThemes/epics Use cases

ShortUser stories

(prioritization)User stories

(design)User feedback

© 2011 Tom Grant

Requirements structure and process needs

changing

Requirements toolkit, not requirements template

Requirements pipeline, not a requirements bus

Requirements retrospection, not “fire and forget”

Business analysts and product owners who make

decisions, not order-takers

© 2011 Tom Grant

Are we having the best possible conversations?

One-on-one negotiations between the business faction and the IT faction are hardly optimal

© 2011 Tom Grant

INPUT: Change the rules with serious games

Structured

• Rules, but often no winners

Purposeful

• Definite outcome

Time-bound

• By definition, a time-boxed

exercise

Participatory

• Success depends on

everyone participating.

Egalitarian

• Everyone has an equal

opportunity to participate.

© 2011 Tom Grant

EXAMPLE: Buy a feature

Android app for activity management

Custom pipeline stages

More complex lead-scoring options

More canned reports

Define and manage teams

Easy clean-up of bad or duplicate data

Activity entry via email

Associate teams with prospects

$5,000

$2,000

$3,500

$1,500

$4,750

$2,500

$3,250

$1,250

FEATURE COST-

$500

-

$300

$2,000

$2,500

-

-

SPENT

© 2011 Tom Grant

More skills and experiences needed

ECONOMICS

COMPUTER

SCIENCE

ANTHROPOLOGY

Actionable

Contextual

Descriptive

© 2011 Tom Grant

BAs need support and mentorship

The top 5 challenges for both product managers

and business analysts are soft

skills.

When polled, product managers

and business analysts say that

soft skills are more important than

technical domain knowledge.

© 2011 Tom Grant

The top priority for PMs: requirements, over time

Source: Pragmatic Marketing survey

of product managers, 2010-2011.

© 2011 Tom Grant

Agile ratchets up the pressure on BAs

Wa

ste

Business analyst

Wa

ste

Time

Documentation

Solution

Has a problem Provides a solution

The business Development team

© 2011 Tom Grant

The BA job must change

Old BA World New BA World

• Order takers • Business partners

• Everything must be on the list • It’s on the list if it provides mutual

value

• Projects • Products

• Focus on documentation • Focus on information

• Requirements as a weapon • Requirements as a resource

We need someone to make smart decisions. And we need them now.

© 2011 Tom Grant

We need BAs to be business innovation aces

Possesses good research skills

Knows how to get reliable answers

quickly

Builds “just in time” requirements

Understands technical feasibility

Helps customers shape requirements

Has decision-making power

Turns requirements into an asset

© 2011 Tom Grant

“Just in time” requirements take skill, resources

Cultivate the right sources

• EX: Business users, social

media, past requirements, etc.

etc.

Identify the right source to

answer the question

• EX: Do we need insight or

validation?

Triangulate using multiple

sources

• EX: One source provides

depth, another ensures that

the answer is representative

Deliver the actionable and

contextual content that people

© 2011 Tom Grant

“With great power comes great responsibility”

Measure and reward adoption, or some other positive outcome

© 2011 Tom Grant


If you treat requirements

as a . . .

Necessity

Catalyst

Commodity

You might find yourself saying . . .

“Thank God that’s done. Now, on to coding!”

“Wow, that new persona made me rethink our

app.”

“When was the last time we looked at those user

stories?”

And you’ll share them with . . .

Just the development team.

The next person you’re trying to convince.

Everyone, in a format that makes sense to them.

© 2011 Tom Grant


“The dev team has

a question . . .”QUALITATIVE

QUANTITATIVE

Ask the community.

Call “go to” users or

stakeholders.

Review personas, use

cases, other existing

content.

Collect usage stats.

Do a quick poll.

Analyze data from public sources

(blogs, communities, etc.).

Someone can provide this information in less than a day.

© 2011 Tom Grant

Step 1: Rethink your assumptions

Potential techniques

• The “first hour” test

• Participant-observer

• “Product box” serious

game

© 2011 Tom Grant

Step 2: Engage your customer in new ways

Potential techniques

• Transparent road map

• Required “voice of the customer”

at key intervals

• Visualization

• “Buy A Feature” serious game

© 2011 Tom Grant

Step 3: Measure the value of the results

Accuracy• EX: How much re-work?

Timeliness• EX: How much on time?

Insight• EX: How much down-stream value?

Weight• EX: How much work to acquire?

Source: Getty Images (http://www.gettyimages.com)

Agile requirements, slide archive

Technology

Transcript of Agile requirements, slide archive