Utilizing Epics & User Stories in Agile Product Development

In agile product development, epics and user stories describe what your product needs to accomplish for the user and define what your product development team needs to build. They help organize work and create a shared understanding of the scope through the lens of the end user. For early-stage startups where time is a luxury, having a clear definition of the scope is crucial. It makes the difference between a team that seamlessly develops a user-centric product and a team that struggles in a chaotic and disorganized environment. 

What are themes, epics, and user stories? 

Themes, epics, and user stories are three pillars of agile product development. They provide a structural framework for planning, organizing, and managing product development tasks. Their primary function is to view the product through the user's eyes, guiding the creation of features that not only cater to user needs but also align with the business's strategic goals.

‍Not sure what to build? Check out our article on Scope Discovery.

Hierarchically, themes are at the top and contain epics, and epics contain user stories. It's common for larger startup product build-outs to start at the theme level, then break down into epics and, finally, user stories, which serve as the scope for sprint planning and development.

How we use epics and user stories at OAK’S LAB

At OAK’S LAB, we leverage epics and user stories differently, depending on the phase of the startup product build. In the initial phase, when the product is still an idea, our product development teams create all themes, epics, and user stories to paint a clear picture of what needs to be developed from scratch. This clarity of scope is crucial for planning and estimating the roadmap for the first MVP release.

As the MVP goes live and the product enters the versioning phase, we continue to utilize epics and user stories to define the work for each sprint. Our dual-track agile product development process ensures that each user story is reviewed and defined during Backlog Refinement meetings. This fosters a shared understanding, precise definition, and accurate estimation of each user story, allowing our teams to effectively prioritize the development for each sprint.

For less complex startup product builds, themes, epics, and user stories provide a sufficient scope definition. However, for larger, more intricate builds, our teams supplement this approach with functional specifications. This outlines the product in greater detail, documents the functionality of all screens, and serves as the full product scope that is continuously updated throughout the product development process.

Tips for epics and user stories

The ultimate aim of epics and user stories is to align your team's development efforts with the user's needs and the business's goals. They are meant to act as guides rather than dictators in your product development journey. Based on our experience of creating epics and user stories for 35 startup product builds, we recommend the following tips:

1. ‍Start with the user. Always write user stories from the end-users perspective, capturing their needs and aspirations. A clear user persona can be quite valuable in this process.
2. ‍Keep it simple. Write your user stories in a way that's easy to comprehend. Use clear language, avoid ambiguity, and maintain an active voice.
3. ‍Make it collaborative. Involve the entire team in the process of creating user stories. This not only enhances the quality of the stories but also helps the team's understanding of them.
4. ‍Focus on the 'why.' The value that each piece of work brings to the user should be the heart of your user stories. This approach will make sure that your team's work is always in alignment with user needs and business goals.
5. ‍Implement “Definition of Ready” and “Definition of Done.” These are fundamental concepts in agile product development. They provide clarity on prerequisites (Definition of Ready) and quality benchmarks for completing a user story (Definition of Done), keeping the team aligned on the expected outcome. Together, they keep the product development process structured, transparent, and efficient.

OAK’S LAB Definition of Ready Checklist for Agile Product Development

A user story at OAK’S LAB is ready when:

• The "Definition of Done" checklist is created.
• It is nested within a theme and epic that aligns with the business and product goals.
• It outlines the value it brings to the user and the business and why it's needed.
• It clearly defines subtasks, acceptance criteria, and testability.
• It identifies any additional testing requirements, such as Unit Tests, if necessary.
• All dependencies are identified and no blocking issues exist.
• Action items for dependencies are included.
• Designs have been completed and approved by stakeholders.
• Edge cases, empty states, and error states have been addressed and resolved, where possible, in consultation with the team.
• Plans are made to update project documentation if necessary.
• It is thoroughly understood by the team - an individual member can explain it in their own words, and the entire team is capable of conducting a demo.
• The engineering team has estimated it, and it can be completed within one sprint.

OAK’S LAB Definition of Done Checklist for Agile Product Development

A user story at OAK’S LAB is done when:

• All subtasks are finished.
• All acceptance criteria is met.
• Code has passed a peer review and merges without conflicts.
• If applicable, unit tests are written and pass successfully.
• It has been tested and approved by QA.
• No known defects exist (unless approved by the stakeholder) and releasing the story won't destabilize other system components.
• The design prototype is updated, so it remains the source of truth.
• The project documentation is updated, so it remains the source of truth.
• The feature or user story has been demoed to stakeholders and feedback has been incorporated if necessary.

In summary, themes, epics, and user stories form the backbone of agile product development. They guide teams as they build user-centric products. Together with the "Definition of Ready" and "Definition of Done" practices, these building blocks enable teams to effectively develop the product and contribute to the business goals. At OAK’S LAB, we've found that following these best practices has been key to building successful products in the startup landscape.