7. Business Goals to
Releases
• Starting with goals and vision
• Epics -> Features -> User Stories
• Story maps and MMFs
• Estimating and planning
8. Elaboration / Decomposition
High Medium Small Details
Level Just In Time
Business Rules
Story 1
Feature A
Acceptance Tests
Epic Story 2
Feature A UI Wireframe
Story 3
Activity Diagram
Tasks
Just in Time Requirements Breakdown... More Definition
9. Release Planning Purpose
• Plan a release based upon:
– Most important features to be delivered
– Capacity of the delivery teams
10. Release Planning Overview
• Participants
– Product owners or a product owner team
– Architecture
– Delivery team (programmers, QA, analysts, etc.)
• Logistics
– Performed prior to release work beginning
– Takes ½ - 2 days depending upon release size,
complexity, and number of teams
11. Release Planning Overview
• Inputs
– Strategy, vision, goals
– Candidate set of features / stories
• Outputs
– Release Vision
– Release Plan
– Architectural Approach
– Testing Approach
12. Release Planning Overview
• Activities
– Business reviews strategy, vision, goals
– Features are discussed and analyzed
– User stories continue to be identified and estimated
– User stories are selected based upon team velocity
and responsible buffering
– Risks are identified
13. What Is A Vision?
• Describes the problem being solved for a
release
• Describe a product solution
• Provides a list of features delivered in the
release
• Creates shared understanding of purpose
14. Vision: Problem Statement
The problem of Having to run to the rental store
Affects People who want to easily watch movies
The impact of which is Wasted time, effort, and cost to travel
to a store to pick from a limited
A successful solution would selection
Allow a user to select movies they want
to see and have them shipped to their
home with a postage paid return
15. Vision: Product Position
For People
Who Want to watch movies at home
The ShipFlix system Is a web-based membership system
That Allows consumers to queue up movies to
watch and to be delivered to their home
Unlike Local DVD rental stores
Our product Will automatically ship DVDs to a person’s
home allowing them to keep 2 disks out at
any time providing pre-paid envelopes so the
16. Epics and Features
• Break the Vision down into:
– Epics: High level outcomes needed to accomplish
the Vision and
– Features: Specific changes needed to deliver the
Epics
• These can be estimated at a high level to
determine the product road-map
17. Epics collections of features, typically 1-3 months in
Epic duration. Epics span releases. Epics can span more than
one team. These are the things the market cares about.
18. Epics collections of features, typically 1-3 months in
Epic duration. Epics span releases. Epics can span more than
one team. These are the things the market cares about.
Features are smaller than epics, typically 2-4 weeks in
Feature duration. Features are contained within releases. Ideally,
features are contained within a team. These are what the
Product Owner Cares about.
19. Epics collections of features, typically 1-3 months in
Epic duration. Epics span releases. Epics can span more than
one team. These are the things the market cares about.
Features are smaller than epics, typically 2-4 weeks in
Feature duration. Features are contained within releases. Ideally,
features are contained within a team. These are what the
Product Owner Cares about.
User Stories are the smallest increment of value, typically
User
less than a week. User Stories are contained within sprint.
Story
These are the things Engineering Management Cares
about.
20. For Each Release:
• Give it a name or statement that describes the
purpose
• Describe the benefits and goals for the
business
• Describe the benefits or value the users get
Release 1: Two DVDs out to
customers
Business Value: Begin creating a
user base to offer more profitable
capabilities
User Value: Ability to have two
21. Release Planning
• A Release Plan is a roadmap for communicating
with project stakeholders
• It is created to communicate when there will be
releases and what features will be in them
• Often takes the form of a Story Map
22. Release Planning Meeting
Release Planning Inputs
• A business value focused goal for the release
• A prioritized set of features or user stories –
business value ranking
• A course estimate for features or stories
• Risks associated with features or stories
• A date for the release
23. Release Planning Meeting
Release Planning Process
• The delivery team assesses the groomed backlog
• Review the sizing, resize if the team doesn’t agree
• Split stories into smaller than a sprint sizes (3 – 4
days to complete)
• Order the stories into the current release, the
following release, and future releases
• Prioritize the stories and risks in the current
release
24. Story Mapping
• An approach to organizing and prioritizing user
stories
• Is a tool to help in defining a roadmap
25. Benefits of Story Mapping
• Provides visibility of the workflow across the
system
• Points out relationships between stories
• Helps to spotlight missing stories
• Provides a prioritization mechanism
• Release planning is improved by focusing on
valuable slices
26. Preparing for Story Mapping
• Understand the users/roles using the system
• The major activities performed by the users of
the system
• Arrange activities in the order they are
performed
• Define stories required to complete activities
28. Buffering
• Buffers for both knows and unknowns
• Plan for Dark Matter: Stuff we know is out there
• Plan for an Iteration 0 if needed
– Establish any needed Build, Continuous
Integration, Walking Skeleton, Spikes,
Developer Environments
• Plan for a Hardening Iteration in a complex
environment
40. Estimating Initial Velocity
• Ask the team the following question:
“Which stories do you think you can commit to
getting ‘Done’ from this release during the first
iteration? Be realistic in your commitment
based on your capacity.”
• These stories makeup their initial velocity.
• You can also do a ‘Mock Planning Meeting’
• Example: a team thinks they can get the first 4
stories on the list completed which total 15
points.
41. Developing the Release Plan
At this point it is possible to determine the time required to
complete the work.
Backlog: 225 points
Historic or initial velocity: 25 points per sprint
Buffering: 20%
Planning Velocity: 20 points
Extra Iterations: • 2 extra sprints
• Sprint Zero: 1 sprint
• Hardening: 1 sprint
Iteration length: 2 weeks
42. Developing the Release Plan
At this point it is possible to determine the time required to
complete the work.
Backlog: 225 points
Historic or initial velocity: 25 points per sprint
Buffering: 20%
Planning Velocity: 20 points
Extra Iterations: • 2 extra sprints
• Sprint Zero: 1 sprint
• Hardening: 1 sprint
Iteration length: 2 weeks
Roughly we need 32 weeks to get the project
done.
43. Example With Internal Releases
(10-15%: Schedule percentages are approximate and will vary by domain, but show typical agile project activity
splits)
10 -15%
Schedule 80% - 85% Schedule 5%
Upfront Close-
Planning
0 20 20 20 0 20 20 20 0 20 20 20 0 20 20 20 0
Out
Iteration 0
Development
Iterations
Releases
Stabilization/ Hardening/Pre-release
Iteration
Assuming your initial velocity is 20pts/iteration
Capacity per release = 60pts without any buffering
32
44. At the End of Release Planning
• We know the purpose of the project
• The team is aligned
• We have an estimated project backlog
• We have a roadmap (we know how many
iterations and releases we have)
• We know which stories are part of our first
release
45. Create A Release Plan
• Review goals, objectives, and architectural
description
• Plan the first 3 sprints
• Log into the system and schedule payment to
payee the customer sets up in the system
• Validate the user experience and enough of the
architecture to reduce technical risks
• Team velocity averages 10 points per sprint
Here is a complete breakdown of the hierarchy from Epic to Task\nEPIC/Theme: have all been used to describe a larger piece of requirement that may include multiple features within it. \nEpic is used to describe functionality that is too big to get done within a sprint and needs to be broken down to a smaller chunk.. \nFeature: a medium sized, business understandable description of functionality. You may have some of these on your list as placeholders that you breakdown and estimate when you’re ready to include them in the next release\nStory: Small valuable business requirement that follows the INVEST attributes\n
\n
\n
\n
\n
\n
\n
\n
The hierarchy of requirements goes:\nEpics – business oriented components of the project vision, then\nFeatures – specific components of epics, but probably still too large to accurately estimate or deliver in an iteration.\n
Explaining the hierarchy of value\n
Explaining the hierarchy of value\n
Explaining the hierarchy of value\n
\n
Release planning is the process of deciding when the project will releases and what will be in those releases.\n\nTypically we have more detail about what exactly will be in the next release and less detail about what will be in subsequent releases\nHowever there needs to be a reasonable and defendable plan for completing all the agreed work within the available time otherwise we need to discuss resceduling or de-scoping the project\n
Inputs into the Release Planning meeting include:\n A business value focused goal for the release – e.g. “the basic movie renting and buying release to get some revenue”\n A prioritized set of user stories – business value ranking – stories that support renting and buying movies\n A course estimate for each story – t-shirt size estimate – with a level of confidence from the team that these look acheivable\n Risks associated with the stories – what might we need to watch out for?\n A date for the release – E.g. May 15th \n\nIt is the team and not the product owner or scrum master that needs to determine what is feasible. \nThe PO sets priority but cannot influence estimates\n
Inputs into the Release Planning meeting include:\n A business value focused goal for the release – e.g. “the basic movie renting and buying release to get some revenue”\n A prioritized set of user stories – business value ranking – stories that support renting and buying movies\n A course estimate for each story – t-shirt size estimate – with a level of confidence from the team that these look acheivable\n Risks associated with the stories – what might we need to watch out for?\n A date for the release – E.g. May 15th \n\nIt is the team and not the product owner or scrum master that needs to determine what is feasible. \nThe PO sets priority but cannot influence estimates\n
\n
\n
\n
\n
\n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
By estimating average velocity, you can begin to determine how many iterations it will take on average to complete all the work on the backlog.\nIn this example, there is 48 points total, the team’s average velocity is 12 pts, this means it will take a min of 4 iterations to get this done. \nNext we’ll talk about additional iterations you need to add to the estimate. \n
The team will not know there velocity for the first iteration so it must be based upon the team’s capacity and understanding they must meet the definition of “done” for their stories. Teams are optimistic about their initial velocity and that needs to be considered during this planning. The teams pick those stories they feel confident they can complete and the total of those story points become their initial velocity.\n\nTo gain a better understanding of what they can accomplish a team might go through a mock planning meeting. The team will break down stories into tasks to provide additional confidence that they can commit to the number of story points they have selected.\n
\n
Here we see how a project can have one or more releases and a release consists of one or more iterations. \nUpfront we may have an iteration 0 that establishes the development environment and tools. The remainder of the iterations will most likely be for adding functionality and will have associated velocity scores (the “20”s in the image above), but some iterations might be for hardening and stabilization and will not deliver new functionality.\n
Each of these items are now available by the end of release planning. This sets the team up for iteration planning.\n