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!