Definitions and Terms R1
Download as PPTX, PDF3 likes1,370 views
The document provides an overview of concepts related to breaking down work in an agile environment. It defines key terms like initiatives, epics, features, releases, sprints, and stories. It describes the process of decomposing work from high-level portfolio items and products down to lower levels like epics, features, and stories. It explains how these different levels relate to each other and how planning is done at different levels from strategic to tactical. It also discusses how these concepts are represented in the Version One tool.
Definitions and Terms R1
- 1. Breaking Down the Work Terms, Definitions, & Process
- 2. Agenda Overview 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 Session Appendices A, B, C
- 3. 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 4
- 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 5
- 6. The Cycle of Decomposition 6 Top Unit Acceptanc e Criteria 2nd Unit 2nd Unit 2nd Unit 2nd Unit 2nd Unit 2nd Unit Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria 3rd 3rd 3rd 3rd 3rd 3rd 3rd 3rd 3rd3rd 3rd 3rd Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th 4th
- 7. Version One – Key Assets Overview 7
- 8. So, what does this look like overall? 8 PerfectServ e IT 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? 9 PerfectServ e IT 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
- 10. 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? 11 Jan-16 Dec-17 Feb 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/2017 Product Life Cycle More than 1 year 2 years shown 1/1/2016 - 12/31/2016 Single Year Development Budget 1/1/2016 - 3/31/2016 Q1 4/1/2016 - 6/30/2016 Q2 7/1/2016 - 9/30/2016 Q3 10/1/2016 - 12/31/2016 Q4 Epic Jan-16 Dec-16 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1/1/2016 - 3/31/2016 Q1 4/1/2016 - 6/30/2016 Q2 7/1/2016 - 9/30/2016 Q3 10/1/2016 - 12/31/2016 Q4 Jan - Apr Release to Production Apr - Jun Release to Production Feature Jan-16 Jun-16 Feb Mar Apr May Jun 1/1/2016 - 3/31/2016 Q1 4/1/2016 - 6/30/2016 Q2 Jan - Apr Release to Production Apr - Jun Release to Production Jan - Jan Sprint 1 Jan - Feb Sprint 2 Feb - Feb Sprint 3 Feb - Mar Sprint 4 Mar - Mar Sprint 5 Story
- 12. Backlogs, Products and Epics OH MY! 12
- 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 13 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 14
- 15. 15 Intake Process: Represents IT Budget for Product Development 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 A Miracl e Occur s
- 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 16 Product Acceptance Criteria 1 Acceptance Criteria 2 Acceptance Criteria 3 Acceptance 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 17 Epic 3 Acceptance Criterial 1 Acceptance Criterial 2 Acceptance Criterial 3 Acceptance Criterial 4 Epi c 1 Epi c 2 Epi c 3 Epi c 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 18
- 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 19 Example Epic Template
- 20. Epic Lightweight Business Case When required, a lightweight business case may be produced. 20
- 21. Features and Releases Midrange targeting and planning 21
- 22. Decomposing the Work - Feature 22 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 23
- 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 24
- 25. Tactical Elements of Sprints & User Stories Where the work is done and the rubber meets the road 25
- 26. Decomposing the Work – User Story 26 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. INVEST 27 Letter 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 Valuable A user story must deliver value to the end user. E Estimable You 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 28
- 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. 29 • 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
- 30. 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 One The “Tree” and how it relates to the way we break down work. 31
- 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 32
- 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 33
- 34. Version One Tree: Product Level 34
- 35. Version One Tree: Team Level 35
- 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”) 37
- 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 38
- 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. 39
- 41. Product Life Cycle down to Sprint Infographic 41 Jan-16 Dec-17 Feb 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-16 Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 1/1/2016 - 12/31/2017 Product Life Cycle More than 1 year 2 years shown 1/1/2016 - 12/31/2016 Single Year Development Budget 1/1/2016 - 3/31/2016 Q1 1/1/2016 - 3/31/2016 Q1 4/1/2016 - 6/30/2016 Q2 4/1/2016 - 6/30/2016 Q2 7/1/2016 - 9/30/2016 Q3 7/1/2016 - 9/30/2016 Q3 10/1/2016 - 12/31/2016 Q4 10/1/2016 - 12/31/2016 Q4 Jan-16 Jun-16 Feb Mar Apr May Jun 1/1/2016 - 3/31/2016 Q1 4/1/2016 - 6/30/2016 Q2 Jan - Apr Release to Production Jan - Apr Release to Production Apr - Jun Release to Production Apr - Jun Release to Production Jan - Jan Sprint 1 Jan - Feb Sprint 2 Feb - Feb Sprint 3 Feb - Mar Sprint 4 Mar - Mar Sprint 5 Jan-16 Feb-16 Feb Jan - Apr Release to Production Jan - Feb Sprint 2 Jan - Jan Sprint 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 42 Product Acceptanc e Criteria Epic Epic Epic Epic Epic Epic Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Acceptanc e Criteria Feature Feature Feature Feature Feature Feature Feature Feature 3rdFeature Feature Feature Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Acceptance Criteria Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y Stor y
- 43. Agile Terms & Version One Terms 43 PerfectServ e IT 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
- 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 45
- 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 46
- 47. Product Life Cycle Definition • 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. 47
- 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 48
- 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 49
- 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 50
- 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 51