Agile Requirements & Design

LeadingAgile
Agile Analysis & Design: Requirements Decomposition

Mike CottmeyerLeadingAgilemike@cottmeyer.com 1.404.312.1471www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer

Requirements DecompositionStory Maps and MMF

Epics collections of features, typically 1-3 months in duration. Epics span releases. Epics can span more than one team. These are the things the CEO cares about.
Epic

Epic
Features are smaller than epics, typically 2-4 weeks in duration. Features are contained within releases. Features are contained within a team. These are what the Product Owner Cares about.
Feature

Epic
Features are smaller than epics, typically 2-4 weeks in duration. Features are contained within releases. Features are contained within a team. These are what the Product Owner Cares about.
Feature
User Stores are the smallest increment of value, typically less than a week. User Stories are contained within sprint. These are the things Engineering Management Cares about.
User
Story

Story Maps visually show the relationship between User Stories and Business Value
Epic
Feature
Feature
Feature
Feature
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Story Maps start with the identification of larger, more strategic organizational goals
Epic

Epicsare decomposed into Features that describe the value added into the product
Epic
Feature

Epic
Feature
Feature

Epic
Feature
Feature
Feature

Epic
Feature
Feature
Feature
Feature

Featuresare decomposed into User Stories that are thin slices of value added into the system
Epic
Feature
Feature
Feature
Feature
User Story
User Story
User Story
User Story

Epic
Feature
Feature
Feature
Feature
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Epic
Feature
Feature
Feature
Feature
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Epic
Feature
Feature
Feature
Feature
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Estimating and Planning

User Stories are estimated in relative units of measure called Story Points
Epic
3
1
2
1
Feature
Feature
Feature
Feature
3
2
3
5
5
2
3
2
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Story Points can be added up to size Features
Epic
11
7
8
12
3
1
2
1
Feature
Feature
Feature
Feature
3
2
3
5
5
2
3
2
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Feature Points can be added up to size Epics
38
Epic
11
7
8
12
3
1
2
1
Feature
Feature
Feature
Feature
3
2
3
5
5
2
3
2
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Our Goal is to build the smallest system possible to deliver the value in the Epic
38
Epic
11
7
8
12
3
1
2
1
Feature
Feature
Feature
Feature
3
2
3
5
5
2
3
2
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

We continuously evaluate the Story Map to determine the Minimally Marketable Feature
38
Epic
11
7
8
12
3
1
2
1
Feature
Feature
Feature
Feature
3
2
3
5
5
2
3
2
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story
User Story

We continuously evaluate the Story Map to determine the Minimally Marketable Feature
38
Epic
11
7
8
12
3
1
2
1
User Story
User Story
User Story
Feature
Feature
Feature
Feature
3
2
3
5
User Story
User Story
User Story
5
2
3
2
User Story
User Story
User Story
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story

When we focus on Minimally Marketable Features, we deliver Business Value early
26
Epic
10
4
7
5
3
1
2
1
User Story
User Story
User Story
Feature
Feature
Feature
Feature
3
2
3
5
User Story
User Story
User Story
5
2
3
2
User Story
User Story
User Story
1
1
2
2
User Story
User Story
User Story
User Story
User Story
User Story
User Story

Minimally Marketable Featuresfeed the prioritization of our Sprint Planning
Story Done
In Process
Task Done
Task Backlog
Story Backlog

Identify the User Story most likely to contribute to the MMF and build that one first
Story Done
In Process
Task Done
Task Backlog
Story Backlog

Identify the User Story most likely to contribute to the MMF and build that one first
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story

Pull User Stories in priority order focusing on delivering complete MMFs
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story

Pull User Stories in priority order focusing on delivering complete MMFs
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story
2
User Story

It’s okay to work User Stories across MMFs if that is what the Product Owner needs
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story
2
User Story

It’s okay to work User Stories across MMFs if that is what the Product Owner needs
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story
2
User Story
1
User Story

The team uses its past velocity to determine how many stories go in the Sprint
Planned Team Velocity = 6 points
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
User Story
2
User Story
1
User Story

The Team breaks each User Story down into Tasks
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
Task
Task
User Story
Task
2
User Story
1
User Story

Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
Task
Task
User Story
Task
2
Task
Task
User Story
Task
Task
1
User Story

Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
Task
Task
User Story
Task
2
Task
Task
User Story
Task
Task
Task
Task
1
User Story
Task
Task

And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
16
8
Task
Task
User Story
8
Task
2
Task
Task
User Story
Task
Task
Task
Task
1
User Story
Task
Task

Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
16
8
Task
Task
User Story
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
Task
Task
1
User Story
Task
Task

Planned Estimated Hours = 98 hours
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
16
8
Task
Task
User Story
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
8
4
Task
Task
1
User Story
16
8
Task
Task

At the beginning of the Sprint, The Team pulls Tasks from the top of the Task Backlog
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
8
Task
User Story
16
Task
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
8
4
Task
Task
1
User Story
16
8
Task
Task

Tasks move across the Story Board until there is a completed User Story.
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
8
Task
User Story
16
Task
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
8
4
Task
Task
1
User Story
16
8
Task
Task

Tasks move across the Story Board until there is a completed User Story.
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
8
Task
User Story
16
Task
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
8
4
Task
Task
1
User Story
8
Task
16
Task

The Team works from the top of the Story Board, Swarming to get User Stories across the board as fast as possible .
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
8
Task
User Story
16
Task
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
8
4
Task
Task
1
User Story
8
Task
16
Task

Until the entire Sprint has been delivered to the Product Owner.
Story Done
In Process
Task Done
Task Backlog
Story Backlog
3
8
Task
User Story
16
Task
8
Task
2
2
16
Task
Task
User Story
8
Task
4
Task
1
8
4
Task
User Story
Task
8
Task
16
Task

From a Metrics perspective, we Burn Down hours to make sure the sprint is on track
38
96
6
Release Burndown
Sprint Burndown
Velocity Trend

From a Metrics perspective, we Burn Down points to make sure the Release is on track
38
96
6
6
Release Burndown
Sprint Burndown
Velocity Trend

From a Metrics perspective, we Burn Down points to make sure the Release is on track
38
96
8
6
6
Release Burndown
Sprint Burndown
Velocity Trend

We track Velocity Trend to make sure the team is delivering in a Predictable manner
38
96
8
6
6
5
Release Burndown
Sprint Burndown
Velocity Trend

When the Release is ready to deliver, The Team has completed the highest priority User Stories, against the highest priority Features ,against the highest priority Epics.
38
96
8
6
6
5
Release Burndown
Sprint Burndown
Velocity Trend

When the Release is ready to deliver, The Team has completed the highest priority User Stories, against the highest priority Features ,against the highest priority Epics.
Everyone is focused on delivering value early and often!
38
96
8
6
6
5
Release Burndown
Sprint Burndown
Velocity Trend

10 Patterns for Splitting User Stories

Pattern 1 – Workflow Steps
Identify specific steps that a user takes to accomplish the specific workflow, and then implement the work flow in incremental stages
As a utility, I want to update and publish pricing programs for my customers
…I can publish pricing programs to the customers in-home display
I can send a message to the customer’s web portal
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010

Pattern 2 – Business Rule Variations
Some business rules are pretty complex. If this is the case, break the story into several stories to handle the business rule complexity
As a utility, I can sort customers by different demographics
…sort by Zip Code
…sort by home demographics
…sort by energy consumption

Pattern 3 – Major Effort
Sometimes a story can be split into several parts where most of the effort will go into implementing the first one
As a user, I want to be able to select/change my pricing program with my utility through my web portal
…I want to use time of use pricing
…I want to prepay for my energy
…I want to enroll in critical-peak pricing

Pattern 4 – Simple Complex
What’s the simplest version that can possibly satisfy the customers need
As a user, I basically want a fixed price, but I also want to be notified of critical-peak pricing events
…respond to the time and duration of the critical peak pricing event
…respond to emergency events

Pattern 5 – Variations in Data
Data variations and data sources are another source of scope and complexity. Consider adding stories just in time after building the simplest version
As a utility, I can send messages to customers
…customers who want their messages
…in Spanish
…in Arabic, and so on

Pattern 6 – Data Entry Methods
Sometimes complexity is in the user interface rather than the functionality itself. Build the simplest possible UI first
As a user, I can view my energy consumption in various graphs
…using bar charts that compare weekly consumption
…in a comparison chart, so I can compare my usage to those who have the same or similar demographics

Pattern 7 – Defer System Qualities
Sometimes the initial implementation is not all that hard. Do the simple thing first and then add attributes like scaleability and speed later.
As a user, I want to see real-time consumption from my meter
…interpolate date from the last known reading
…display real time data from the meter

Pattern 8 – Operations (CRUD)
Words like manage or control give away that the story might cover multiple operations
As a user, I can manage my account
…I can sign-up for an account
…I can edit my account settings
…I can cancel my account

Pattern 9 – Use Case Scenarios
If use cases have been developed to represent complex user-to-system or system-to-system interactions, the story can often be split according to the scenarios in the use case
I want to enroll in the energy savings program through a retain disributor
…Use Case/Story #1 (happy path) Notify utility that consumer has equipment
…Use Case/Story #2 (alternate scenario) Handle data validation errors

Pattern 10 – Break Out a Spike
If the story is too large or overly complex, or if the implementation is poorly understood, build a functional or technical spike to figure it out.
As a user I want to be able to create reports that have never been created before and we do not have the technology in place to deliver them
…Research the available technologies for online report delivery
…Create mockups of reports to show to the customer

Mike CottmeyerLeadingAgilemike@cottmeyer.com 1.404.312.1471www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer

Agile Requirements & Design

by Mike Cottmeyer on Jan 31, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Agile Requirements & Design — Presentation Transcript