the agile classroom
DESCRIPTION
Session 2: Agile Planning: Requirements to Complete a Product Backlog. The Agile Classroom. March 17, 2010. Moderators: Duncan Kinchen, Red Fox Consulting, LLC Sandi Kappus, Air Wisconsin, Inc. - PowerPoint PPT PresentationTRANSCRIPT
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)