![]() ![]() 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. 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. For example, we might include some mockups in the epic description or links to more useful information that we find along the way.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. Connections: Details of the system-wide dependencies and any other specifically-related Epics.Īs work on an Epic progresses, the description often changes or gets added to.Communication Processes: Parameters for how the team will communicate around this work such as the dedicated Slack channel, standup schedule, links to meeting notes, etc.Squad: The defined team working on the Epic, and in which role, e.g., front-end, back-end, DevOps, QA, marketing, etc.Goals: Measurable goals for the work, e.g., Increase use of X feature by Y%, by Z date.Open Questions: A sort of pre-mortem to address or at least acknowledge any FAQs or unknown answers.Out of Scope: Specific items or problems that we won’t be addressing with this work.In-depth details should be kept to specific Stories. Proposal (or Scope): An overview of the scope of the work.Background: Any other background information needed, e.g., links to research docs we’ve carried out to inform this work.We include as much info and data here as possible. Summary: A summary of the unsolved user problem(s) that the epic is trying to address.We’re in the process of creating a definitive template for our descriptions but, right now, most of the following information is usually present in them: We like to include lots of information in our Epic Descriptions, acting as a single source of truth for what the work is for. Behind every good Epic is a great Epic description! To keep things tidy, we archive our Epics a year after they are marked as Done. Grouping similar content with infinite scope (we use labels instead).Įxamples of some recently completed Epics at Shortcut:.Ongoing projects within a particular team that don’t have an end date or a defined stopping point (we use Projects instead).Endless backlogs (we use Projects instead).There is a start/ end date or outcome to the work.There is a specific scope to the work that defines when an Epic will be deemed complete.More than one story is needed to achieve the goal.Epics should always be for a finite period of time and ideally, be assigned to a Milestone. ![]() At Shortcut, an Epic is a collection of stories that, when completed, will achieve a specific goal or outcome. The standard definition of an Epic is a large body of work, a large user problem that can be broken down into more than one story. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |