Real World Effective/Agile Requirements - IBM Innovate 2010 -sally elatta

Real World Agile
Release Planning and
Story Breakdown
Techniques
Sally Elatta
President, AgileTransformation.com
Sally@AgileTransformation.com
RDM-1131A

The premiere software and product delivery event.
June 6–10 Orlando, Florida

2

Speaker

 Sally Elatta
 President AgileTransformation.com
 Taught over 1000+ and helped coach over 20+ teams
 Background: Java/.Net Software Architect
 Certified Scrum Practitioner & ScrumMaster
 Certified IBM, Sun, Microsoft Professional
 Sally@AgileTransformation.com
I am simply a transformer. Someone who is really
passionate about transforming individuals, teams and
organizations to doing what they do better. I value instilling
soft skills and leadership qualities in the people I coach. I
believe in Servant Leadership as the way to lead change
and create a culture of empowered teams, as opposed to
Command and Control.
1
2

3

Agenda

Challenges With Requirements

Requirements Visioning and Brainstorming

Requirements Break Down

Requirements Deep Dive

Real World Release Planning Techniques

Best Practices and Tips

3
3

Group Workshop

What are the top challenges we face
with Requirements on a project?
What are the most common issues
that cause project challenges?
 Discuss this with others next to you and prepare
some answers to share with all of us.

4

Common Challenges with Requirements

 Limited access to stakeholders  Not thinking outside of the
„current‟ box
 Conflicting priorities
 Too much focus on one type of
 Customers don‟t know what they requirement
want
 Not separating the What from the
 Customers change their mind How
 Getting the RIGHT SMEs  Developers don‟t understand the
 Missing requirements problem domain
 Jumping into the details too early  No clear definition of „Done‟
 Moving from Abstract to Concrete

Copyright© 2010 Sally Elatta AgileTransformation.com
5
5

Addressing the Challenges with Requirements Gathering

 Must Improve:
Designing a process for requirements gathering so that you gather:
 The Right Level of Requirement.
 At the Right Time.
 From the Right SME.
 Using the Right elicitation/modeling techniques.
Defining „Acceptance Tests‟ as core requirements and input into
development.
Engagement level of Product Owners and SMEs.
Early and continuous user acceptance testing.
Engagement level of Product Owner.


6

The 4 Step to Agile Requirements Gathering


7

Building Our Release Backlog

8

Visioning

• Aims to identify: Techniques • Vision Statement
• High level vision • Objectives
and objectives. • Conditions of
• Key measures for • Stakeholder Satisfaction
success. Interviews • Roles/ Personas
• High level scope • Facilitator Led • Use Case Diagrams
• Target users and Visioning • High Level Process
key goals. Workshop Diagrams
• High level backlog • Role-Playing • High Level UI Flow
• High Level • High Level Backlog
Modeling (Themes and
Features)
• Team Breakout
and Converge
Goal Output


9

Use Case Diagram – User Perspective

Scott Ambler
www.AgileModeling.com

10

Sample Process Diagram - Process Perspective

Scott Ambler

11

UI Flow – Screen/UI Perspective

Scott Ambler

12

Requirements Brainstorming

Techniques • Epics, User
• To brainstorm a
large number of Stories
user stories. • Story Writing
• Goal is breadth, not Workshop
depth. • Post-it Note
Brainstorming
• Teams Breakout
Converge
Output
Goal


13

Story Writing Workshops

 Involve as many team members as possible.
 Goal is to brainstorm and write as many user
stories as possible under the themes identified.
Leave the prioritization and evaluation for later.
 Prepare the room with post-it notes, flip charts
and markers.
 Need an effective facilitator to run these
meetings to keep folks on track.

14

Attributes of a User Story

 A small piece of a requirement that is „valuable‟ to the product
owner. U-INVEST Attributes:

Understandable
Story Format: Independent
“As a <role>, I want to <goal>” Negotiable
“Ability to <goal>”
Valuable
Estimatable
Small
Testable

15

Sample Stories

As an Agent I
As an Agent I
want to view the
want to add new
‘Current Leads’
lead information.
report.

As a BA I want
to define the
existing product
return process.
As the XYZ system
As the EDW I want to receive
System, I want to new member
have ABC file enrollments each
loaded on a night.
schedule.

16

Requirements Breakdown

• To breakdown Techniques
• User Stories
existing list of
epics into small
user stories. • Facilitator Led
Workshop
• All Stories should
follow • Post-it Note
U-INVEST. • Teams Breakout
Converge

Output
Goal


17

Breaking Down the EPICS

 Epics are large stories that need to broken down so they can be
development-ready. They could be either Compound or Complex.
 Compound means they have other independent stories within
them.
 Complex means that it is really one big independent story, but to
get it done, we need to break it down to reduce it‟s complexity.
 You break down epics during:
Initial story brainstorming.
During story sizing.
During sprint execution when realizing scope is larger than anticipated.

18

Real World Methods for Story Break Down

 We wanted to share some real world methods we‟ve used
with various teams to break down Stories.
Process Based Breakdown
CRUD – Function Base Breakdown
Business Rule Based Breakdown
User/Platform Based Breakdown


19

Process Based Breakdown

 Walk through the process steps it would take to get that Story completed.
When done, investigate each step and ask yourself if this step could be an
independent valuable testable story of it‟s own?
 „As a student I want to register for a course‟

Browse View Register
Login available course for
courses details course


20

CRUD – Function Based Breakdown

 Apply CRUD (create, read/search, update, delete)
 Trigger words: Manage, Administer, Control, Setup,
Configure
 Example: „As a mobile user I want to manage my greetings‟
As a mobile user I want to create a default greeting.
As a mobile user I want to modify my default greeting.
As a mobile user I want to delete a greeting.


21

Business Rule Breakdown

 Break down the business rules into simple/complex,
positive/negative rules.
 Start with the „simplest‟ story, then add complexity as you go.
 Example: As a loan officer, I want to process a loan
application:
Process a simple loan application that is approved.
Process a simple loan application that fails.
Process a complex loan application that is approved.
Process a complex loan application that fails.


22

User or Platform Based Breakdown

 You can break down Stories based on the different user types
(customer, agent, administrator) or different platforms it will
be accessed via (mobile, portal, desktop) as long as
additional work is needed to implement these.
 Example: “As a phone user I want to listen to my voice mail”
 As a mobile user I want to listen to my voice mail
 As a portal web user I want to listen to my voice mail
 As a desktop phone user I want to listen to my voice mail


23

Building a Release Plan

 There are multiple steps to creating a release plan. Here is
generally the most common activities:
Build the backlog.
Prioritize and size each story.
Define what „Done‟ means for your team.
Determine your iteration length.
Estimate initial velocity.
Map stories to iterations based on this estimate.
Add fall-through, hardening, and pre-release iterations where needed.
Arrive at initial delivery date estimate (for scope driven efforts) or
Arrive at rough scope that could delivered by a specific date (for date
driven projects).


Sample Team Definition of Done (Long!)

25

Planning for Additional Iterations

 Fall-through iterations are needed after every 4 or 5
development ones. They are planned to be very light so they
can be used to help complete any work that „fell through‟ from
one iteration to the other.
 Hardening or Quality iterations are added to do cross-team
integration testing, regression testing, resolve any technical
debt issues, do early alpha/beta testing ..etc.
 A Pre-Release iteration is added before moving to
production to prepare for this release for deployment. It
includes user training, help doc finalization, acceptance and
transition to support teams.

Sample Release Plan

As a Group, Let‟s Review the
“Sample Agile Release Plan”


27

Release Burn Up Chart


Story Deep-Dive (Details of a Story)

• Identify detailed Techniques
level requirements • Acceptance
for each story. Tests
• This should be • Facilitator Led • Business
done a few weeks Workshop Rules
before this Story • Teams • Test Examples
will be Breakout • UI Prototype
implemented. Converge • Activity
Diagram

Goal
Output

29

Sample Acceptance Test Cases

“A customer can pay for shopping
cart items using a credit card”
Test with VISA, MasterCard and American Express (pass)
Test with Diner‟s Club (fail)
Test with bad and missing 3 digit codes (fail)
Test with expired cards (fail)
Test with a purchase amount over the card limit (fail)

30

Business Rules

 In some cases, the test itself contains the business rule itself.
In other cases you will need to provide the list of business
rules that apply to that test case.
 1.1-TC1 „Verify that student eligibility rules are applied
correctly during registration‟
TC1-BR1: Students with a „hold‟ record cannot register on the site.
TC1-BR2: Students with outstanding payment from last semester
cannot register.
TC1-BR3: Student already registered cannot register again.

32

Sample UI Prototypes

Scott Ambler

33

Managing Change

 Rule #0: Identify Breadth then Break Stories Down!
The more you focus on doing this right at the beginning the less “new scope”
you‟ll have.
 Rule #1: Assess the Impact
When new requirements or changes are made, allow the team to assess and
report the impact to the schedule. Don‟t just accept blindly.
 Rule #2: Provide Options
Let the Product Owner know they have options. Based on the impact, they are
welcome to add but may need to also remove from the bottom of the list.
 Rule #3: Product Owner Controls Scope
Product Owner must control scope, not the Project Manager. They must be
empowered to make decisions and clearly know schedule impacts and options.


34

Managing Change ..

 Rule #4: Track the Changes!
Don‟t just add and change requirements without tracking!
 Rule #5: Deep-Dive Just in Time to Reduce Impact of Change
Don‟t invest too much upfront on each requirement. Decide as late as possible,
deliver as fast as possible!
 Rule #6: Provide Stability
Establish concrete rules for introducing new requirements. The team needs to
focus during an iteration and should only address new scope in the following
iteration.


35

Sample Change Management Tracking


36

3
7

Summary

 Addressing the challenges with requirements starts by
designing a simple yet effective process.
 We need to differentiate between the levels of requirements.
 Using simple modeling and effective facilitation techniques
can dramatically improve requirements gathering.
 Release planning is a multi-step activity.

For more Agile related training and coaching, please visit us:
www.AgileTransformation.com
www.AgileTraining.com

37

3
9

Daily iPod touch giveaway
SPONSORED BY

 Complete your session surveys online each day
at a conference kiosk or on your Innovate 2010 Portal!

 Each day that you complete all of that day‟s session
surveys, your name will be entered to win the daily
IPOD touch!

 On Wednesday be sure to complete your full conference evaluation
to receive your free conference t-shirt!

4
0

www.ibm/software/rational

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM‟s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future
product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services
are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product,
or service names may be trademarks or service marks of others.

Real World Effective/Agile Requirements - IBM Innovate 2010 -sally elatta

More Related Content

What's hot

Viewers also liked

Similar to Real World Effective/Agile Requirements - IBM Innovate 2010 -sally elatta

Recently uploaded

Real World Effective/Agile Requirements - IBM Innovate 2010 -sally elatta