managing requirements in an agile world: avoiding the...

www.esi-intl.com

Managing Requirements in an Agile World: Avoiding the “Round Peg/Square Hole” Dilemma

Nancy Y. Nee, PMP, PMI-ACP, CSM, CBAPVP, Global Product Strategy, ESI International

[email protected]

building talent, driving results

Agenda

Agile? SCRUM?

What’s the Difference?Agile In Practice

10/22/2012© ESI International, Inc. 2010

2


Here’s what we’ll cover

� Agile or SCRUM – what’s the

difference?

� Agile Manifesto

� Is this just another fad?

� The 3 layers of agile

requirements

� Backlogs, User Stories, and

Acceptance Tests

Agile Requirements


Method

Agile Requirements


Frameworks & Methods—Agile

AGILE MANIFESTO

Agile ModelingAgile Modeling

Agile Unified

Process

Agile Unified

Process

ScrumScrum

Dynamic Systems

Development Methods

Dynamic Systems

Development Methods

Essential

Unified Process

Essential

Unified Process

Extreme

Programming

Extreme

Programming

Feature Driven DevelopmentFeature Driven Development

Open Unified

Process

Open Unified

Process

Velocity TrackingVelocity Tracking

AGILE MANIFESTO

Agile Modeling

Agile Unified

Process

Scrum

Dynamic Systems

Development Methods

Essential

Unified Process

Extreme

Programming

Feature Driven Development

Open Unified

Process

Velocity Tracking

Agile Requirements


Agile Manifesto

1. Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

7. Working software is the primary measure of progress.

2. Welcome changing requirements, even late

in development. Agile processes harness

change for the customer’s competitive

advantage.

8. Agile processes promote sustainable

development. The sponsors, developers and

users should be able to maintain a constant

pace indefinitely

3. Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter time scale.

9. Continuous attention to technical

excellence and good design enhances agility.

4. Business people and developers must work

together daily throughout the project.

10. Simplicity—the art of maximizing the

amount of work not done—is essential.

5. Build projects around motivated individuals.

Give them the environment and support they

need, and trust them to get the job done.

11. The best architectures, requirements and

designs emerge from self-organizing teams.

6. The most efficient and effective method of

conveying information to and within a

development team is face-to-face conversation.

12. At regular intervals, the team reflects on

how to become more effective, then tunes and adjusts its behavior accordingly.


Not just another fad… perceived IT project success rates - 2010

Copyright 2010 Scott W. Ambler www.ambysoft.com/surveys/

18%

15%

12%

12%

41%

40%

29%

31%

52%

53%

61%

67%

Traditional

Ad-Hoc

Agile

Iterative

Failed Challenged Successful

Note: Accurate to within +/-7%

Figures don’t add to 100% due to use of “ranged options”


Agile in Practice – From the Top Down

The Portfolio Layer

The Team Layer

The Program Layer

Portfolio ManagementInvestments

Portfolio Backlog Architecture

Product Backlog

Product ManagementFeatures “Releases”

Team Backlog

ComponentsAgile TeamsStories & Iterations


Requirements at the Portfolio Layer

� Highest Level Requirements

� “Business Requirements are high-level needs, goals

or objectives of an enterprise in its entirety” ~ IIBA

� These types of requirements evolve out of enterprise analysis

activities

� In the Agile world there are 2 types of “high” level

requirements

� Investment Themes

� Epics


Investment Themes & Epics

� Investment Themes are “bigger” or more “lofty than

epics – epics are decomposed themes

� Investment themes are a set of initiatives that drive

investments, which in turn drives goods and services

� In Agile terms investment themes are established

annually by the “Portfolio Management Group”

� Themes generally have a much longer “shelf-life” than

epics


Investment Themes & Epics

There are 4 flavors of Investment themes that are

generally considered and are NOT unique to the world

of Agile

1. Existing – enhance, support & maintain

2. New – revenue generating products and services, gain

market share in the near term, invest today, realize today

3. Future – invest today – realize tomorrow, products and

services that will grow revenue in outlying years

4. Sunset – put the horse out to “pasture”


Epics – Portfolio Level

Agile Requirements

� Are large scale in nature and are used to realize investment

themes

� Are the highest level of requirement

� Demonstrate VISION NOT specificity

� They must be categorized, prioritize and estimated

� They represent the “2nd layer of abstraction”


Epics – Portfolio Level

� Epics are managed and maintained by the Portfolio

management group, governance team or business

unit owners

� Epics are managed and maintained in the Portfolio

backlog

Epic1

Epic2

Epic3

Po

rtfo

lio

Bac

klo

g

Investment Themes


A note about architectural epics

� Represent the technological/infrastructure initiatives required

to support features

� Ultimately architectural epics represent large scale

implementations that could potentially affect millions of lines of

code and how that code will be housed, supported etc.


Features – Program Level

� What new things will a system do for its users

� Describes the benefits the users will get out of features

� They bridge the gap between “needs” and Software

requirements

Problem or

Opportunity

Solution



� Simple rule of thumb for features; 25-50 features ensures

that this layer of abstraction is kept at a high level.

� In essence features are a high level user story and can be

written as such

� “As a sales person I want my expenses to be automatically

categorized so that I can create my expense reports

quickly”

� This layer of abstraction is important for Agile teams to

organize teams for development efforts

Agile Requirements



Challenges in Prioritizing Features for the Program Backlog

� Customers want them all

� Product managers want to avoid prioritizing features for sake of having

them all

� Quantification of value for simple must haves is difficult to do for sake of

remaining competitive – this is often to abstract in nature to prioritize

� Comparing “apple” features to “oranges” features can be very

challenging

� Large features that take months to develop versus must have

features that take weeks to develop


User Stories – Team Level

� User Stories are NOT Requirements

� They are a “placeholder” for requirements to be

realized/discussed

� They are the “Value Stream” for Users and a direct line to

developers for coding

� The user story is the most critical level of abstraction for Agile

environments to succeed

� Help to bridge developers with customers

Agile Requirements



� “A user story is a brief statement of intent that describes

something the system needs to do for the user” –Leffingwell

� Detailed system behavior is NOT captured in a user story

Agile Requirements



Characteristics of a great user story:

� They are short and easy to read

� They are captured in a “list format” large BRD’s not welcome here!

� They can be discarded after implementation

� They represent small increments of functionality

� They should be relatively easy to estimate

Agile Requirements



Characteristics of a great user story;

� Card

� 2 or 3 sentences to describe intent of story

� Format: As a <role> I can <activity> so that <business value>

� Conversation

� The card in essence is the introduction to a conversation

between, product owner, developers, users, team, customer etc,

in short all stakeholders involved. The conversation is intended to

seek clarity and drive out details

� Confirmation

� = Acceptance test, has the story been implemented according to

conditions of satisfaction?

Agile Requirements



� Characteristics of a great user story;� Details of conversation are most often captured as

assumptions acceptance criteria, and alternate flows, and are

kept as separate notes with the user stories

� Critical to the success of the user story is acceptance criteria;

� Acceptance criteria are “conditions of satisfaction”

� The best litmus test of user stories is the use of the mnemonic INVEST

� Independent� Negotiable� Valuable� Estimable� Small� Testable


Pulling it all together

www.esi-intl.com

Questions?

Nancy Y. Nee, PMP, PMI-ACP, CSM, CBAPVP, Global Product Strategy, ESI International

[email protected]

managing requirements in an agile world: avoiding the...

Documents