To do that, consider a couple of thoughts that Jeff Patton shared in his book User Story Mapping: You should view user stories from an outcome based perspective. It looks at user stories through the all too common output based perspective.
/PortfolioAnalysisforBeginners-5a011cc7ec2f64003784666f.jpg "portfolio epic definition")
Looking back on that definition now, I realize it’s not quite right. User stories will be decomposed to a level that can be delivered in a single iteration and provide value.” (If you’re a Scrum purist, replace “iteration” with “sprint”.) In Beyond Requirements, I defined user story as “a description of a product feature used for planning and scoping purposes. Use one of the of the other terms for that purpose – I suggest epic. Use feature to describe something your product does or has, don’t use it as a certain type of product backlog item. That means that features are helpful for distinguishing the different versions of a product (for example what options each version of a product does and does not have.) See this feature listing for Evernote as an example. This use of feature is consistent with the definition of feature:Ī distinctive attribute or aspect of something, orĪ prominent or conspicuous part or characteristic
In fact that’s what benefits point to as that post describes:īenefits are the outcomes or results that users will (hopefully) experience by using your product or service I like this definition better because it provides a nicer tie in with outcome based thinking. Benefits: What’s the Difference & Why It Matters and has much more of a marketing slant to it. That definition is taken from the article Features vs. Since I wrote Beyond Requirements, I’ve refined my view of features and now think of feature in these terms: That definition is written from the context of business analysis so it is inevitably going to relate to requirements. In Beyond Requirements, I used the Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3 definition of feature: “A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.” I need to start by clarifying the use of this particular word, because some of the other definitions depend on it.
Portfolio epic definition free#
You can sign up for a free trial, purchase a subscription to Linked In Learning, or just purchase the course. Want to know more about Themes, Epics, Features, and User Stories from a different perspective, take a look at this video (Affiliate link) from Angela Wick’s Linked In Learning Course Agile Product Owner Role: Foundations. Keep your product backlog hierarchy to two levels. User stories are for the team.ĭon’t use themes for prioritization. Epics are for stakeholders, users, and customers.User stories are placeholders for a conversation.User stories identify what someone wants to accomplish with your product and why.
Portfolio epic definition software#
In case the length of this post is intimidating, here are the key points.Ī feature is something your product has or is… this is typically functionality offered by a software program that enables users to do something.īenefits are the outcomes or results that users will (hopefully) experience by using your product or service. Where those situations exist, I’ll explain how I use a particular term and why. Unfortunately, those founders have also decided to use some terms in their frameworks differently than how they are used in other frameworks. The inventors of the various agile frameworks love to come up with new names in an attempt to emphasize the difference between their ideas and concepts that currently exist. Some of my definitions may be controversial, in part because there are different ways to define the same word depending on your framework of choice. With that in mind, here are some definitions for these key product backlog terms followed by a more in depth explanation of why I chose the definitions I did. I’d like to help you avoid those discussions in the future and help you help your customers get the outcomes they seek. Yes, I realize that answer is not particularly satisfying, especially to anyone who has lost an entire day of their life to a semantic argument about levels of a product backlog hierarchy. Have you ever been confused about whether a product backlog item is an epic, feature, or user story?Įver questioned whether you needed themes?Īs long as your team understands what the product backlog item means when you start to work on it, you really shouldn’t care if it’s called an epic, feature or user story.
0 kommentar(er)
