How to break up epics (for Product Managers)
•
2 likes•571 views
A quick guide for new and experienced product managers alike on how to break up epics into smaller user stories.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to How to break up epics (for Product Managers)
Similar to How to break up epics (for Product Managers) (20)
Recently uploaded
Recently uploaded (20)
How to break up epics (for Product Managers)
- 1. Proprietary and confidential HOW TO BREAK UP EPICS For Product Managers Amartya Sengupta Director of Product 1
- 3. Proprietary and confidential Epics and Themes 3 An epic is a large user story that is too big to implement in a single iteration and therefore should be disaggregated into smaller user stories. Examples: Retargeting, mCent Android app This is not to be confused with a theme, which is a collection of related user stories. Examples: First time user experience, callback rate
- 4. Proprietary and confidential Break up epics to move (and learn) faster 4 • Milestone drift - It’s difficult to estimate time required for big projects, so they may take longer than you’d think. When that happens, you may realize some components are less core than you’d previously thought. • Scope creep - When engineers, designers, data scientists, etc. know there’s a follow-on, they won’t try to cram everything into the first version • Sharper focus - The exercise forces you to think about what's at the heart of the feature • Learn and adapt - You may learn things from early phases that will change what you actually implement (or don’t implement) in later phases
- 5. Proprietary and confidential How to break up an epic… 5 What’s in the epic? Define the MVP Divide into phases Note: In this section, I’ll use the example of the original epic to create an mCent Android App (2014Q1). At the time, mCent was a website where users could install apps or refer friends to earn airtime.
- 6. Proprietary and confidential Step 1. What’s in the epic? 6 Epic • Take inventory of everything you might want to get done in the epic up front. This will make it easier to break things into phases, and it helps you communicate what’s being considered •Example: Initial mCent App •App in Google Play Store •Login, Signup (phone/email/FB) •View and complete offers •Referral funnel (refer, signup) •Top up •Promote in mCent web
- 7. Proprietary and confidential Step 2. Define the MVP 7 • Strip out features relentlessly until you have defined the minimum user story that can be released to prod that provides some value • Optimize for overall speed, not quickest to first release •Example: Initial mCent App •App in Google Play Store •Login, Signup (phone/email/FB) •View and complete offers •Referral funnel (refer, signup) •Top up •Promote in mCent web Epic Minimum Viable Product
- 8. Proprietary and confidential Step 3. Divide into phases 8 Don’t: Divide the epic into user stories that must all be done before benefit Do: Start with the MVP and move outward Engineers will just do the whole thing at once… 1 2 3 1 2 3 Each phase brings actual value (in prod)
- 9. Proprietary and confidential Step 3. Divide into phases 9 • Repeat the MVP exercise for each phase, optimizing for overall value •Example: Initial mCent App •Phase 0.5: Login with phone •Checkpoint supporting parallelization of work •Phase 1: Offers and top up •Phase 2: App in Google Play •Phase 3: Promote in mCent web •Phase 4: Referrals 1 2 3
- 10. Proprietary and confidential Pro tips 10 • Involve engineering early - it’s easy to make suboptimal decisions based on a misunderstanding of what’s easy/hard or the best way to accomplish a goal • Be flexible - Don’t blindly stick to your original plan. You may find out things in early phases that you didn’t expect • e.g. users don’t care about it, it’s more / less work than expected, unexpected things are more important, etc. • Pre-MVP checkpoint - Sometimes, for very large MVPs, I push for a checkpoint that works end-to-end to push engineering to get something out in the wild • Engineer not used to working on big project - get in the habit of getting something out in prod • Can also be useful to facilitate parallelization of the epic, if there is some initial piece that blocks others
- 12. Proprietary and confidential Case study: Member connections 12 •The situation •In 2015Q3, the growth team wanted to work on a series of social features to increase the stickiness of and social proof within mCent. In order to do that, we’d need to figure out each member’s mCent social network. •Unfortunately, this was a huge engineering task. We didn't have any social infrastructure, and we didn’t know how much we would need to build because we didn’t know how dense the mCent network was. •There was also little product proof beyond some member interviews and our own intuition that it would pay off, so we couldn’t just build it at any cost.
- 13. Proprietary and confidential Case study: Member connections 13 •Step 1: What’s in the epic? •User-managed connections •Connect with your friends •Add / remove connection •Pull address book (phone, gmail, facebook, etc.) •Privacy management •Back-end connection database •User-facing benefit •Refer your non-mCent friends •Activity of mCent friends (completions, referrals, etc.) •Reporting - number of connections, connections, etc.
- 14. Proprietary and confidential Case study: Member connections 14 •Step 2: Define the MVP •User-managed connections • Connect with your friends • Add / remove connection •Privacy management •Pull address book (phone, gmail, facebook, etc.) •Back-end connection database •User-facing benefit •Refer your non-mCent friends •Activity of mCent friends (completions, referrals, etc.) •Reporting - number of connections, connections, etc. Commentary User management and the second user- facing benefit could be stripped out
- 15. Proprietary and confidential Case study: Member connections 15 •Step 2: Define the MVP •User-managed connections • Connect with your friends • Add / remove connection •Privacy management •Pull address book (phone, gmail, facebook, etc.) •Back-end connection database •User-facing benefit •Refer your non-mCent friends •Activity of mCent friends (completions, referrals, etc.) •Reporting - number of connections, connections, etc. Commentary Just learning the density of the mCent network was useful, even without user- facing benefits
- 16. Proprietary and confidential Case study: Member connections 16 •Step 3: Divide into phases •Phase 1: Automatic member connections + measure the density of network •Phase 2: Refer your non-mCent friends •Phase 3: Friend completions in activity feed •Phase 4: User management of connections Commentary Based on Phase 1 learnings, we never implemented 2 or 4!