Download - Definitions and Terms R1
Breaking Down the WorkTerms, Definitions, & Process
AgendaOverview Quick once over of heirarchy, process, and
tree as well as breaking down the work
Backlogs, Products, and Epics Portfolio level components and their definition
Features and Releases Program Level components and their definitions
Sprints and Stories Project/Team level components and their definitions
Integrating with Version One How does this procedure work with Version One and our Tree
Q&A Questions and Answer SessionAppendices A, B, C
Overview• In this workshop we will cover some concepts that
we have all used in one manner or another… our goal is:– To give you an optimal way to decompose work– To provide a standard vocabulary for everyone to share
when referring to work– To provide a standard way of approaching the break down
of work and working within the Version One tree hierarchy• In scope… terms and definitions from the Portfolio
level to task level • Out of scope… the intake process for new work
prior to approved portfolio item
4
Strategic vs Tactical Planning• Strategic planning is high level• Focused on milestones and
product level deliverables• Product road map and even
release planning are considered strategic level planning
• Strategic level planning has fewer details, and is more focused on providing larger goals to be achieved
• Funding is often done at the Strategic level, due to the level of detail presented and the fact that it is still very resistant to change and adjustments due to obstacles
• Tactical planning is more actually closely aligned to work that must be done at the mid range and detail level
• Tactical planning is around the sprint planning and task planning level
• Used more as a executable plan of action to produce assets of value
• We often track the actual hours spent on tactical assets, such as tasks, for purposes of rolling that information up to capitalize when strategic elements are deployed to production
5
The Initiative• Definition: An initiative is
a large scale effort possibly requiring work both within and outside of IT.
• Initiatives are generally strategic in nature
• Initiatives will lack detail level specifics
• Initiatives are often accompanied by a feasibility study and business case for funding consideration
• Characteristics:– High level– Used in strategic planning– May take less than one
year, but may stretch across multiple budgetary years
– Can be larger than individual product life cycles
– Can include work both within and outside of IT
6
The Cycle of Decomposition
Top Unit
Acceptance
Criteria
2nd Unit
2nd Unit
2nd Unit
2nd Unit
2nd Unit
2nd Unit
Acceptance
Criteria
Acceptance
Criteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
3rd
3rd
3rd
3rd3rd3rd3rd3rd3rd3rd3rd3rd
Product
Epic
AcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
4th
4th
4th
4th4th4th4th4th4th4th4th4th4th
4th
4th4th4th4th
4th
4th4th
StoryFeature
7
Version One – Key Assets Overview
8
So, what does this look like overall?PerfectSer
veIT
Product
Epic
Feature Feature
User Story User Story
Task Task Task Task
User Story
Feature
Epic
Feature
Epic
Product
Epic
9
And in terms of Version One?PerfectSer
veIT
NODE
Portfolio Item
Child Portfolio
Item Child
Portfolio Item
Backlog Item
Backlog Item
Task Task Task Task
User Story
Feature
Portfolio Item
Feature
Epic
Product
Epic
Best Practice: Portfolio Item is 1 year or less in duration
Best Practice: Child Portfolio Item only persists within a release to production
Best Practice: Backlog Items only persist for one Sprint
The Purpose: Completing the Product Vision
10
Stage 1:When all stories are done, the feature is complete
Stage 2:When all features are complete, the epic is complete
Stage 3:When all the epics are complete, the product is complete
Stage 4:When the product is complete, we have realized our vision in the marketplace
11
Where do quarters and releases come in?
Jan-16 Dec-17Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
1/1/2016 - 12/31/2017Product Life CycleMore than 1 year
2 years shown
1/1/2016 - 12/31/2016Single Year Development Budget
1/1/2016 - 3/31/2016Q1
4/1/2016 - 6/30/2016Q2
7/1/2016 - 9/30/2016Q3
10/1/2016 - 12/31/2016Q4
Epic
Jan-16 Dec-16Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
1/1/2016 - 3/31/2016Q1
4/1/2016 - 6/30/2016Q2
7/1/2016 - 9/30/2016Q3
10/1/2016 - 12/31/2016Q4
Jan - AprRelease to Production
Apr - JunRelease to Production
Feature
Jan-16 Jun-16Feb Mar Apr May Jun
1/1/2016 - 3/31/2016Q1
4/1/2016 - 6/30/2016Q2
Jan - AprRelease to Production
Apr - JunRelease to Production
Jan - JanSprint 1
Jan - FebSprint 2
Feb - FebSprint 3
Feb - MarSprint 4
Mar - MarSprint 5
Story
12
Backlogs, Products and EpicsOH MY!
13
Backlog• Backlog is one of the most
over used and less understood terms in all of agile
• There are multiple types of backlogs, that cover strategic planning concepts all the way down to your daily activities
• Understanding the different types of backlog (even if you choose not to employ them at some levels or refer to them as a “backlog”) will prevent confusion
Sprint Backlog
Team Backlog
Release Backlog
Quarterly Backlog
Product Backlog
Portfolio BacklogPortfolio Backlog
• A portfolio backlog is a list of projects or programs that are listed in strategic and financial priority in the order from most beneficial to least
• The list represents the major initiatives or work we will fund in IT
• For development, that work is usually expressed in terms of products
• For purely infrastructure projects or programs, the work may be classified in terms customized to the infrastructure to be added either descriptive of the work (i.e. New Data Center) or designated by some customized code name (i.e. “Project Cortez”)
Product Backlog
• When someone refers to the Product Backlog they are referring to the prioritized wish list of all the things that the product should be capable of once completed.
• It’s important to note this backlog can contain Epics, Features, or a combination of both.
• A functional, planning ready backlog will have enough high priority epics decomposed to feature level to fill the next planned future product release to production
Quarterly Backlog
• Some teams have embraced quarterly planning. If they have a list of milestones, epics, and/or features to be completed within that quarter that list once prioritized is the quarterly backlog
• It is important to not confuse the quarterly backlog with a release backlog
• A quarterly backlog may contain no production releases, one production release, or multiple production releases
• It is not uncommon to have a quarterly backlog AND a release backlog, however some teams choose to supplant the release backlog with a quarterly backlog and will only do midrange planning using the quarter as the unit of measure
Release Backlog
• The release backlog is a prioritized list of work decomposed to feature level that contains a list of all value added functionality and required infrastructure to be added in the next release to production
• A release backlog is often used as the list of features referenced at time of release planning, and in scaled mult-team efforts will contain features to be divided amongst all participating teams
• Do not confuse a release backlog with a team backlog. If you have a single team doing all the work within a release to production, then they represent the same work. HOWEVER… if you have multiple teams a release backlog will have the work for all teams while a team backlog will contain only the work for a single team for a release
• SAFe refers to the Release backlog as the program backlog. Be aware of this, so if you see within the tool or someone mentions a “program backlog” you will not be confused
Team Backlog
• This contains all the work decomposed to the feature level, user story level, or a combination or the two. The team backlog contains the prioritized work for a single team to complete in a single release to production.
• Do not confuse this backlog with a Sprint backlog. While some teams do go to production every sprint, and in those occasions a sprint backlog does contain the same work as the Team Backlog, we rarely have a minimal marketable feature completed within one sprint
• When multiple sprints of work must be completed before we have something we can release to production the team backlog will actually contain two or more sprint backlogs of features
Sprint Backlog
• This is the team backlog of work decomposed to the user story level to be used in sprint planning and contains the work to be accomplished within one iteration or sprint
• If your team does not use iterations… and is a Kanban style team… you may or may not use a sprint backlog within the tool to present your Kanban queue
• Remember… this is a list of work to be accomplished within a sprint and all user stories should be ideally finished within whichever sprint they are started.
14
The Final Backlog– the Daily Task List• This is not considered by many to
be an actual backlog, as it is just the work a single individual plans to do in a single day
• No matter how informally, however, we all tend to keep a list somewhere in our head or on a white board or a tool that has our activities for the day
• If you do not practice this, you might consider starting. I have seen this done to great success using confluence and white boarding to help team members remind their teammates what they are working on throughout the day
15
Intake Process:
Represents IT Budget
for Product Developme
nt
Product 1 is funded for Development
Product 2 is funded for Development
Product 3 is funded for Development
Product 4 is funded for Development
IT Budget – Selecting Products
AMirac
le Occu
rs
16
Product• A product is top container of
work that exists under IT • Each product may contain
multiple Epics and have multiple releases to production
• To decompose the epic– Determine the acceptance
criteria consisting of all the major functionality the product should be capable of once complete
– Decompose each acceptance criteria into one or more Epics
Product
Acceptance Criteria 1Acceptance Criteria 2Acceptance Criteria 3Acceptance Criteria 4
Decompose
17
Product Acceptance Criteria• Each acceptance criteria for a
product is decomposed to one or more Epics
• To decompose the acceptance criteria– Break down the key
components of the first acceptance criteria using logical, time based, or dependency based logical containers
– Repeat process for all product acceptance criteria until you have a full list of epics.
– Prioritize your epics and build your initial product backlog
• Note: As you build your epics, you are actually satisfying your acceptance criteria for your Product
Epic 3
Acceptance Criterial
1Acceptance Criterial
2Acceptance Criterial
3Acceptance Criterial
4
Epic 1
Epic 2
Epic 3
Epic 4
18
The Epic• Definition: An epic is an
asset, either expressed in terms of a broad/ large milestone or product capability
• Example: – Product – Complete
Triathlon• Epic 1 – Complete
Swimming course• Epic 2 – Complete
Biking course• Epic 3 – Complete
Running course
• Simile: Also referred to as Portfolio Item within Version One
• Characteristics:– Epics by definition are so large that
details may not be possible at the beginning
– Epics can be treated as projects, with what is in scope, out of scope, and acceptance criteria defined in some form of informal documentation
– Epics may span releases to production, quarters, etc., but will not extend past the product life cycle
– One or more Epics satisfy the acceptance criteria of the Product
– One or many teams may collaborate to build an epic
19
Epic Template• Often the scope of an epic
requires more information than a story or task.
• Usually that information is placed in a tool such as Version One
• Required as a minimum:– Description– Success / Acceptance
Criteria– What is In Scope– What is Out of Scope
Example Epic Template
20
Epic Lightweight Business Case
When required, a lightweight business case may be produced.
21
Features and ReleasesMidrange targeting and planning
22
Decomposing the Work - Feature
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Epic
Repeat the Process• Identify Acceptance Criteria• Decompose Acceptance Criteria to component
assets• Verify that component assets can be
accomplished within one release• Verify each asset has well defined acceptance
criteria of its own
23
The Feature• Definition: A feature is an
asset that combined with other features satisfied an acceptance criteria of an epic
• Example: – Product – Complete Triathlon• Epic 1 – Complete Swimming course• Epic 2 – Complete Biking
course– Feature 1: Acquire
bicycle– Feature 2: Practice on
comparable course– Feature 3: Execute
bike race on day of competition
• Epic 3 – Complete Running course
• Simile: Also referred to as Child Portfolio Item within Version One
• Characteristics:– Features should be
decomposed to be small enough to be accomplished within one release to production
– Features will take one or MORE sprints to accomplish
– Features will have one or MORE user stories
– Features are generally assigned to a single team, although may be vertically sliced if required in a scaled agile environment
24
The Release vs Quarterly Planning• Release is an overused term • Simply, it is the bundle of features we are
going to put out to production to upgrade/increase our product’s capability
• Version One allows releases to be used 2 ways– Release with the Product on the tree is
the release going to production of all new code
– Release under the team is basically a container of one or more sprints worth of work within that team, grouped for reporting and status tracking purposes
• With our current cadence, we are releasing at the end of every quarter, making the two appear similar. You can release to production less or more frequently than quarterly, so it is important to make sure they are not confused for one another
• Quarterly planning is a term used to describe all the work we will do within the upcoming quarter
• Very often, we can base our mid to long range roadmaps on quarterly planning
• There is no specific “Quarterly Planning” place within the tool. We will simply plan releases and they will occur within the designated quarter
• As we are currently set up, we do quarterly planning with teams who have dependencies upon the work their fellow teams are producing. This is much like release planning. The similarity is that currently we are having one release per quarter… by design … and the terms quarterly planning and release planning are being used interchangeably
25
Tactical Elements of Sprints & User StoriesWhere the work is done and the rubber meets the road
26
Decomposing the Work – User Story
Story 1
Story 2
Story 3
Story 4
Story 5
Feature
Repeat the Process• Identify Acceptance Criteria• Decompose Acceptance Criteria to component
assets• Verify that component assets can be
accomplished within one release• Verify each asset has well defined acceptance
criteria of its own
27
The User Story• Definition: Work
expressed in terms of an end user perspective. It should describe the user, what they want, and why.
• Simile: Also referred to as a backlog item within Version One
• Characteristics: All stories should follow the INVEST criteria if at all possible.
• User Stories should only persist within the sprint that they start in.
INVESTLetter Meaning Description
I Independent
The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable
User stories, up until they are part of an iteration, can always be changed and rewritten.
V ValuableA user story must deliver value to the end user.
E EstimableYou must always be able to estimate the size of a user story.
S Small
User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable
The user story or its related description must provide the necessary information to make test development possible.
28
When is a Backlog Item NOT a user story• Teams not using scrum
may be using the backlog item as their task level work container
• This is a valid use, and is common on non-IT related teams and also for infrastructure teams
• Teams with work of this nature still need to insure they have adequate acceptance criteria so that completion of the backlog item is not left to subjective judgement at the end
29
The Sprint
• Definition: The sprint is an iteration that is included in Agile SCRUM that focuses on producing value that can be released either incrementally or in conjunction with other sprints to create a minimally marketable feature.
• Sprints contain a backlog of user stories committed to by the team
• It is common for an iteration to have a planning session, several daily standups, a review and a retrospective
• Sprints can last for 2, 3, or 4 weeks
Decomposing the Work – The Task
30
Task 1
Task 2
Task 3
Task 4
Task 5
User Story
Repeat the Process• Identify Acceptance Criteria• Decompose Acceptance Criteria to component assets• Verify that component assets can be accomplished within
one release• Verify each asset has well defined acceptance criteria of its
own• Tasks are very simple… they are the building blocks of each
user story. • Good tasks are simply testable• Good tasks are between 2 – 16 hours in duration as a rule of
thumb
31
Integrating with Version OneThe “Tree” and how it relates to the way we break down work.
32
A Project & Version One• Definition: An individual or
collaborative enterprise that produces some valuable effect or asset and has a definite beginning and end
• When working with Version One, drop the word “project” from your vocabulary whenever you see it in the tool, and replace it with “bucket” or “container”
• Version One over uses and misuses the term project to the point of potentially great confusion
• Simile: Also referred to as a NODE within Version One
33
The Asset• Definition: An asset is a
pronoun. It is a general term that is applied to any level of work decomposition.
• The asset is in common usage due to the need to refer to work in a nonspecific variable– Common Usage Example: We
decomposed the epic to 12 assets, but only 10 could be accomplished within a release to production. We broke the last 2 assets into another 5 smaller assets, leaving us with 15 features for the next release.
• Simile: An asset may be referred to as a portfolio item, child portfolio item, backlog item, or even less frequently as a task within Version One
• Characteristics:– Can refer to anything from a
node to a level of work– Used when work is less
defined and requires further definition to be classified correctly
– Often used in planning or training situations where pronouns are more applicable than more precise descriptions of work to convey a point
34
Version One Tree: Product Level
35
Version One Tree: Team Level
36
Appendix ABacklog Definitions
37
Backlog
Product Backlog
• When someone refers to the Product Backlog they are referring to the prioritized wish list of all the things that the product should be capable of once completed.
• It’s important to note this backlog can contain Epics, Features, or a combination of both.
• A functional, planning ready backlog will have enough high priority epics decomposed to feature level to fill the next planned future product release to production
Portfolio Backlog
• A portfolio backlog is a list of projects or programs that are listed in strategic and financial priority in the order from most beneficial to least
• The list represents the major initiatives or work we will fund in IT
• For development, that work is usually expressed in terms of products
• For purely infrastructure projects or programs, the work may be classified in terms customized to the infrastructure to be added either descriptive of the work (i.e. New Data Center) or designated by some customized code name (i.e. “Project Cortez”)
38
Backlog (Continued)Quarterly Backlog
• Some teams have embraced quarterly planning. If they have a list of milestones, epics, and/or features to be completed within that quarter that list once prioritized is the quarterly backlog
• It is important to not confuse the quarterly backlog with a release backlog
• A quarterly backlog may contain no production releases, one production release, or multiple production releases
• It is not uncommon to have a quarterly backlog AND a release backlog, however some teams choose to supplant the release backlog with a quarterly backlog and will only do midrange planning using the quarter as the unit of measure
Release Backlog
• The release backlog is a prioritized list of work decomposed to feature level that contains a list of all value added functionality and required infrastructure to be added in the next release to production
• A release backlog is often used as the list of features referenced at time of release planning, and in scaled mult-team efforts will contain features to be divided amongst all participating teams
• Do not confuse a release backlog with a team backlog. If you have a single team doing all the work within a release to production, then they represent the same work. HOWEVER… if you have multiple teams a release backlog will have the work for all teams while a team backlog will contain only the work for a single team for a release
• SAFe refers to the Release backlog as the program backlog. Be aware of this, so if you see within the tool or someone mentions a “program backlog” you will not be confused
39
Backlog (Continued)Team Backlog
• This contains all the work decomposed to the feature level, user story level, or a combination or the two. The team backlog contains the prioritized work for a single team to complete in a single release to production.
• Do not confuse this backlog with a Sprint backlog. While some teams do go to production every sprint, and in those occasions a sprint backlog does contain the same work as the Team Backlog, we rarely have a minimal marketable feature completed within one sprint
• When multiple sprints of work must be completed before we have something we can release to production the team backlog will actually contain two or more sprint backlogs of features
Sprint Backlog
• This is the team backlog of work decomposed to the user story level to be used in sprint planning and contains the work to be accomplished within one iteration or sprint
• If your team does not use iterations… and is a Kanban style team… you may or may not use a sprint backlog within the tool to present your Kanban queue
• Remember… this is a list of work to be accomplished within a sprint and all user stories should be ideally finished within whichever sprint they are started.
40
Appendix BInfographics
41
Product Life Cycle down to Sprint Infographic
Jan-16 Dec-17Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Jan-16 Dec-16Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
1/1/2016 - 12/31/2017Product Life CycleMore than 1 year
2 years shown
1/1/2016 - 12/31/2016Single Year Development Budget
1/1/2016 - 3/31/2016Q1
1/1/2016 - 3/31/2016Q1
4/1/2016 - 6/30/2016Q2
4/1/2016 - 6/30/2016Q2
7/1/2016 - 9/30/2016Q3
7/1/2016 - 9/30/2016Q3
10/1/2016 - 12/31/2016Q4
10/1/2016 - 12/31/2016Q4
Jan-16 Jun-16Feb Mar Apr May Jun
1/1/2016 - 3/31/2016Q1
4/1/2016 - 6/30/2016Q2
Jan - AprRelease to Production
Jan - AprRelease to Production
Apr - JunRelease to Production
Apr - JunRelease to Production
Jan - JanSprint 1
Jan - FebSprint 2
Feb - FebSprint 3
Feb - MarSprint 4
Mar - MarSprint 5
Jan-16 Feb-16Feb
Jan - AprRelease to Production
Jan - FebSprint 2
Jan - JanSprint 1
Epics exist within the product life cycle
Best practice: Epics should be as small as they can be… perhaps requiring work over 2 -3 releases to production
Features exist within a single release to production, but may span 1 or more sprints within that release
User Stories exist within a single sprint . If work is required to hold over to subsequent sprints, best practice is to split the user story into two stories, one for each sprint
Tasks exist within a single sprint, like user stories.
Best Practice: A task should last no more than 2 working days before being completed. Larger tasks should be broken down to smaller tasks if possible
42
The Cycle of Decomposition
Product
Acceptance
Criteria
Epic
Epic
Epic
Epic
Epic
Epic
Acceptance
Criteria
Acceptance
Criteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
3rd
Feature
Feature
Feature
AcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria
AcceptanceCriteriaAcceptanceCriteria
Story
Story
Story
StoryStoryStory
StoryStoryStoryStoryStoryStoryStory
Story
Story
StoryStoryStory
Story
Story
Story
43
Agile Terms & Version One TermsPerfectSer
veIT
NODE
Portfolio Item
Child Portfolio
Item Child
Portfolio Item
Backlog Item
Backlog Item
Task Task Task Task
User Story
Feature
Portfolio Item
Feature
Epic
Product
Epic
Best Practice: Portfolio Item is 1 year or less in duration
Best Practice: Child Portfolio Item only persists within a release to production
Best Practice: Backlog Items only persist for one Sprint
44
Appendix CMiscellaneous Definitions
45
The Initiative• Definition: An initiative is
a large scale effort possibly requiring work both within and outside of IT.
• Initiatives are generally strategic in nature
• Initiatives will lack detail level specifics
• Initiatives are often accompanied by a feasibility study and business case for funding consideration
• Characteristics:– High level– Used in strategic planning– May take less than one
year, but may stretch across multiple budgetary years
– Can be larger than individual product life cycles
– Can include work both within and outside of IT
46
Strategic vs Tactical Planning• Strategic planning is high level• Focused on milestones and
product level deliverables• Product road map and even
release planning are considered strategic level planning
• Strategic level planning has fewer details, and is more focused on providing larger goals to be achieved
• Funding is often done at the Strategic level, due to the level of detail presented and the fact that it is still very resistant to change and adjustments due to obstacles
• Tactical planning is more actually closely aligned to work that must be done at the mid range and detail level
• Tactical planning is around the sprint planning and task planning level
• Used more as a executable plan of action to produce assets of value
• We often track the actual hours spent on tactical assets, such as tasks, for purposes of rolling that information up to capitalize when strategic elements are deployed to production
47
Product Life CycleDefinition
• The stages of a product from it’s introduction until the product is eventually retired
• This is usually expressed in stages, and depending upon whether you are technical or more marketing focused those stages may vary.
• These stages do follow a pattern, however. – Initial introduction or product design and
development– Operations where enhancements are
introduced and where sales revenue typically increases
– Maturity during which the product enhancement effort and revenue stabilize
– Decline where the product revenue eventually becomes too little to be viable. During this phase bug fixes and support often cease and the product is eventually retired
Characteristics
• Product Life Cycle can span multiple projects, and often a product manager is assigned to represent the needs of the product from introduction and development thru the retirement of the product.
48
The Asset• Definition: An asset is a
pronoun. It is a general term that is applied to any level of work decomposition.
• The asset is in common usage due to the need to refer to work in a nonspecific variable– Common Usage Example: We
decomposed the epic to 12 assets, but only 10 could be accomplished within a release to production. We broke the last 2 assets into another 5 smaller assets, leaving us with 15 features for the next release.
• Simile: An asset may be referred to as a portfolio item, child portfolio item, backlog item, or even less frequently as a task within Version One
• Characteristics:– Can refer to anything from a
node to a level of work– Used when work is less
defined and requires further definition to be classified correctly
– Often used in planning or training situations where pronouns are more applicable than more precise descriptions of work to convey a point
49
The Epic• Definition: An epic is an
asset, either expressed in terms of a broad/ large milestone or product capability
• Example: – Product – Complete
Triathlon• Epic 1 – Complete
Swimming course• Epic 2 – Complete
Biking course• Epic 3 – Complete
Running course
• Simile: Also referred to as Portfolio Item within Version One
• Characteristics:– Epics by definition are so large that
details may not be possible at the beginning
– Epics can be treated as projects, with what is in scope, out of scope, and acceptance criteria defined in some form of informal documentation
– Epics may span releases to production, quarters, etc., but will not extend past the product life cycle
– One or more Epics satisfy the acceptance criteria of the Product
– One or many teams may collaborate to build an epic
50
The Feature• Definition: A feature is an
asset that combined with other features satisfied an acceptance criteria of an epic
• Example: – Product – Complete Triathlon• Epic 1 – Complete Swimming course• Epic 2 – Complete Biking
course– Feature 1: Acquire
bicycle– Feature 2: Practice on
comparable course– Feature 3: Execute
bike race on day of competition
• Epic 3 – Complete Running course
• Simile: Also referred to as Child Portfolio Item within Version One
• Characteristics:– Features should be
decomposed to be small enough to be accomplished within one release to production
– Features will take one or MORE sprints to accomplish
– Features will have one or MORE user stories
– Features are generally assigned to a single team, although may be vertically sliced if required in a scaled agile environment
51
The Feature• Definition: A feature is an
asset that combined with other features satisfied an acceptance criteria of an epic
• Example: – Product – Complete Triathlon• Epic 1 – Complete Swimming course• Epic 2 – Complete Biking
course– Feature 1: Acquire
bicycle– Feature 2: Practice on
comparable course– Feature 3: Execute
bike race on day of competition
• Epic 3 – Complete Running course
• Simile: Also referred to as Child Portfolio Item within Version One
• Characteristics:– Features should be
decomposed to be small enough to be accomplished within one release to production
– Features will take one or MORE sprints to accomplish
– Features will have one or MORE user stories
– Features are generally assigned to a single team, although may be vertically sliced if required in a scaled agile environment