Hi Emmanuel,

Thank you for sharing your feedback and question. I recommend working with themes in addition to epics. I use a theme to describe a larger feature or capability like notification. You can think of a theme as a category or “chapter”. This allows you to progressively break down epics into user stories until they are done while still being able to add new notification stories.

Does this help?

I have a question about iterations.

We create an epic to cover specific features or user experience. e.g.: I want to be reminded to do X on a daily basis. We then come up with a solution, which we split into user stories. We release live, collect feedback, and then carry on iterating to improve the original problem we are trying to address.

1. If we keep the same epic and add new stories, the epic never gets delivered and always has new stories added to it.
2. The alternative is to create a new epic with a “version number” (e.g.: I want to be reminded to do X on a daily basis V6)

I think none of the solutions above really work, we should try being more creative about naming each new iteration. if the solution is different (ability to set up auto-reminder vs highlighted new content in the app each day, for instance, we create a separate epic with a name specific to the solution we are implementing). If the changes required for a new iteration are simple enough and don’t really qualify for a new epic, we have user stories added to the product backlog but with no epic attached to them.

Would love to hear your thoughts on this.

Many thanks
Emmanuel

Thank you for your comment Dieter. Please have a look at my articles “Creating Effective Sprint Goals” and “When Should Product Backlog Grooming Take Place?“, which should answer your question. If that’s not the case, then please let me know!

Three possible answers
1) give the team time to prepare the session (for introverts)
2) deliberately have two sessions (for extraverts)
3) have a ready story not as a result of a grooming session but as a result of a sprint itself

Which one do you favor? Do you have other alternatives?

Hi Carolina,

Thank you for your feedback. I like to distinhuish between product capabilities or features, epics, and user stories. I include capabilities and features on a product roadmap, but not epcis. Please take a look at my article The Product Roadmap and the Product Backlog for more information.

Hope this helps!

I found this article very interesting. I wonder if you could share a more practical example of how it would all come together. In your view, is an epic a higher level goal (perhaps linked to an element of the roadmap, with an approx timeline) which would then be divided further into sprint goals (which would then broken into smaller stories?).

Thanks!

Thanks for your feedback, Anup. I am not aware of any general nemonic convention. I suggest that you rework your epics and ask the dev team to estimate the remaining effort as they are partially implemented. Hope this helps.

Thanks

Hi Roger, Thanks for your comment. I derive epics from the goals of the personas, and I use them to sketch the overall product functionality. I prefer to decompose epics just in time based on the sprint goal / hypothesis by breaking out detailed stories required to reach the goal. This minimises the upfront story writing effort, and it makes it easier to update the Product Canvas / backlog. Epics, of course, capture only the product functionality. For more complex interactions, I like to work with scenarios, storyboards, and workflow diagrams: http://www.romanpichler.com/blog/agile-scenarios-and-storyboards/ I find it helpful to appreciate that there are different ways to capture product ideas and requirements. I recommend choosing the techniques that work best for the product being developed.

It’s tricky, though. I see two common mistakes people make with epics and decomposition.

1. Folks like Dean Leffingwell favor epics like “Video Streaming”, which to me don’t really capture what problem we’re solving for the user. It seems to me that epics should capture the goals and perspective of the user.

2. More commonly, story decomposition usually occurs along functional lines.

I wrote a blog entry with a fictional “epic conversation” to illustrate the common mistakes with stories and epics and how to deal with them.

The main opportunity that agile practitioners seem to miss when it comes to story splitting is dividing epics or stories into versions that iteratively strengthen the acceptance criteria. I’d love to get your thoughts on this idea, Roman.