LeadingAgile<br />Agile Analysis & Design: Requirements Decomposition <br />
Mike CottmeyerLeadingAgilemike@cottmeyer.com	1.404.312.1471www.leadingagile.com	facebook.com/leadingagiletwitter.com/mcott...
Requirements DecompositionStory Maps and MMF<br />
Epics collections of features, typically 1-3 months in duration.  Epics span releases.  Epics can span more than one team....
Epics collections of features, typically 1-3 months in duration.  Epics span releases.  Epics can span more than one team....
Epics collections of features, typically 1-3 months in duration.  Epics span releases.  Epics can span more than one team....
Story Maps visually show the relationship between User Stories and Business Value<br />Epic<br />Feature<br />Feature<br /...
Story Maps start with the identification of larger, more strategic organizational goals<br />Epic<br />
Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />
Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />
Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />...
Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />...
Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />F...
Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />F...
Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />F...
Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />F...
Estimating and Planning<br />
User Stories are estimated in relative units of measure called Story Points<br />Epic<br />3<br />1<br />2<br />1<br />Fea...
Story Points can be added up to size Features<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />Fea...
Feature Points can be added up to size Epics<br />38<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<b...
Our Goal is to build the smallest system possible to deliver the value in the Epic<br />38<br />Epic<br />11<br />7<br />8...
We continuously evaluate the Story Map to determine the Minimally Marketable Feature<br />38<br />Epic<br />11<br />7<br /...
We continuously evaluate the Story Map to determine the Minimally Marketable Feature<br />38<br />Epic<br />11<br />7<br /...
When we focus on Minimally Marketable Features, we deliver Business Value early<br />26<br />Epic<br />10<br />4<br />7<br...
Minimally Marketable Featuresfeed the prioritization of our Sprint Planning<br />Story Done<br />In Process<br />Task Done...
Identify the User Story most likely to contribute to the MMF and build that one first<br />Story Done<br />In Process<br /...
Identify the User Story most likely to contribute to the MMF and build that one first<br />Story Done<br />In Process<br /...
Pull User Stories in priority order focusing on delivering complete MMFs<br />Story Done<br />In Process<br />Task Done<br...
Pull User Stories in priority order focusing on delivering complete MMFs<br />Story Done<br />In Process<br />Task Done<br...
It’s okay to work User Stories across MMFs if that is what the Product Owner needs<br />Story Done<br />In Process<br />Ta...
It’s okay to work User Stories across MMFs if that is what the Product Owner needs<br />Story Done<br />In Process<br />Ta...
The team uses its past velocity to determine how many stories go in the Sprint<br />Planned Team Velocity = 6 points<br />...
The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br /...
The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br /...
The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br /...
And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team ...
And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team ...
And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team ...
At the beginning of the Sprint, The Team pulls Tasks from the top of the Task Backlog<br />Planned Team Velocity = 6 point...
Tasks move across the Story Board until there is a completed User Story.  <br />Planned Team Velocity = 6 points<br />Plan...
Tasks move across the Story Board until there is a completed User Story.  <br />Planned Team Velocity = 6 points<br />Plan...
Tasks move across the Story Board until there is a completed User Story.  <br />Planned Team Velocity = 6 points<br />Plan...
The Team works from the top of the Story Board, Swarming to get  User Stories across the board as fast as possible .  <br ...
The Team works from the top of the Story Board, Swarming to get  User Stories across the board as fast as possible .  <br ...
The Team works from the top of the Story Board, Swarming to get  User Stories across the board as fast as possible .  <br ...
Until the entire Sprint has been delivered to the Product Owner.  <br />Planned Team Velocity = 6 points<br />Planned Esti...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Bur...
From a Metrics perspective, we Burn Down points to make sure the Release is on track<br />38<br />96<br />6<br />6<br />Re...
From a Metrics perspective, we Burn Down points to make sure the Release is on track<br />38<br />96<br />8<br />6<br />6<...
We track Velocity Trend to make sure the team is delivering in a Predictable manner<br />38<br />96<br />8<br />6<br />6<b...
When the Release is ready to deliver, The Team has completed the highest priority User Stories, against the highest priori...
When the Release is ready to deliver, The Team has completed the highest priority User Stories, against the highest priori...
10 Patterns for Splitting User Stories<br />
Pattern 1 – Workflow Steps<br />Identify specific steps that a user takes to accomplish the specific workflow, and then im...
Pattern 2 – Business Rule Variations<br />Some business rules are pretty complex.  If this is the case, break the story in...
Pattern 3 – Major Effort<br />Sometimes a story can be split into several parts where most of the effort will go into impl...
Pattern 4 – Simple Complex<br />What’s the simplest version that can possibly satisfy the customers need<br />As a user, I...
Pattern 5 – Variations in Data<br />Data variations and data sources are another source of scope and complexity.  Consider...
Pattern 6 – Data Entry Methods<br />Sometimes complexity is in the user interface rather than the functionality itself.  B...
Pattern 7 – Defer System Qualities<br />Sometimes the initial implementation is not all that hard.  Do the simple thing fi...
Pattern 8 – Operations (CRUD)<br />Words like manage or control give away that the story might cover multiple operations<b...
Pattern 9 – Use Case Scenarios<br />If use cases have been developed to represent complex user-to-system or system-to-syst...
Pattern 10 – Break Out a Spike<br />If the story is too large or overly complex, or if the implementation is poorly unders...
Mike CottmeyerLeadingAgilemike@cottmeyer.com	1.404.312.1471www.leadingagile.com	facebook.com/leadingagiletwitter.com/mcott...
Upcoming SlideShare
Loading in...5
×

Agile Requirements & Design

4,510

Published on

0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,510
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
407
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. LeadingAgile<br />Agile Analysis & Design: Requirements Decomposition <br />
    2. 2. Mike CottmeyerLeadingAgilemike@cottmeyer.com 1.404.312.1471www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer<br />
    3. 3. Requirements DecompositionStory Maps and MMF<br />
    4. 4. 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. <br />Epic<br />
    5. 5. 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. <br />Epic<br />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. <br />Feature<br />
    6. 6. 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. <br />Epic<br />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. <br />Feature<br />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. <br />User <br />Story<br />
    7. 7. Story Maps visually show the relationship between User Stories and Business Value<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    8. 8. Story Maps start with the identification of larger, more strategic organizational goals<br />Epic<br />
    9. 9. Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />
    10. 10. Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />
    11. 11. Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />Feature<br />
    12. 12. Epicsare decomposed into Features that describe the value added into the product<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />
    13. 13. Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />User Story<br />User Story<br />User Story<br />User Story<br />
    14. 14. Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    15. 15. Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    16. 16. Featuresare decomposed into User Stories that are thin slices of value added into the system<br />Epic<br />Feature<br />Feature<br />Feature<br />Feature<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    17. 17. Estimating and Planning<br />
    18. 18. User Stories are estimated in relative units of measure called Story Points<br />Epic<br />3<br />1<br />2<br />1<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />5<br />2<br />3<br />2<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    19. 19. Story Points can be added up to size Features<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />5<br />2<br />3<br />2<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    20. 20. Feature Points can be added up to size Epics<br />38<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />5<br />2<br />3<br />2<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    21. 21. Our Goal is to build the smallest system possible to deliver the value in the Epic<br />38<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />5<br />2<br />3<br />2<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    22. 22. We continuously evaluate the Story Map to determine the Minimally Marketable Feature<br />38<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />5<br />2<br />3<br />2<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    23. 23. We continuously evaluate the Story Map to determine the Minimally Marketable Feature<br />38<br />Epic<br />11<br />7<br />8<br />12<br />3<br />1<br />2<br />1<br />User Story<br />User Story<br />User Story<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />User Story<br />User Story<br />User Story<br />5<br />2<br />3<br />2<br />User Story<br />User Story<br />User Story<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    24. 24. When we focus on Minimally Marketable Features, we deliver Business Value early<br />26<br />Epic<br />10<br />4<br />7<br />5<br />3<br />1<br />2<br />1<br />User Story<br />User Story<br />User Story<br />Feature<br />Feature<br />Feature<br />Feature<br />3<br />2<br />3<br />5<br />User Story<br />User Story<br />User Story<br />5<br />2<br />3<br />2<br />User Story<br />User Story<br />User Story<br />1<br />1<br />2<br />2<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />User Story<br />
    25. 25. Minimally Marketable Featuresfeed the prioritization of our Sprint Planning<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />
    26. 26. Identify the User Story most likely to contribute to the MMF and build that one first<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />
    27. 27. Identify the User Story most likely to contribute to the MMF and build that one first<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />
    28. 28. Pull User Stories in priority order focusing on delivering complete MMFs<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />
    29. 29. Pull User Stories in priority order focusing on delivering complete MMFs<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />2<br />User Story<br />
    30. 30. It’s okay to work User Stories across MMFs if that is what the Product Owner needs<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />2<br />User Story<br />
    31. 31. It’s okay to work User Stories across MMFs if that is what the Product Owner needs<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />2<br />User Story<br />1<br />User Story<br />
    32. 32. The team uses its past velocity to determine how many stories go in the Sprint<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />User Story<br />2<br />User Story<br />1<br />User Story<br />
    33. 33. The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />Task<br />Task<br />User Story<br />Task<br />2<br />User Story<br />1<br />User Story<br />
    34. 34. The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />Task<br />Task<br />User Story<br />Task<br />2<br />Task<br />Task<br />User Story<br />Task<br />Task<br />1<br />User Story<br />
    35. 35. The Team breaks each User Story down into Tasks<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />Task<br />Task<br />User Story<br />Task<br />2<br />Task<br />Task<br />User Story<br />Task<br />Task<br />Task<br />Task<br />1<br />User Story<br />Task<br />Task<br />
    36. 36. And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />16<br />8<br />Task<br />Task<br />User Story<br />8<br />Task<br />2<br />Task<br />Task<br />User Story<br />Task<br />Task<br />Task<br />Task<br />1<br />User Story<br />Task<br />Task<br />
    37. 37. And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team Velocity = 6 points<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />16<br />8<br />Task<br />Task<br />User Story<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />Task<br />Task<br />1<br />User Story<br />Task<br />Task<br />
    38. 38. And estimates each Task in Real Hours so they can assess if they can make a solid Commitment to Deliver<br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />16<br />8<br />Task<br />Task<br />User Story<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />16<br />8<br />Task<br />Task<br />
    39. 39. At the beginning of the Sprint, The Team pulls Tasks from the top of the Task Backlog<br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />16<br />8<br />Task<br />Task<br />
    40. 40. Tasks move across the Story Board until there is a completed User Story. <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />16<br />8<br />Task<br />Task<br />
    41. 41. Tasks move across the Story Board until there is a completed User Story. <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />8<br />Task<br />16<br />Task<br />
    42. 42. Tasks move across the Story Board until there is a completed User Story. <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />8<br />Task<br />16<br />Task<br />
    43. 43. The Team works from the top of the Story Board, Swarming to get User Stories across the board as fast as possible . <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />8<br />Task<br />16<br />Task<br />
    44. 44. The Team works from the top of the Story Board, Swarming to get User Stories across the board as fast as possible . <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />8<br />Task<br />16<br />Task<br />
    45. 45. The Team works from the top of the Story Board, Swarming to get User Stories across the board as fast as possible . <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />8<br />4<br />Task<br />Task<br />1<br />User Story<br />8<br />Task<br />16<br />Task<br />
    46. 46. Until the entire Sprint has been delivered to the Product Owner. <br />Planned Team Velocity = 6 points<br />Planned Estimated Hours = 98 hours<br />Story Done<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />3<br />8<br />Task<br />User Story<br />16<br />Task<br />8<br />Task<br />2<br />2<br />16<br />Task<br />Task<br />User Story<br />8<br />Task<br />4<br />Task<br />1<br />8<br />4<br />Task<br />User Story<br />Task<br />8<br />Task<br />16<br />Task<br />
    47. 47. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    48. 48. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    49. 49. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    50. 50. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    51. 51. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    52. 52. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    53. 53. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    54. 54. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    55. 55. From a Metrics perspective, we Burn Down hours to make sure the sprint is on track<br />38<br />96<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    56. 56. From a Metrics perspective, we Burn Down points to make sure the Release is on track<br />38<br />96<br />6<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    57. 57. From a Metrics perspective, we Burn Down points to make sure the Release is on track<br />38<br />96<br />8<br />6<br />6<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    58. 58. We track Velocity Trend to make sure the team is delivering in a Predictable manner<br />38<br />96<br />8<br />6<br />6<br />5<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    59. 59. 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. <br />38<br />96<br />8<br />6<br />6<br />5<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    60. 60. 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. <br />Everyone is focused on delivering value early and often!<br />38<br />96<br />8<br />6<br />6<br />5<br />Release Burndown<br />Sprint Burndown<br />Velocity Trend<br />
    61. 61. 10 Patterns for Splitting User Stories<br />
    62. 62. Pattern 1 – Workflow Steps<br />Identify specific steps that a user takes to accomplish the specific workflow, and then implement the work flow in incremental stages<br />As a utility, I want to update and publish pricing programs for my customers<br />…I can publish pricing programs to the customers in-home display<br />I can send a message to the customer’s web portal<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    63. 63. Pattern 2 – Business Rule Variations<br />Some business rules are pretty complex. If this is the case, break the story into several stories to handle the business rule complexity<br />As a utility, I can sort customers by different demographics<br />…sort by Zip Code<br />…sort by home demographics<br />…sort by energy consumption<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    64. 64. Pattern 3 – Major Effort<br />Sometimes a story can be split into several parts where most of the effort will go into implementing the first one<br />As a user, I want to be able to select/change my pricing program with my utility through my web portal<br />…I want to use time of use pricing<br />…I want to prepay for my energy<br />…I want to enroll in critical-peak pricing<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    65. 65. Pattern 4 – Simple Complex<br />What’s the simplest version that can possibly satisfy the customers need<br />As a user, I basically want a fixed price, but I also want to be notified of critical-peak pricing events<br />…respond to the time and duration of the critical peak pricing event<br />…respond to emergency events<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    66. 66. Pattern 5 – Variations in Data<br />Data variations and data sources are another source of scope and complexity. Consider adding stories just in time after building the simplest version<br />As a utility, I can send messages to customers<br />…customers who want their messages<br />…in Spanish<br />…in Arabic, and so on<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    67. 67. Pattern 6 – Data Entry Methods<br />Sometimes complexity is in the user interface rather than the functionality itself. Build the simplest possible UI first<br />As a user, I can view my energy consumption in various graphs<br />…using bar charts that compare weekly consumption<br />…in a comparison chart, so I can compare my usage to those who have the same or similar demographics<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    68. 68. Pattern 7 – Defer System Qualities<br />Sometimes the initial implementation is not all that hard. Do the simple thing first and then add attributes like scaleability and speed later.<br />As a user, I want to see real-time consumption from my meter<br />…interpolate date from the last known reading<br />…display real time data from the meter<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    69. 69. Pattern 8 – Operations (CRUD)<br />Words like manage or control give away that the story might cover multiple operations<br />As a user, I can manage my account<br />…I can sign-up for an account<br />…I can edit my account settings<br />…I can cancel my account<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    70. 70. Pattern 9 – Use Case Scenarios<br />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<br />I want to enroll in the energy savings program through a retain disributor<br />…Use Case/Story #1 (happy path) Notify utility that consumer has equipment<br />…Use Case/Story #2 (alternate scenario) Handle data validation errors<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    71. 71. Pattern 10 – Break Out a Spike<br />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. <br />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<br />…Research the available technologies for online report delivery<br />…Create mockups of reports to show to the customer<br />Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2010<br />
    72. 72. Mike CottmeyerLeadingAgilemike@cottmeyer.com 1.404.312.1471www.leadingagile.com facebook.com/leadingagiletwitter.com/mcottmeyer linkedin.com/in/cottmeyer<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×