Agile Requirements & Design
72
LeadingAgile Agile Analysis & Design: Requirements Decomposition
-
Upload
mike-cottmeyer -
Category
Entertainment & Humor
-
view
4.457 -
download
0
Transcript of Agile Requirements & Design
LeadingAgileAgile Analysis & Design: Requirements Decomposition
Mike CottmeyerLeadingAgile
www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer
Requirements DecompositionStory Maps and MMF
EpicEpics 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
Feature
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.
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.
Epic
Feature
User Story
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.
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.
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.
Epic
Feature
User Story
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
Story Maps visually show the relationship between User Stories and Business Value
Epic
Story Maps start with the identification of larger, more strategic organizational goals
Epic
Feature
Epics are decomposed into Features that describe the
value added into the product
Epic
Feature Feature
Epics are decomposed into Features that describe the
value added into the product
Epic
Feature Feature Feature
Epics are decomposed into Features that describe the
value added into the product
Epic
Feature Feature Feature Feature
Epics are decomposed into Features that describe the
value added into the product
Epic
Feature
User Story
Feature Feature Feature
User Story
User Story
User Story
Features are decomposed into User Stories that are thin slices of value added into the system
Epic
Feature
User Story
Feature Feature Feature
User Story
User Story
User Story
User Story
User Story
User Story
User Story
Features are decomposed into User Stories that are thin slices of value added into the system
Epic
Feature
User Story
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
Features are decomposed into User Stories that are thin slices of value added into the system
Epic
Feature
User Story
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
Features are decomposed into User Stories that are thin slices of value added into the system
Estimating and Planning
Epic
Feature
User Story
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
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
User Stories are estimated in relative units of measure
called Story Points
Epic
Feature
User Story
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
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
11 7 12 8
Story Points can be added up to size Features
Epic
Feature
User Story
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
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
11 7 12 8
38 Feature Points can be added up to size Epics
Epic
Feature
User Story
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
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
11 7 12 8
38 Our Goal is to build the smallest system possible to deliver the value in the Epic
Epic
Feature
User Story
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
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
11 7 12 8
38 We continuously evaluate the Story Map to determine the
Minimally Marketable 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
Epic
Feature Feature Feature Feature
User Story
User Story
User Story
11 7 12 8
38
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
We continuously evaluate the Story Map to determine the
Minimally Marketable 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
Epic
Feature Feature Feature Feature
User Story
User Story
User Story
10 4 5 7
26
3
2
5
1
1
3
2
1
2
5
3
2
1
3
2
2
When we focus on Minimally Marketable Features, we
deliver Business Value early
Story Backlog Task Backlog In Process Task Done Story Done
Minimally Marketable Features feed the prioritization of our
Sprint Planning
Story Backlog Task Backlog In Process Task Done Story Done
Identify the User Story most likely to contribute to the
MMF and build that one first
Story Backlog Task Backlog In Process Task Done Story Done
User Story
3
Identify the User Story most likely to contribute to the
MMF and build that one first
Story Backlog Task Backlog In Process Task Done Story Done
User Story
3
Pull User Stories in priority order focusing on delivering
complete MMFs
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
3
2
Pull User Stories in priority order focusing on delivering
complete MMFs
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
3
2
It’s okay to work User Stories across MMFs if that is what the Product Owner needs
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
3
2
1
It’s okay to work User Stories across MMFs if that is what the Product Owner needs
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
3
2
1
Planned Team Velocity = 6 points
The team uses its past velocity to determine how many stories go in the Sprint
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
3
2
1
Planned Team Velocity = 6 points
The Team breaks each User Story down into Tasks
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
3
2
1
Task Task
TaskTask
Planned Team Velocity = 6 points
The Team breaks each User Story down into Tasks
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
Planned Team Velocity = 6 points
The Team breaks each User Story down into Tasks
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8 16
8
Planned Team Velocity = 6 points
And estimates each Task in Real Hours so they can assess
if they can make a solid Commitment to Deliver
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8 16
8
16 2
48
Planned Team Velocity = 6 points
And estimates each Task in Real Hours so they can assess
if they can make a solid Commitment to Deliver
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
TaskTask
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8 16
8
16 2
48
8 4
16 8
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
And estimates each Task in Real Hours so they can assess
if they can make a solid Commitment to Deliver
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8
16 2
48
8 4
16 8
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
At the beginning of the Sprint, The Team pulls Tasks from the
top of the Task Backlog
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8
16 2
48
8 4
16 8
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
Tasks move across the Story Board until there is a
completed User Story.
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
2
1
Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16User Story
3
Tasks move across the Story Board until there is a
completed User Story.
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
Tasks move across the Story Board until there is a
completed User Story.
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
Task
Task Task
Task
Task Task
TaskTask
3
1
Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
User Story
2
The Team works from the top of the Story Board, Swarming to get User Stories across the
board as fast as possible .
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
Task
Task Task
Task
Task Task
TaskTask
3
2
1
Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
The Team works from the top of the Story Board, Swarming to get User Stories across the
board as fast as possible .
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
3
2Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
User Story
1
The Team works from the top of the Story Board, Swarming to get User Stories across the
board as fast as possible .
Story Backlog Task Backlog In Process Task Done Story Done
User Story
User Story
User Story
Task
Task Task
Task
Task Task
Task Task
3
2
1
Task
8
16 2
48
8 4
168
Planned Team Velocity = 6 pointsPlanned Estimated Hours = 98 hours
Task 8
Task 16
Until the entire Sprint has been delivered to the Product
Owner.
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
6
From a Metrics perspective, we Burn Down hours to make
sure the sprint is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
66
From a Metrics perspective, we Burn Down points to make
sure the Release is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
66
8
From a Metrics perspective, we Burn Down points to make
sure the Release is on track
Release Burndown
38
Sprint Burndown
96
Velocity Trend
66
8
5
We track Velocity Trend to make sure the team is
delivering in a Predictable manner
Release Burndown
38
Sprint Burndown
96
Velocity Trend
66
8
5
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.
Release Burndown
38
Sprint Burndown
96
Velocity Trend
66
8
5
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!
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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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.
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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.
Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
• 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 CottmeyerLeadingAgile
www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer
