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. Epic
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. 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
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. 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
7. 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
8. Story Maps start with the identification of larger, more strategic organizational goals Epic
10. Epicsare decomposed into Features that describe the value added into the product Epic Feature Feature
11. Epicsare decomposed into Features that describe the value added into the product Epic Feature Feature Feature
12. Epicsare decomposed into Features that describe the value added into the product Epic Feature Feature Feature Feature
13. 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
14. 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
15. 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
16. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. Minimally Marketable Featuresfeed the prioritization of our Sprint Planning Story Done In Process Task Done Task Backlog Story Backlog
26. 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
27. 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
28. Pull User Stories in priority order focusing on delivering complete MMFs Story Done In Process Task Done Task Backlog Story Backlog 3 User Story
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
37. 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
38. 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
39. 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
40. 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
41. 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
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. 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
52. 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
53. 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
54. 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
55. 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
56. 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
57. 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
58. 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
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. 38 96 8 6 6 5 Release Burndown Sprint Burndown Velocity Trend
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. Everyone is focused on delivering value early and often! 38 96 8 6 6 5 Release Burndown Sprint Burndown Velocity Trend
62. 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
63. 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
64. 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
65. 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
66. 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
67. 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
68. 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
69. 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
70. 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
71. 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
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.
