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


AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria


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 - 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




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



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.

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Independent

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Negotiable

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Valuable

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Estimable

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Small

https://en.wikipedia.org/wiki/INVEST_(mnemonic)#Testable

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 - JanSprint 1

Jan - FebSprint 2

Feb - FebSprint 3

Feb - MarSprint 4

Mar - MarSprint 5

Jan-16 Feb-16Feb


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



AcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteriaAcceptanceCriteria


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















51















definitions and terms r1

Documents