Agile Requirements & Design
Upcoming SlideShare
Loading in...5
×
 

Agile Requirements & Design

on

  • 4,028 views

 

Statistics

Views

Total Views
4,028
Views on SlideShare
4,027
Embed Views
1

Actions

Likes
12
Downloads
345
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.
  • Explaining the hierarchy of value
  • Explaining the hierarchy of value
  • Explaining the hierarchy of value
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • Story Mapping
  • So, before we get started, a little about me. My name is Mike Cottmeyer, I am an agile transformation coach with Pillar technology. Before I joined Pillar I was a trainer and consultant with VersionOne. Before that I ran a pretty large agile portfolio of projects for CheckFree (now Fiserv). Pillar Technology has been around for about 13 years and is just about 100 people strong. Pillar specializes in agile transformation and project delivery. We can bring in agile coaches on the leadership and project management side. We can bring in coaches to help you with TDD. We can spin up teams and help you deliver projects.

Agile Requirements & Design Agile Requirements & Design Presentation Transcript

  • 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
  • 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
    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
  • 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
    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
  • Epicsare decomposed into Features that describe the value added into the product
    Epic
    Feature
    Feature
  • Epicsare decomposed into Features that describe the value added into the product
    Epic
    Feature
    Feature
    Feature
  • Epicsare decomposed into Features that describe the value added into the product
    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
  • 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
    User Story
    User Story
    User Story
    User Story
  • 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
    User Story
    User Story
    User Story
    User Story
    User Story
    User Story
    User Story
    User Story
  • 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
    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
    Planned Team Velocity = 6 points
    Story Done
    In Process
    Task Done
    Task Backlog
    Story Backlog
    3
    Task
    Task
    User Story
    Task
    2
    User Story
    1
    User Story
  • The Team breaks each User Story down into Tasks
    Planned Team Velocity = 6 points
    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
  • The Team breaks each User Story down into Tasks
    Planned Team Velocity = 6 points
    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
    Planned Team Velocity = 6 points
    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
  • And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver
    Planned Team Velocity = 6 points
    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
  • And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver
    Planned Team Velocity = 6 points
    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
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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.
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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.
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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
  • Tasks move across the Story Board until there is a completed User Story.
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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 .
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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 .
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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 .
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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.
    Planned Team Velocity = 6 points
    Planned Estimated Hours = 98 hours
    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 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 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 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 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 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 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 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 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • 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
    Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010
  • Mike CottmeyerLeadingAgilemike@cottmeyer.com 1.404.312.1471www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer