The Agile Classroom

Session 2:

Agile Planning: Requirements to Complete a

Product Backlog

March 17, 2010

Moderators:

Duncan Kinchen, Red Fox Consulting, LLCSandi Kappus, Air Wisconsin, Inc.

Duncan Kinchen is a Senior Project Manager and a Certified Scrum Master (CSM) with over 26 years of experience. Based in Green Bay, Duncan has led projects of all sizes in a broad range of industries. Starting with Rapid Application Development in Europe before graduating into Scrum, Duncan has followed the increasing implementation of Agile methodologies for years and is committed to the advancement of Agile principles wherever possible. He is currently one of the Program Directors for the Northeast Wisconsin (NEW) Agile Users Group.

Sandi Kappus is an Applications Manager and a Certified Scrum Master (CSM) with Air Wisconsin Airlines the largest independently held regional airline in the United States, Air Wisconsin Airlines Corporation (AWAC) performs flying services for US Airways, and ground handling services primarily for United. Sandi has over 10 years of experience in business analysis, project management and portfolio management spanning the financial sector as well at the airline industry.  Sandi currently sits on the board for the NorthEast Wisconsin Chapter of the International Institute of Business Analysis (IIBA).  Sandi has actively been practicing the agile methodology as a business analyst, product owner and scum master and is committed to the development of business analysis and Agile methodologies.

3

Agile Methodologies- The Development Landscape -

Engineering Methodologies

PredicitiveProcess-Oriented

RigidHighly-Structured

No Process Lightweight Process Heavyweight Process

Agile Methodologies

AdaptivePeople-Oriented

FlexibleLess-Structured

No

Str

uct

ure

Lig

ht

Str

uct

ure

Hig

hly

Str

uct

ure

d

Code and Fix

Individual Chaos

“Build it and he will come”

1970

's

1990's

2000

4

Agile Requirements and the Product Backlog

Requirements Gathering – High Level

5

Being true to the Agile Methodology you will need to account for:

• Technical changes• Changing business needs• Process improvement• Enhancing the value of the application

Traditional Requirements Gathering Process

6

7

Agile Requirement Process

Example: Requirements Board Postit Collections and User Stories

9

How detailed should Agile Requirements be?

Detailed enough for the team to start work from.

Further details can be established and clarified during development.

10

INVEST in Good Requirements

Independent – Agile Requirements should be as independent as possible.

Negotiable – Agile Requirements are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

Valuable – Agile Requirements should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

Estimatable – Agile Requirements need to be estimated. They need to provide enough information to estimate, without being too detailed.

Small – Agile Requirements should be small. Not too small. But not too big.

Testable – Agile Requirements need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

11

Key Principles for Agile Requirements

Active user involvement is imperative Agile teams must be empowered to make

decisions Requirements emerge and evolve as software is

developed Product Owner involvement is key to success Enough’s enough – apply the 80/20 rule Cooperation, collaboration and communication

Increasing Detail through Interaction over Time

Getting Priorities Right…

Features and functions used in a typical system

Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always7%

Often13%

Sometimes16% Rarely

19%

Never45%

Rarely or never used: 64%

Often or always used: 20%

14

The Product Backlog

15

Agile Requirement Process

16

Agile Requirements Summary

Agile Requirements combine written and verbal communications, supported with a picture where possible.

Agile Requirements should describe features that are of value to the user, written in a user’s language.

Agile Requirements detail just enough information. Details are deferred and captured through

collaboration - just in time for development. Test cases should be written before development,

when the User Story is written. Agile Requirements should be Independent,

Negotiable, Valuable, Estimatable, Small and Testable.

17

Writing Good User Stories- Links

http://www.agile-software-development.com/2008/04/writing-good-user-stories.html (Kelly Waters)

http://www.agilemodeling.com/artifacts/userStory.htm (Scott Ambler)

http://www.extremeprogramming.org/rules/userstories.html

http://www.userstories.com/ http://www.codesqueeze.com/the-easy-way-to-writing-

good-user-stories/ http://www.mountaingoatsoftware.com/books/2-user-

stories-applied-for-agile-software-development (Mike Cohn)

18

Writing Good User Stories- Literature

Agile Requirements & User Stories: Extreme Programming Practices for

Project Managers and Business Analysts

by Louis Molnar

User Stories Applied: For Agile Software Development

by Mike Cohn

Next Session: Sprint PlanningAgile Planning – Estimating and Prioritizing Requirements (Delivering Value from the Product Backlog)