A question keeps coming up in my Applying Professional Scrum classes: "What are epics and features, and how do we use them in the Product Backlog?" The Product Backlog is the to-do list for the team. Each item on the Product Backlog is a to-do item, and each to-do item is called a Product Backlog item (PBI). Epics and features are complementary Scrum practices that some Product Owners use. Like a folder structure, they are a convenient way to group PBIs or user stories into meaningful groups.
The Product Backlog is commonly summarized as the to-do list for the team. It includes an ordered list of all the work the team needs to do to maximize the value of the product resulting from the work of the Developers. The Product Backlog includes a list of new features for development, production bug fixes to resolve, fixes for technical debt for completion, and anything else that the Product Owner believes would add value to the product.
Technical debt is work required to improve or maintain the quality of the product. It can include activities such as upgrading the development environment, bug fixes, adding code comments, code reorganizing or refactoring, and removing workarounds. The Product Owner can delegate the creation of individual Product Backlog items but remains accountable for the overall content and order.
While the Product Owner is accountable for the content and order of the Product Backlog, they must regularly collaborate with the Developers on the Scrum Team. The Product Owner and the Developers work together to maximize the product's value. They collaborate on the sizing of higher ordered items and brainstorm ideas for what to include in the Product Backlog.
Manageable sizing of the highest PBIs is critical to delivering an Increment of value each Sprint, which is the cornerstone of Scrum. The Developers (not the Product Owner) should size the work because they know best what they can reasonably complete within the Sprint timeframe. Makes sense, right? After all, you don't want the Product Owner deciding that two people in one Sprint can build a house with just a bag of nails.
What does this have to do with epics and features?
Epics and features are a complementary, optional practice Product Owners can use to organize the team’s Product Backlog. I think of epics and features as a folder structure. (Note that some digital Product Backlog tools place features in higher-ordered folders with epics inside them. In others, it is the opposite. Either way is acceptable. The point is that these folders help the Product Owner organize the items in the Product Backlog into meaningful groups.)
How do you decide what is a Product Backlog item, feature or epic? A Product Backlog should be sized for completion within one Sprint. Generally, features or epics consist of multiple Product Backlog items, each adding to the feature or epic. The delivery of a complete epic or feature can span multiple Sprints.
Many tools, such as Jira and TFS, include this optional way to organize work in the Product Backlog.
Conclusion
Epics and features are a complementary Scrum practice that Product Owners can use to organize the Product Backlog. Similar to folders, they can help provide structure to your work. They can also be helpful when forecasting delivery or building a roadmap. The Product Owner can use this complementary practice if it fits their context and adds value for the team.
Comments