It is a Product Manager’s job to determine what to build, it’s an engineer’s job to determine how to build it.
Epics contextualize and group requests:
- PMs are problem-solvers of Epics, developers are problem-solvers of stories
- 80% of prioritization should be done at the Epic level
- More than just a collection of stories, Epics should holistically solve a problem YOU identify
Product Managers work to follow a flow such as:
- Identify Epics
- Estimate Epics
- Prioritize Epics
- Pick Epic(s) for Sprint #1
- UI Design (optional)
- Write stories
- Estimate stories
- Finalize scope of sprint #1 with stories
- Development begins
- Pick Epic(s) for Sprint #2 *
Rinse and repeat!
*Doesn’t mean you can’t plan ahead
-
It all starts with the Epic. Epics are full-stack “problem themes” that teams should work together to solve, and move on once it’s complete.
-
Focus on the benefits of storywriting and AC, why it’s important to follow and the results it produces. Team can both understand the format and follow through on the development/testing methodologies that support the format.
-
Storywriting and Acceptance Criteria should be a core piece of a Product Manager’s job. It’s his/her responsibility to make sure they are accurate, complete, and move the product forward.
-
Story tracking system (JIRA, Pivotal, etc.) must be accepted and used as the source of truth organization-wide. You cannot be an effectively operating (and distributed) team without tracking stories and conversations.
-
All stories should be reviewed and accepted by a Product Manager (or equivalent) alongside support of QA review. This has the additional effect of forcing the team to rely on Acceptance Criteria to accept/reject stories.