An epic story can be thought of as a large user story which could be broken down into smaller stories. An epic may be delivered over more than one sprint or releases. Epics help in creating a better structure and hierarchy. Further, epics might have changes in their scope over time. Epics are a great way to roll up functionality into an abstract wrapper to defer the effort required to break it down into smaller chunks until later. Examples of epics could include: user registration, login, user preferences, search for products, search results page, add to shopping cart, cart checkout, payment, admin products, admin users, view transactions, etc. Each of these should be considered epics and will certainly require breaking down (aka splitting) at some point before they are ready for developers. Epics can form part of a story map which provides orientation to delivery teams and stakeholders on the overall scope of the work at hand. This prevents the team and stakeholders getting bogged down in the detail and provides an easy to consume overview or mental model. On an Agile project or work stream, typically the Business Analyst will work with the Product Owner and key stakeholders to identify the major epics of the system to be developed. The discussions are kept at the level as diving into the detail of each epic is usually a waste of time. It’s a waste of time because the detail will be lost over time and needs to be discussed at the point of development. When carving out epics for the work it’s important to go beyond just involving your business analyst. All members of the team should be involved in this activity so that they can provide expert input and guidance about the best way of going about solving the problem. Common related tasks associated with epics are estimation and sizing, story splitting, story writing, test strategy, and behaviour driven development techniques. In our Create Better User Stories workshop we cover this activity in detail.

I would like to speak with an advisor