Table of contents
- What is agile development?
- What is an epic?
- Epics vs. user stories vs. initiatives
- How to write an epic
- What to include in an epic
- A real-world example of an epic
What is agile development?
Agile development is an iterative process that enables software development teams to accelerate their time to market by fostering and embracing a culture of continuous learning. Agile teams learn by doing.
In product development, the strategy and roadmap is based on data and insights from the market, which is always evolving. The product team must be dynamic enough to adapt to shifting requirements and user needs. This is a core agile value as outlined in the Agile Manifesto.
It’s not enough to anticipate user needs because they are ever-evolving. Agile development teams work in short, iterative sprints, which affords them the flexibility and pragmatism required to deliver complex products.
What is an epic?
An epic is a feature or functionality consisting of multiple building blocks and scenarios. Epics are derived from themes or initiatives and can be segmented into smaller pieces called user stories.
An epic can span across multiple sprints, teams, and even projects. The theme, epic, and user stories share the same strategic goal at different levels of the focus area.
Consider the example of building a house. If an initiative is like building the ground floor, an epic is like creating a kitchen and a user story is like building a wall, with each brick being a task.
Agile development breaks down a broad product vision into small, achievable tasks that produce frequently updated results.
Like building a house, the product development lifecycle can feel overwhelming. The direction of where to start may not be apparent to everyone working on the product. But it helps to break down the larger initiative into several themes — for example, building the foundation and the ground floor.
You can break it down further into epics — e.g., building each room — and then even further to building a wall. This gives us a clearer picture of what we need to achieve today to make meaningful progress toward the strategic initiative.
In large organizations, where several cross-functional teams are involved in product development, epics help everyone get on the same page around development goals, dependencies, and priorities.
Epics vs. user stories vs. initiatives
Depending on the organization’s size, the product’s complexity, the composition of initiatives, themes, and epic may vary in dimensions. Smaller products or organizations may only have one top hierarchy. However, if the design of scale is used within the circumference of an organization, the basic idea is the same.
A product roadmap boils down to smaller, achievable tasks. In any product development cycle, multiple features concurrently fulfill users’ needs. But that doesn’t mean the product needs to be fully developed with all features complete at the time of launch.
A core value of agile development is quick delivery and learning by doing. Breaking the theme into various levels helps shorten the product development lifecycle from ideation to execution.
This segmentation also helps in prioritization by slicing the initiative into more manageable minimum viable products (MVPs). The MVPs can be developed and launched to the user within a short period, allowing the team to learn and iterate, validate ideas, and adjust the roadmap as necessary.
Regardless of how you structure the hierarchy structure of themes/initiatives, epics, and user stories, each level is defined with a purpose.
Themes and initiatives
Themes and initiatives define the product vision. The big idea is segmented into strategic goals.
The purpose of the theme is to be the North Star, providing a clear picture of the entire organization’s focus area.
The initiative can be closing a market gap, addressing a pain point, innovation, market fit, etc.
Epics
An epic is the actualization of the product roadmap. The initiative is further segmented into defined features to develop.
Epics create alignment between the organization and the product development when it comes to prioritization.
User stories
A user story is user-focused and driven by user value.
Even though the product vision and roadmap come from within the organization, development should always be completely user-centric. User stories help the development team empathize with the user and clarify the value produced as a result of the product from the customer’s perspective.
How to write an epic
An epic is a high-level requirement of a feature. While writing an epic, your goal is to align stakeholders with your product vision and roadmap. To achieve that alignment with clarity and focus, you should provide all the relevant information, including any dependencies, clarify any misunderstandings, and establish a clear direction with a measurable goal.
Collaboration is key to a good epic description. Though the product manager is responsible for writing an epic spec, they’re not expected to be an expert at all levels. When creating an epic spec document, collaborate with your team to discuss and align on solution design, UX design, and the customer journey. Bring in all the required knowledge and expertise early to avoid getting stuck later on.
What to include in an epic
Every development is different, so the epic specs will differ from product to product. Some epics include granular detail while others only highlight high-level requirements.
An epic should include at least the bare minimum information the product team requires to get started on user stories and prioritize tasks to solve the customer’s needs as efficiently as possible.
A basic epic is structured as follows:
Introduction
The introduction should outline the “why” and the “what” — the reason for prioritizing and developing the feature and user pain points to solve. You should also include the metrics and KPIs for measuring the performance.
In addition, any documentation or early wireframes you can provide go a long way toward establishing a common understanding of the goal and path to successful delivery. Some things to consider:
- Summary of features and reasons for developing them
- Performance metrics and KPIs
- Links to specific documentation
- Marketing plans and legal requirements (if any)
- Early wireframes
Product requirements
An essential objective of the epic is to establish a shared understanding of the development goal. The epic should include the feature’s functional and nonfunctional requirements.
The product requirements documentation might mention availability in multiple languages or on multiple devices, for example.
Design requirements
You should always collaborate with the UX designer to write the design requirement. They are the expert and will surely have insights to share from their countless user test experiences.
Examples of product design requirements might include things like:
- Where to place search functionality for each device
- A request for a prototype to simplify future group discussions
Engineering requirements
You should strive for alignment with the target architecture while compiling the high-level requirement in an epic. Like the tech stack or solution design, consideration in the early stages will help you estimate more accurately and maximize efficiency down the line.
For example, let’s say the engineering team wants to create an API to integrate with some existing database functionality to fetch a list of songs. Investigating something these opportunities during the initial stages of creating the epic helps you avoid incurring inadvertent technical debt.
KPI and metrics
KPIs guide every product development cycle. A concrete set of metrics and goals will help the teams focused and motivated to hit stated objectives.
KPIs should be tangible and measurable. A vague KPI is of no value and does not motivate action. At first, some KPIs may seem not measurable, but after aligning with data analysts, there is always a way to measure development value in numbers.
For example, increasing customer satisfaction is a good KPI, but a little vague. Instead, try adding metrics such as net promoter score (NPS) or the number of times a user interacts with a new functionality in one session.
A real-world example of an epic
Let’s consider the example of a music streaming app to demonstrate how an epic is structured. Suppose you want to add search functionality to the app. The database contains more than 1 million songs from across the globe — a key differentiator for your product, so the search functionality is deemed critical to enable users to find whatever music they are looking for intuitively.
Using the epic template below, our epic would look something like this:
Keeping with this example, an epic spec document pertaining to the items populating the template above might read as follows:
Introduction
The new search functionality will allow users to narrow down their search and offer suggestions to help them find the music they want to listen to instantly.
Our research shows that 86 percent of our user base is interested in the search functionality. Since the most commonly identified problem with searching music is that people can’t remember or recognize the song’s name, a voice search service shows the most considerable demand.
We expect this functionality will increase the number of songs played per user by 10 percent on average, which will result in approximately 30 percent additional time spent per month using the app.
Product requirements
- Users can initiate a search from multiple suitable pages in the app
- Users can begin a voice search
- AI integration in search functionality
- Customized search suggestions
- Should include tracking on each page
Design requirements
- Display search suggestions in a list filtered is different categories
- Design should work with accessibility rules
Engineering requirements
- New API’s to be built only in the new backend system
- Dependencies shared with the AI integration team
KPIs
- Conversion rate: Clicks on the suggested list of songs
- Use of voice search: Avg. use per session per user
A good epic spec document will help you foster collaboration and achieve alignment across your team and your organization. Epics also make it easier to write user stories, slice down and prioritize the backlog, and run a smoother scrum.
Conclusion
In agile development, all the frameworks, structures, and processes are created with one principle: the ability to be flexible and deliver quickly to learn iteratively.
The main goal of any process or documentation is to create alignment, avoid misunderstanding, and minimize inadvertent technical debts while accelerating time to market.
The post What is an epic in agile? Complete guide with examples appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/U2kpsRc
via Read more
