how to write an epic hypothesis statement

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

What if we found ourselves building something that nobody wanted? In that case what did it matter if we did it on time and on budget? —Eric Ries

Portfolio epics are typically cross-cutting, typically spanning multiple value streams and Program Increments (PIs). SAFe recommends applying the Lean Startup build-measure-learn cycle for epics to accelerate the learning and development process, and to reduce risk.

This article primarily describes the definition, approval, and implementation of portfolio epics . Program and Large solution epics, which follow a similar pattern, are described briefly at the end of this article.

There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics are used to advance the Architectural Runway  to support upcoming business or technical needs.

It’s important to note that epics are not merely a synonym for projects; they operate quite differently, as Figure 1 highlights. SAFe generally discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup cycle (Figure 6).

Defining Epics

Since epics are some of the most significant enterprise investments, stakeholders need to agree on their intent and definition. Figure 2 provides an epic hypothesis statement template that can be used to capture, organize, and communicate critical information about an epic.

Download Epic Hypothesis Statement

Portfolio epics are made visible, developed, and managed through the  Portfolio Kanban system where they proceed through various states of maturity until they’re approved or rejected. Before being committed to implementation, epics require analysis. Epic Owners take responsibility for the critical collaborations required for this task, while  Enterprise Architects typically shepherd the enabler epics that support the technical considerations for business epics.

Defining the Epic MVP

Analysis of an epic includes the definition of a Minimum Viable Product (MVP) for the epic. In the context of SAFe, an MVP is an early and minimal version of a new product or business Solution that is used to prove or disprove the epic hypothesis . As opposed to story boards, prototypes, mockups, wire frames and other exploratory techniques, the MVP is an actual product that can be used by real customers to generate validated learning.

Creating the Lean Business Case

The result of the epic analysis is a Lean business case (Figure 3).

Download Lean Business Case

The LPM reviews the Lean business case to make a go/no-go decision for the epic. Once approved, portfolio epics stay in the portfolio backlog until implementation capacity and budget becomes available from one or more ARTs. The Epic Owner is responsible for working with Product and Solution Management  and  System Architect/Engineering to split the epic into Features or Capabilities during backlog refinement. Epic Owners help prioritize these items in their respective backlogs and have some ongoing responsibilities for stewardship and follow-up.

Estimating Epic Costs

As Epics progress through the Portfolio Kanban, the LPM team will eventually need to understand the potential investment required to realize the hypothesized value. This requires a meaningful estimate of the cost of the MVP and the forecasted cost of the full implementation should the epic hypothesis be proven true.

• The MVP cost ensures the portfolio is budgeting enough money to prove/disprove the Epic hypothesis and helps ensure that LPM is making investments in innovation in accordance with lean budget guardrails
• The forecasted implementation cost factors into ROI analysis, help determine if the business case is sound, and helps the LPM team prepare for potential adjustments to value stream budgets

The MVP cost estimate is created by the epic owner in collaboration with other key stakeholders. It should include an amount sufficient to prove or disprove the MVP hypothesis. Once approved, the MVP cost is considered a hard limit, and the value stream will not spend more than this cost in building and evaluating the MVP. If the value stream has evidence that this cost will be exceeded during epic implementation, further work on the epic should be stopped.

Estimating Implementation Cost

The MVP and/or the full implementation cost is further comprised of costs associated with the internal value streams plus any costs associated with external suppliers. It is initially estimated using t-shirt sizing (Figure 4) and refined over time as the MVP is implemented.

Estimating Epics in the early stages can be difficult since there is limited data and learning at this point. T-shirt sizing is a cost estimation technique which can be used by LPM, Epic Owners, architects and engineers, and other stakeholders to collaborate on the placement of epics into groups (or cost bands) of a similar size. A cost range is established for each T-shirt size using historical data. Each portfolio determines the relevant cost range for each T-shirt size. The gaps in the cost ranges reflect the uncertainty of estimates and avoid too much discussion around the edge cases. The full implementation cost can be refined over time as the MVP is built and learning occurs

Supplier Costs

An Epic investment often includes a contribution and cost from suppliers, whether internal or external. Ideally, enterprises engage external suppliers via Agile contracts which supports estimating the costs of a suppliers contribution to a specific epic. For more on this topic, see the Agile Contracts advanced topic article.

Forecasting an epic’s duration

While it can be challenging to forecast the duration of an epic implemented by a mix of internal ARTs and external suppliers, an understanding of the forecasted duration of the epic is critical to the proper functioning of the portfolio. Similar to the cost of an epic, the duration of the epic can be forecasted as an internal duration, the supplier duration, and the necessary collaborations and interactions between the internal team and the external team. Practically, unless the epic is completely outsourced, LPM can focus on forecasts of the internal ARTs affected by the epic, as internal ARTs are expected to coordinate work with external suppliers.

Forecasting an epic’s duration requires an understanding of three data points:

• An epic’s estimated size in story points for each affected ART, which can be estimated using the T-shirt estimation technique for costs by replacing the cost range with a range of points
• The historical velocity of the affected ARTs
• The percent (%) capacity allocation that can be dedicated to working on the epic as negotiated between Product and Solution Management, epic owners, and LPM

In the example shown in Figure 5, a portfolio has a substantial enabler epic that affects three ARTs and LPM seeks to gain an estimate of the forecasted number of PIs. ART 1 has estimated the epic’s size as 2,000 – 2,500 points. Product Management determines that ART 1 can allocate 40% of total capacity toward implementing its part of the epic. With a historical velocity of 1,000 story points per PI, ART 1 forecasts between five to seven PIs for the epic.

After repeating these calculations for each ART, the epic owner can see that while some ARTs will likely be ready to release on demand earlier than others, the forecasted duration to deliver the entire epic across all of the ARTs will likely be between six and eight PIs. If this forecast does not align with business requirements, further negotiations will ensue, such as adjusting capacity allocations or allocating more budget to work delivered by suppliers. Once the epic is initiated, the epic owner will continually update the forecasted completion.

Implementing Epics

The Lean Startup strategy recommends a highly iterative build-measure-learn cycle for product innovation and strategic investments. This strategy for implementing epics provides the economic and strategic advantages of a Lean startup by managing investment and risk incrementally while leveraging the flow and visibility benefits of SAFe (Figure 6). Gathering the data necessary to prove or disprove the Epic Hypothesis is a highly iterative process that continues until a data-driven result is obtained or the team consumes the MVP budget. In general, the result of a proven hypothesis is an MVP suitable for continued investment by the value stream. Continued investment in an Epic that has a dis-proven hypothesis requires the creation of a new epic and approval from the LPM Function.

SAFe Lean Startup Cycle

After it’s approved for implementation, the Epic Owner works with the Agile Teams to begin the development activities needed to realize the epic’s business outcomes hypothesis:

• If the hypothesis is proven true,  the epic enters the persevere state, which  will drive more work by implementing additional features and capabilities. ARTs manage any further investment in the Epic via ongoing WSJF feature prioritization of the Program Backlog . Local features identified by the ART, and those from the epic, compete during routine WSJF reprioritization.
• However, if the hypothesis is proven false, Epic owners can decide to pivot by creating a new epic for LPM review or dropping the initiative altogether and switching to other work in the backlog.

After evaluating an epic’s hypothesis, it may or may not be considered to remain as a portfolio concern. However, the Epic Owner may have some ongoing responsibilities for stewardship and follow-up.

The empowerment and decentralized decision-making of Lean budgets depend on Guardrails for specific checks and balances. Value stream KPIs and other metrics also support guardrails to keep the LPM informed of the epic’s progress toward meeting its business outcomes hypothesis.

Program and Solution Epics

Epics may also originate from local ARTs or Solution Trains, often starting as initiatives that warrant LPM attention because of their significant business impact or initiatives that exceed the epic threshold. These epics warrant a Lean Business Case and review and approval through the Portfolio Kanban system. The Program and Solution Kanban article describes methods for managing the flow of these epics.

Last update: 20 October 2022

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.

Epical epic. Agile epic examples

What is an agile epic, what to use it for, and foremost how?

Requirements. Small, large, technical, business, operational, and researchable. And above all, plenty of them. During four years of ScrumDesk development, we have more than 800 requirements in our backlog. And these are the only requirements that we have decided to implement without any further ideas that would be nice to have. It is, of course, difficult to navigate such a long list without any additional organization of the backlog structure. And this is where Epic comes to help.

Every Scrum or Agile training introduces the term Epic. In training sessions, epics are presented by only using one image, and essentially, they are not even explained assuming their simplicity. It is not rocket science. However, the question emerges as soon as a product owner starts preparing a backlog of the product. How to organize epics? What are they supposed to describe? How to organize them?

Epic is a set of requirements that together deliver greater business value and touch the same portion of the product, either functional or logical.

Agile Epic, similar to the requirement itself (often User story), is supposed to deal with a problem of single or multiple users and at the same time should be usable and valuable.

How to identify epic?

It is no science at all. Start with thinking about a product from a large perspective. Agile epic is a large high-level functionality. Their size is large, usually in hundreds of story points. However, all these chunks of functionalities must be usable end to end. In practice, we have encountered multiple approaches to epic design. Let’s try to see which one is the best for you.

Epics are managed by product management or other strategic roles. For smaller products, Product Owners identify them. Agile epics help structure your work into valuable parts that can be developed faster while delivering value to users.

I. Epic as a part of the product

Epic can represent a large, high-level yet functional unit of the product. For example, in ScrumDesk we have epics BACKLOG, PLAN, WORK, REPORTS. In the app, you can find parts, and modules, which are called the same way as a given epic.

Top epics of the ScrumDesk product

This backlog organization is appropriate when you are creating a product that you are going to be developing in the long run.

Why use this method of epic organization?

• As a product owner, you simply have to be able to orientate yourself in parts of the product and know what you have or have not finished yet.
• At the same time, it is easy to measure progress by parts of the product.
• The Product Owner is naturally urged to change the order of features in the epic , which leads to the creation of rapid delivery of a minimum of viable product increments .

The disadvantage of this method is the lacking view of the user journey It is not visible which parts of the backlog cover what parts of the user value flow. E.g. process from registration, and basket to payment. Each part of the process can belong to a different epic.

Epics, in this case, do not end here, they are not concluded because the functional unit is delivered in the long term. In years. In the roadmap, the implementation of level features of individual epics is planned.

II. Epic as a part of the business flow

This approach is based on the fact, that we know the flow of values, meaning a business process that we can divide into individual parts and then make it more detailed and deliver iteratively. High-level functionalities follow the business workflows.

Epics by the business workflow

For example, an e-shop. Agile epics candidates would be:

• Product catalog viewing – for portraying categories of goods and a list of goods in each category, filtering and searching for goods.
• Product selection – a selection of interesting products such as favorites, comparing, pricing, or adding to a cart.
• The Cart of the products – browsing the content of a basket, comparing, and counting the total price.
• Payment – choice of payment options, total order, total price, shipping, the payment itself, and payment confirmation.
• Product delivery – a visual display of the delivery status, email, and SMS notifications.

The product owner is naturally able to focus on the delivery of the whole customer’s experience .  The first fully functional version is then created quite quickly and is subsequently improved iteratively. Epic Payment is based on VISA, transfer, and cash. In the first version, only Visa payment will be delivered, transfer and cash in the next one.

The development of epics takes a longer time in this case. It does not usually make sense to close them, as they will be further elaborated in the future by other features. Business easily understands the state of the implemented application (e-shop) which simplifies communication and significantly improves cooperation between IT and business. It is important to use commercial terms rather than technological ones.

III. Project as epic

Do you deliver products to a client in various phases and various projects? In this case, it may be easier to create epics according to projects or the project’s phases.

Epics as project or phase

Such epics are usually considered finished (closed) when the project is delivered. The advantage is obvious. There is an absolutely clear state of implementation of the project. Participants and stakeholders have excellent transparency. At the same time, stakeholders can focus on preparing for the next phase of the project.

On the other hand, it can be quite difficult to keep an overview of the functionalities units of the product itself. The state is more perceived by architects rather than the business itself. In real life, we also came across seeing this way to lead to a change in the company’s focus, or even to the degradation of its vision. A company that once wanted to act as a product and solution maker became a company fully listening to clients. Their products became a ‘toy’ in the hands of clients which led to people leaving teams because they have lost the personal connection with the product. They often lose the power to say NO.

It is also practical to use themes for further categorization of requirements . This creates a virtual matrix, in which each requirement belongs to a certain product set and also might belong to a business theme that is communicated to clients. In ScrumDesk we use, for example, themes for identifying clients who had requested larger sets of features, and we, after all, decided to include them in backlogs. As a product owner, I know how to communicate the status of requirements with a client while still keeping my eyes on the implementation of the product itself.

Epics and Themes

Themes in the product world are often determined by top management at strategic meetings and these topics are subsequently implemented in multiple value streams supported by multiple products. An example of such strategic themes can be 3D Maps, AI (Artificial Intelligence) in risky investments, and traveling without physical gates and cards.

Artificial Epics

In addition to business logic, an application has many parts that create a basic core of a product, but a customer rarely notices them.

First of all, you need to think about and register, for example, the design of architecture, suggestion of UX layout of an app, initial frameworks, and technological preparation. In later phases, the functionalities are still touching the entire product at once. E.g. logging, error handling etc. In ScrumDesk we had an epic called #APPLICATION for such requirements.

When we started four years ago, we decided to keep all bugs in epics titled #TECH. Symbol # indicates artificial epic.

Later we changed this strategy and now we are trying to put every requirement, regardless of its type, under the right epic, as the epic either repairs or expands, improves from the technological point of view.

Epic and business value

In Agile, each requirement should deliver additional business value. However, in the case of more complex applications, it is almost impossible to evaluate the value supplied at such a low level. In this case, it is easier to determine the business value at the level of epic . Epic then can analyze, suggest and prepare ahead of implementation itself beforehand.

It is also possible to create a business case and consequently the business value itself. Such an approach is recommended, for example, Scaled Agile Framework, in which the epic adds value to the selected value stream.

Epics in SAFe

How to prepare epics?

Product Owner prepares epics in advance, prior to planning and implementation.

For good preparation he needs support from multiple people:

• an architect for a rough design of the architecture that is needed to implement the epic,
• stakeholders, for whom the functionality will be delivered, for business value determination and business case,
• UX Designer to work out framework principles of interface design and usability of the epic,
• People from service and support for a good design of epic from the operational perspective,
• And whoever else is needed

PREARE EPICS IN SCRUMDESK FOR FREE

Preparation of an epic can, and often has a different process than the requirements themselves. In SAFe ‘Portfolio Kanban’ is recommended for the preparation of epics. Therefore, a separate Kanban board with multiple statuses exists on which the momentum of the epic realization is transparently displayed. This creates space for regular meetings of a small team preparing requirements ahead and continuous improvement of epic details.

Portfolio Kanban systems for epics management

The Product Owner basically works in two-time spaces. In the first one, he prepares epics for the future, and in the second he contributes to the implementation of already developed epics.

How ScrumDesk helps with epics?

ScrumDesk supports epics from its first version. As we use ScrumDesk for the development of the ScrumDesk, we identified and tried different approaches to backlog organization. In the first version epics were just titles, later we added possibilities to:

• add more details in the description of the epic,
• visualize epics as colored cards in user stories map,
• added an option to track the business value, risk, effort (as an aggregation of child requirements),
• break down epics into features and/or user stories to manage complex backlogs,
• track comments and changes,
• attach files (i.e. business cases),
• possibility to add the timeline for epics and features with the support of agile roadmaps displaying not just plans, but comparing them to reality as well.

Common mistakes

• Epic by technology layer. Database, backend, frontend. Functionality is not covered end-to-end, it only supplies parts of it.
• Epic by product version. The product version is a set of properties from different epics. Unlike the epic, the version has a timeline as well.
• Epic by a customer (stakeholder) to which part of the functionality is being delivered. If you need to evidence the customer, evidence it in a separate attribute and organize the epics according to the procedures above.
• When the product assumptions change, the form of epic organization will not readjust. Adapt and select appropriate approaches as needed. Do not be afraid to work with the backlog and change it so you can orient quickly, you can choose other ways of epics organization and especially to have it transparent for the team as well as stakeholders.
• https://www.flickr.com/photos/sebrendel/8155603332
• http://www.scaledagileframework.com/epic/
• http://www.scaledagileframework.com/portfolio-kanban/

Found this interesting? Share, please!

About the author: dusan kocurek.

The SAFe® Epic – an example

We often have questions about what a “good” sufficiently developed SAFe Epic looks like. In this example we use with clients during the Lean Portfolio Management learning journey, we dive into an example of real-world details behind an epic hypothesis statement.

For now, we have not provided a fully developed SAFe Lean Business Case as an example because business cases are typically highly contextual to the business or mission. That being said please remember that the core of the business case is established and driven from the Epic Hypothesis Statement and carried over into the documented business case.

Agile Lifecycle Management Solution Enabler Epic

Epic Owner: John Q. Smith

Epic Description

The big awesome product company requires a common platform for collaboration on work of all types across the portfolio for all teams, managers, architects, directors, and executives including customer collaboration and feedback loops. This solution will solve the problems in our system where we have poor quality or non-existent measurement and multiple disparate systems to manage and report on work.

For the Portfolio Teams

Who needs to manage their work, flow, and feedback

The single-source system of record for all work

IS A web-based software tool suite that provides customizable workflows that support the enterprise strategic themes related to creating better business and IT outcomes using guidance from the Scaled Agile Framework for Lean Enterprises (SAFe), Technology Business Management (TBM), and Value Stream Management (VSM) via the Flow Framework

THAT will provide a common place for all customers and portfolio stakeholders to have a transparent vision into all of the work occurring in the system/portfolio, provide a mechanism to manage capacity at scale, and enable easier concurrent road mapping  

UNLIKE the current array of disparate, ad hoc tools and platforms

OUR SOLUTION will organize all work in a holistic, transparent, visible manner using a common enterprise backlog model combined with an additive enterprise agile scaling framework as guidance including DevOps, Lean+Systems Thinking, and Agile

Business Outcomes:

• Validate that the solution provides easy access to data and/or analytics, and charts for the six flow metrics: distribution, time, velocity, load, efficiency, and predictability for product/solution features (our work). (binary)
• The solution also provides flow metrics for Lean-Agile Teams stories and backlog items. (binary)
• 90% of teams are using the solution to manage 100% of their work and effort within the first year post implementation
• All features and their lead, cycle, and process times (for the continuous delivery pipeline) are transparent. Feature lead and cycle times for all value streams using the system are visible. (binary)
• Lean flow measurements — Lead and cycle times, six SAFe flow metrics, and DevOps metrics enabled in the continuous delivery pipeline integrated across the entire solution platform (binary)
• Activity ratios for workflow, processes, and steps are automatically calculated (binary)
• Percent complete and accurate (%C&A) measures for value streams automatically calculated or easily accessible data (binary)
• Number of documented improvements implemented in the system by teams using data/information sourced from the ALM solution > 25 in the first six months post implementation
• Number of documented improvements implemented in the system by teams using data/information sourced from the ALM solution > 100 in the first year post implementation
• Flow time metrics improve from baseline by 10% in the first year post implementation (lead time for features)
• Portfolio, Solution/Capability, and Program Roadmaps can be generated by Lean Portfolio Management (LPM), Solution Management, and Product Management at will from real-time data in the ALM (binary)
• Roadmaps will be available online for general stakeholder consumption (transparency)
• Increase customer NPS for forecasting and communication of solution progress and transparency of execution by 20% in the first year post implementation (survey + baseline)
• Build a taxonomy for all work including a service catalog (binary)
• Run the system and the system produces the data to produce the capacity metrics for all value streams to enable the LPM guardrail (binary)
• Stops obfuscation of work hidden in the noise of the one sized fits all backlog model (everything is a CRQ/Ticket) and allows for more accurate and representative prioritization including the application of an economic decision-making framework using a taxonomy for work (binary)
• Enables full truth in reporting and transparency of actual flow to everyone, real-time – including customers (100% of work is recorded in the system of record)
• Enables live telemetry of progress towards objectives sourced through all backlogs, roadmaps, and flow data and information (dependent)
• 90% of teams are using the solution to manage 100% of their capacity within the first year post implementation

Leading Indicators:

• Total value stream team member utilization > 95% daily vs. weekly vs. per PI
• Low daily utilization < 75% indicates there is a problem with the solution, training, or something else to explore
• % of teams using the ALM solution to manage 100% of their work and effort
• Number of changes in the [old solutions] data from the implementation start date
• Usage metrics for the [old solutions]
• We can see kanban systems and working agreements for workflow state entry and exit criteria in use in the system records
• Teams have a velocity metric that they use solely for the use of planning an iterations available capacity and not for measuring team performance (only useful for planning efficiency performance)
• Teams use velocity and flow metrics to make improvements to their system and flow (# of improvements acted from solution usage)
• Teams are able to measure the flow of items per cycle (sprint/iteration) and per effort/value (story points; additive)
• Program(s)[ARTs] are able to measure the flow of features per cycle (PI) and per effort/value (story points; additive from child elements)
• Portfolio(s) are able to measure the flow of epics per cycle (PI) and per effort/value (story points; additive from child elements)
• % of total work activity and effort in the portfolio visible in the solution
• Show the six flow metrics
• Features (Program) – current PI and two PI’s into the future
• Epics and Capabilities – current PI up to two+ years into the future
• are the things we said we were going to work on and what we actually worked on in relation to objectives and priorities (not just raw outputs of flow) the same?
• The portfolio has a reasonable and rationalized, quality understanding of how much capacity exists across current and future cycles (PI) in alignment with the roadmap
• Identification and reporting of capacity across Portfolio is accurate and predictable;
• Identification of Operational/Maintenance-to-Enhancement work ratio and work activity ratios and % complete and accurate (%C&A) data readily available in the system
• including operations and maintenance (O&M) work and enhancements,
• highlighting categories/types of work
• Work activity ratios are in alignment with process strategy and forecasts, process intent, and incentivizing business outcomes;
• allows leadership to address systemic issues;
• data is not just reported, but means something and is acted upon through decision-making and/or improvements
• # of epics created over time
• # of epics accepted over time
• # of MVP’s tested and successful
• Parameters configured in the tool to highlight and constrain anti-patterns
• Stimulates feedback loop to assist in making decisions on whether to refine/improve/refactor and in that case, what to refine/improve/refactor
• Strategic themes, objectives, key results, and the work in the portfolio – Epics, Capabilities, Features, Stories traceability conveyed from Enterprise to ART/Team level

Non-Functional Requirements

• On-Premise components of the ALM solution shall support 2-Factor Authentication
• SaaS components of the ALM solution shall support 2-Factor Authentication and SAML 2.0
• The system must be 508 compliant
• The system must be scalable to support up to 2000 users simultaneously with no performance degradation or reliability issues
• Must be the single-source system for all work performed in the portfolio and value streams.
• ALM is the single-source system of record for viewing and reporting roadmap status/progress toward objectives

Building your Experiment – The Minimum Viable Product (MVP)

Once you have constructed a quality hypothesis statement the product management team should begin work on building the lean business case and MVP concept. How are you going to test the hypothesis? How can we test the hypothesis adequately while also economically wrt to time, cost, and quality? What are the key features that will demonstrably support the hypothesis?

• Name First Last

Developing a Winning Epic Hypothesis Statement that Captivates Stakeholders using SAFe

The Scaled Agile Framework®, or SAFe, was created in 2011 and built upon the classic Agile manifesto by incorporating key ideas from the Lean methodology.

Organisations using this framework can accomplish a wide range of advantages, according to SAFe developers, such as:

20-50% increases in productivity

30-75% quicker time to market

10-50%Increases in employee engagement

Assume that in order to reap the benefits of project management, your Executive Action Team (EAT) wants to embrace a Lean-Agile mentality. If so, it needs to become proficient in crafting and presenting an Epic Hypothesis Statement (EHS). Check out the Agile certification course to learn more.

Creating a strong EHS and persuading your stakeholders to embrace your bold idea are crucial to attaining business agility and optimising development procedures. On the other hand, neglecting to do so will impede your pipeline for continuous delivery and hinder you from effectively creating functional software.

It’s imperative that you nail your EHS pitch because there is a lot riding on it. We’ve developed this useful tool to assist you pitch your Epic Hypothesis Statement to your EAT in order to support these efforts.

What Is an Executive Action Team (EAT)?

One of the cross-functional teams in the SAFe framework is the Executive Action Team (EAT). This group drives organisational transformation and eliminates barriers to systemic advancement. Additionally, the EAT will hear your EHS and choose whether or not to add it to the Epic queue.

The idea that change must originate at the top is one of the fundamental tenets of the lean-agile approach. An effective EHS pitch will pique the interest of Executive Action Team stakeholders and persuade them to adopt your Epic Hypothesis Statement.

What Is an Epic Hypothesis Statement (EHS)?

A comprehensive hypothesis that outlines an epic or sizable undertaking intended to overcome a growth impediment or seize a growth opportunity is called the Epic Hypothesis Statement (EHS).

Epics are typically customer-facing and always have a large scale. They need to assist a business in meeting its present requirements and equip it to face obstacles down the road.

The Epic Hypothesis Statement (EHS) is typically delivered to the EAT in the style of an elevator pitch: it is brief, simple, and concise, although the statement itself will be highly thorough.

Key Components of an Epic Hypothesis Statement

The Portfolio Kanban system’s initial funnelling phase is expanded upon in the Epic Hypothesis Statement. The concept started out as just one, like “adding self-service tools to the customer’s loan management portal.”

You must refine this fundamental concept into a fully realised endeavour in your role as the Epic Owner. In the event that your theory is verified, you must also describe the anticipated advantages the firm will enjoy. Your EHS also has to have leading indications that you can track as you move toward validating your hypotheses.

Let’s expand on the example of the self-service tool.

You could expand on the basic premise of integrating self-service capabilities into the loan management portal that is visible to customers if you wanted to develop an EHS. Indicate which specific tools you want to use and how they will enhance the client journey in your explanation of the initiative.

For example, the following could be considered expected benefit outcomes of this initiative:

• A reduction in calls to customer service
• Better customer satisfaction and engagement
• improved image of the brand

It’s true that some advantages would be hard to measure. Complementary objectives and key results (OKRs) are therefore quite important to include in your EHS since they will support your pitch to your EAT regarding the benefits of your EHS.

Pitching Your EHS

It’s time to submit your finished Epic Hypothesis Statement to the EAT for consideration. You need to do the following if you want to involve your stakeholders.

Make Use of Powerful Visuals

The Agile manifesto and the Portfolio Kanban system both stress the value of visualisation. Including images in your EHS pitch demonstrates to your audience that you understand these approaches in their entirety and aids with their understanding of your concept.

Explain the Applicability of Your OKRs

Your suggested endeavour and the OKRs you’ve chosen should be clearly connected. Nevertheless, it never hurts to emphasise this point by outlining how each OKR you select will assist in monitoring the advancement of your theory’s proof.

Close the Deal with a Powerful Concluding Statement

Your Epic Hypothesis Statement is ultimately a sales pitch. Handle it as such by providing a succinct yet captivating conclusion. Go over the possible advantages of your project again, and explain why you think it will help the business achieve its short- and long-term objectives.

The Perfect EHS Pitch Starts with a Great Idea

By utilising the aforementioned strategies and recommendations, you can create an extensive EHS that grabs the interest of your stakeholders. But never forget that the quality of your idea will determine how well your pitch goes.

Work with your EAT to integrate ideas that have a significant impact into your workflow for managing your portfolio. Next, choose a notion you are enthusiastic about and develop your hypothesis around it. You’ll have no trouble crafting the ideal EHS pitch.

Conclusion  To learn more about Agile and SAFe, check out the SAFe Agile certification course online.

What is Interruption Testing?

Approaches for being a lead business analyst, leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Related Articles

Agile Project Management

Best Ways To Apply Regression Testing In Agile Environment 

Kanban Vs. Scrum: Get to know the Difference

Roles and Responsibilities of a Scrum Master

• The Compass Decide your level of Agility
• The Journey An incremental approach to Transformation
• The Roadmap A change model for success
• Field Notes A resource library for all things Agile
• Notifications

Epics and Outcomes

When teams are first moving away from, “Epic is a container for a list of features,” and towards, “Epic is a discrete investment decision,” It can be hard to reorient. In their old world, the epic had some sort of field – “list the features contained in this epic” which was straightforward to fill out. The decisions they made were really easy: “Is anything we planned to build missing? Add it.”

When your mental model is, “We need to predictably deliver all these things someone else thought was important,” managing the flow of epics is pretty easy. Creating a ‘roadmap’ is easy too (hint: it is not a roadmap, it is a release plan, with the features grouped together conveniently for making a pretty presentation).

And this is why it is hard for teams to reframe. We are asking them to stop doing the easy thing and start doing the important thing. Set aside, for the moment, the challenges of creating the conditions in the organization where this team (the portfolio team) is allowed to do important work – this is what we do at LeadingAgile, removing all of the barriers – I want to focus on the shift in thinking that has to happen. We put the structures in place which allow the practices to flourish that embody these changes.  

How we structure the epic is as important as how we structure the teams and how we structure the flow of work. All of it is needed.

The epic contains two key fields – the desired outcome and the success criteria. The names of these fields could be different – they could be “lagging indicator” (relative to the lifecycle of the epic) and “leading indicator.” You could also call them “benefit” and “KPI.”

The elements of the epic need to support the decisions we make within and about the epic. I think of the first set of questions together – “Should we do this?” “When should we do this?” “What cost should we be willing to incur in order to do this?” The primary element of the epic needed to answer these questions is the desired outcome field. This field is where the team articulates the benefit which justifies the investment and decisions about when to invest. This information is a focal point for collaboration within the portfolio team (and occasionally across portfolio teams).

This benefit-realization expectation is also the critical element to assuring coherence between the scope of work we are about to undertake, and the level of ambition embodied in the strategic plan. All necessary cross-team collaboration to assure the capacity of the teams is allocated to effectively execute the strategy. I often talk about this as “collaborating up.”

The second set of decisions we need to make – and this is where the conceptual shift is hardest – are captured with “What do we need to build to achieve this outcome?” This is a key difference between business Agility and just another feature factory faux-Agile farce. We are asking the portfolio team to be responsible (in collaboration with the product teams) for making the right choices about what things should be built to achieve the desired outcomes – taking into account organizational capacity (balancing capacity with demand) and dependencies and impediments; broadly assuring feasibility of the approach.  

To support these decisions, a desired outcome is operationally too abstract. We need a causal linkage between what we choose to do and why we choose to do it. Half of this causal linkage is embodied in an outcome hypothesis.

We believe if we cause these (observable, measurable) behavior changes (or KPI changes) in the system, it will result in realizing the desired outcome (benefit) we intend. We will know we are right if we see (measurable criteria) and we will know we are wrong if we see (measurable criteria).

The mindset shifts to embrace uncertainty and think of the approach to executing each epic as “placing a bet” is again, literally, what it means to embody business agility. We are starting with the assumption we may be wrong – which makes it possible to learn you may have been wrong. If you are already certain about what needs to be built, you will never give yourself the opportunity to discover how you are wrong.  

The other half of this causal linkage is captured in a solution hypothesis.

We believe if we build these (features), they will solve these problems resulting in these (observable, measurable) behavior changes. We will know we are right if we see (measurable criteria) and will know we are wrong if we see (measurable criteria).

The solution approach – which features – is  referenced from  the epic but is not  included within the epic. This is a conceptually different place. The epic is where we center the outcome hypothesis;  the solution design work – typically across multiple features – is where we embody the solution hypothesis.

For the epic to contain both halves of the outcome hypothesis (the change we are trying to create, and how we expect to benefit if we create it) – we need two fields. The success criteria field is where we capture the intended changes to the system. We separate the fields because we are introducing new behaviors and new frames of reasoning and decision making. The product team(s) who are responsible for developing the solution approaches need an anchor – the success criteria. We only ask them to abstractly shift their thinking into one hypothesis – the solution hypothesis – and to partner with the portfolio team who anchors on the outcome-hypothesis.

Through a quantified success criterion, an epic provides the structure to enable the product teams to explore options for how best to solve the problems which (we believe) we need to solve to achieve the measurable change in behavior.  The portfolio team collaborates with the product team to come up with solution approaches that are both right alone AND right together. I refer to this as “collaborating down” when working with portfolio teams, and “collaborating up” when working with product teams.

This is a radically different set of expectations for the members of the portfolio team – to elicit, define, align upon the intended outcomes; assure their coherence with strategic intent; provide clarity of purpose to the product and delivery teams. It was much easier when they only had to ask, “do you want fries with that” and pass the order on back to the kitchen staff.

Comment (1)

What are some examples in showing the difference between an Epic being a, “container for a list of features,” and a “discrete investment decision?”

Great stuff here! For capability and readability, please add headings. 🙏

Leave a comment

Your email address will not be published. Required fields are marked *

We use cookies to improve your experience on our site and to show you relevant ads.

Never Miss A Post

• Integrations
• Learning Center

How to Write an Epic (for Product Managers)

What is an epic.

An epic in product management is a group of related development tasks between high-level strategic themes and actionable user stories.

You can think of an epic in two ways:

1.) The top-down view:

An epic is a body of work that a product team devises as they break down a strategic theme into smaller initiatives. A theme on your product roadmap might contain two or more epics.

2.) The bottom-up view:

An epic is a body of work representing a group of user stories sharing a common strategic goal. Several related stories on the roadmap will often roll up to a single epic.

What is an Example of an Epic in Product Management?

Look at the graphic at the top of this page. It represents a section of a hypothetical software company’s product roadmap. Let’s review the details to see how the epics fit into the team’s strategy, which flows from one central theme.

THEME: Increase the number of people using our free trial

To achieve this goal, the product team has identified two epics. We’ll examine just the first one and the user stories that flow from it.

EPIC: Simplify the trial download process

As you can see, this epic represents a subset of the theme to bring in more trial users. But the work required here, to simplify the trial download process, is more than a development team can complete in a single sprint.

For this reason, the team must further break down this epic into user stories that the developers can complete in one sprint.

USER STORY #1: Shorten the signup form

The product team believes trial usage has been low because the current signup form contains too many questions. It turns off visitors.

Following this user story, the team will cut out all but the necessary lead-collection questions. The form might ask only for the user’s full name and email address.

USER STORY #2: Move the signup form from our site into the app itself.

The product team has identified another challenge in their trial process. When users click the “TRY IT FREE” button, they encounter the signup form right away. They have not yet invested time in starting the download process, so they are more likely to abandon the form.

The team would like to let users make progress accessing the trial version before filling out the form. They can download the app, install it on their computer, and see the product interface on their screen. Then, before they can perform any action with the product, they’ll need to complete the form.

This way, users have already invested time and effort in starting the trial. They can also see that they can start using the app immediately after they’ve finished the form.

Bottom line: A product team develops an epic by breaking down a high-level product theme into more manageable components. Then, they will need to break down each epic into actionable tasks, the user stories.

How to Write an Epic?

There are many ways you can write an epic. But most approaches have a few steps every day. Let’s walk through them.

Step 1: Name the epic.

Before you can start planning the details of the epic, you need to give it a clear, concise title.

On the hypothetical roadmap above, the product team identified two strategic actions to help achieve their theme of increasing trial downloads. For one of those strategies, they named the epic “Simplify download process.”

You want to start your epic writing process with the name because it helps clarify your strategic goals. You will also find it helpful to have a standard way of describing the strategy. It will reduce confusion and miscommunication among your team .

Step 2: Write a narrative explaining the epic.

Next, you will write a short description of what you hope to achieve with the epic. This narrative should contain at least the following:

1. Who: the persona (in this case, the product manager )

2. What: your objective

3. Why: the value behind the objective

Here is a template you can use to fill in the details:

As the [product manager] , I want to [simplify the trial download experience] so that [we increase the number of people who complete the trial download process] .

Pro tip: You can also include another sentence or two with background information that helps explain why this epic matters.

For example, in our hypothetical, you might include a note about your research, which includes:

• Current abandon rates on your trial download web page
• Data indicating these abandon rates are higher than the industry average
• Data showing that your signup form contains more fields than the industry average

Step 3: Establish the scope for the epic.

You will now want to jot down the scope of work for this epic—in other words, the boundaries. The range of work will help your team to stay on track.

Going back to our hypothetical, “Simplify the download process,” you might want to specify:

• Which trial downloads to focus on
• Which form fields to eliminate (and which to keep)
• Where you wish to relocate the form

Step 4: Define completion for the epic.

As a product manager, your team will need to know when to define completion for the epic. You will also need to write a clear set of acceptance criteria—the high-level list of requirements your team will need to approve. With our hypothetical, this acceptance criteria would include:

• The development team can confirm that we can track the abandon rate in the app, where we’ve moved the form.

Step 5: Break the epic down into stories.

At this point, you’ve technically completed and understand how to write an epic in product management. The epic writing phase is complete. You are now ready for the next stage: writing the user stories. But we include this as step 5 to show you how epic creation should flow naturally into writing actionable tasks that your developers can add to their next sprint.

How to Write a Product One-Pager People Will Actually Read

When asking yourself how you can write a product one-pager that people will actually read, it’s important to note its...

The Biggest Mistake When Rolling Out a New Roadmapping Tool — and How to Avoid it

One of the product roadmap’s primary goals is to bring a company’s teams and departments together around a shared strategy...

How Zoom’s Product Strategy Evolved to Keep Pace with an Unprecedented Surge

An analysis of how Zoom's product strategy scaled to meet connectivity demands with an unexpected, unprecedented influx of users during...

Continue exploring

You can search or explore specific categories.

Prioritization and Backlog

Company news and updates, templates and workbooks, remote product management, product metrics and analytics, product strategy example, product managers, tools and resources, customer-centricity, product leadership, product management, roadmap and roadmap management, product strategy, agile & product development, career and interviews, try productplan free for 14 days, share on mastodon.

Filter by Keywords

The Art of Agile Epics: Creating, Tracking, and Measuring Success

February 13, 2024

Managing agile epics is like juggling bowling pins. Take your eyes off them, and you’ll mess up the entire act. But with enough practice and a robust toolset, project managers can easily master the art of completing epics in the shortest agile iterations. 🤹

If you’re already on the journey of doing so, fret not—we’re here to decode the secret key to harmonizing your agile epics with efficient project management! 

This article provides comprehensive insights into the nature of agile epics, their place within the broader agile methodology, and their relationship with user stories and tasks. We’ll also list different approaches and their benefits alongside real-life agile epic examples to illustrate their practical application.

Let’s delve into the framework behind agile epics!

What Is an Agile Epic?

The role of agile epics in project management, customer-focused results, flexibility, improved time management, practical example of agile epics, step 1: define the user persona for the epic, step 2: set your goals and define epics, step 3: break down epics into user stories, step 4: define timeframes and track each epic, step 5: integrate customer feedback loops, best practices for mastering agile epics.

An agile epic is a collection of smaller and mutually connected tasks, also known as user stories , formatted as requirements that fulfill the end-user’s needs. These collections help development teams create a hierarchy of pending tasks and consistently deliver quality to their customers.

In most cases, agile epics are not composed of low-end tasks you can complete in one iteration. Think of epics as branches of a tree, with each leaf representing a user story—they’ll fall off one by one instead of all at the same time. 🍂

Still, you must maintain consistency throughout all epics—that’s where agile themes come along. Themes are the trunk of your agile tree and represent general directions of the development process without getting into too much detail. They help agile teams prioritize work and ensure it aligns with the larger project objectives. 

With epics, you can detail the initial setting of the theme and turn a goal into a string of tasks. 

Agile epics are essential in detailing the general project objective and paving the road toward accomplishing client requirements. With a clear grasp of a theme’s context, teams lower the risk of being overwhelmed and steering away from their goal. 

With that in mind, here’s how agile epics help ensure smooth project delivery: 

• Providing a holistic view: Epics break down the initial general requirements and allow you to create specific user stories based on them. They provide a strategic roadmap for product development and guide the prioritization of work
• Simplifying resource allocation: Understanding the scope and size of epics helps project managers make informed decisions when allocating resources and ensure all tasks are completed within deadlines  
• Backlog management: Epics are crucial in prioritizing work and managing the product backlog. Project managers, together with product owners and developers, prioritize epics based on factors such as urgency and customer needs
• Promoting collaboration: Cross-functional teams with different tasks may be part of the same epic, promoting cooperation and strengthening the internal dynamics. Further breaking down epics into smaller stories ensures dependencies are managed effectively
• Monitoring progress: Epics provide a framework for monitoring progress and tracking milestones. Project managers use epics to assess the trajectory of the project, identify risks and issues, and make adjustments as needed

Maintaining the set hierarchy can become challenging as your agile epics grow in number and size. If that happens, you can leverage project management templates —they provide pre-built frameworks and ensure consistency across the entire Scrum team. 

Benefits of Using Agile Epics

One of the most notable benefits of agile epics is the refinement of Scrum project management . Epics provide a framework for managing project scope by breaking down large and complex requirements into smaller, more manageable components. This enables teams to prioritize work effectively and ensures that development efforts are focused on delivering value. 

That’s only one of the reasons you should implement them in your processes. Let’s explore a few more! ⚙️

By breaking epics down into user stories, agile project management not only establishes clear dependencies but ensures that an epic addresses all the specific customer needs. 

This helps your company prioritize customer feedback and make changes that align with current business goals, justifying the stakeholders’ resources. Once you establish a picture of what the end-user of your product truly needs, all teams will be able to address these needs effectively. 

As your customer base evolves, so do market dynamics and, with them, general project requirements. This is where the agile framework makes a difference— epics promote flexibility and adaptability. 

By strategically portioning the workload, you allow the developers and the entire Scrum or agile team to go back to a specific user story of any epic and adjust , refine , reprioritize , or even completely discard it. 

Epics are time-boxed and naturally have start and end dates. This means you can: 

• Manage them in multiple sprints instead of overwhelming developers
• Make clear estimates on when you’ll complete an epic 
• Review the previous sprints to create more accurate predictions for future epics 

While this may be a time-consuming process at first, once you become habitual in tracking all epics simultaneously, you’ll be able to optimize your current processes and make more accurate estimations. 

While the term epics originated in the settings of agile software development, it’s easily applicable to any process that can be broken down into more manageable pieces. To explain the term further, let’s draw an analogy and see a real-life agile epic example. ⏸️ 

Example: Constructing an enclosed garden

Imagine you’re constructing an enclosed garden—a tranquil oasis where people can relax and reconnect with nature. Let’s break down this project using agile principles.

In the context of our garden, epics represent broad categories of work that align with the project’s objectives. Here are some potential epics:

• Landscaping: Designing the layout, selecting plants, and creating pathways
• Infrastructure: Building a fence, installing a gate, and setting up an irrigation system
• Comforts: Adding benches, installing lighting, and incorporating decorative features

User stories represent specific features or functionalities of the garden from the perspective of the end-user. They help break down epics into actionable tasks. If we take the infrastructure epic as an example, one user story could be:

As a gardener, I want a sturdy fence to protect the garden from wildlife and maintain privacy.

Each user story point comprises various tasks with a defined timeframe for completion. For instance, to complete the user story above, we’ll finish tasks like purchasing materials for building the fence and gate, installing irrigation pipes, and testing the system for efficiency.

How to Create and Track Agile Epics

To create epics properly, ensure each aligns with current business goals or objectives and key results (OKRs). Brainstorming, writing, and tracking epics may be an elaborate process, but with the right tool, you can master it in no time. 🛠️

To do so, use a holistic project management software like ClickUp ! The ClickUp Agile Suite helps you expedite creating epics with industry-specific AI prompts, track each epic with burndown charts and SMART goals, and collaborate with your entire agile team simultaneously! 

Before jumping into the epics, delineate the project’s target customer. Ask yourself: 

• Whose perspective will the user stories address? 
• What does the target audience truly care about? 
• How can the product enhance their experience? 

The answers to these questions will set the base for writing user stories that satisfy customer requirements. Whether attracting new leads or improving the current experience, ensure that you target the customer’s pain points and create relevant user stories that will guide the development team.

To get a head start on the process, use ClickUp’s User Persona Template . Product owners can easily create different personas depending on gender, age, and interests using Custom Fields. Multiple views also help you group these personas to get a larger picture and visualize how each interacts with the product by identifying common behavior patterns. 

To make company-specific adjustments to the defined user persona, use ClickUp Whiteboards . These virtual canvases allow you to connect ideas and collaborate with the Scrum team to recognize different behavior patterns in real time.

Once you’ve established the project requirements, it’s time to set clear goals across different epics. Epics should be broad enough to encapsulate significant areas of work but specific enough to provide actionable guidance to the team. 

To easily establish each agile epic, try your hand at ClickUp Goals . Create to-the-point targets and assign them to the person in charge. As the development gains traction, you can visualize the progress at a glance with percentage tracking—you’ll instantly know how close you are to reaching the goal. 🎯

Use ClickUp’s Chat View to discuss your goals and any changes you want your agile members to make behind the scenes. Create meeting groups and give members access or assign comments to quickly delegate tasks. 

For total clarity on the objectives, ensure each epic is SMART :

• M easurable
• A chievable
• T ime-bound

This approach removes ambiguity and ensures every team member understands the predefined expectations. The ClickUp’s Weekly Scorecard Template facilitates the setup of clear, shared weekly goals that directly contribute to primary objectives. 

Once epics are defined and prioritized, break them into smaller, more detailed user stories and actionable tasks. Epics with more detailed user stories that require multiple sprints can be visually structured using a Gantt chart for enhanced clarity.

With ClickUp’s Gantt Charts , you can use different colors to reflect all your user stories and tasks or sort all tasks depending on their:

Get an instant update on any task’s progress by hovering your cursor over it to receive a visual percentage of the completion rate. Add dependencies to automatically reschedule tasks and use smart dependency-path tracking to identify user stories that can potentially move at a slower pace than intended. This, in turn, boosts your team’s project management capabilities.

If you don’t like assembling user stories the old-fashioned way, you can instantly create them using ClickUp’s AI and leverage 100+ industry-specific prompts. Simply instruct the tool to create user stories based on your provided data and adjust the result if needed.

Centralize all user stories and share them with relevant stakeholders while live co-editing with peers using ClickUp Docs —the project manager may need extra assistance from other agile members!

Strive for a balanced time limit for your agile epics—not excessively lengthy or overly brief. Typically, aim for dedicating 1–4 months per epic, accommodating multiple sprints.

Give your agile epics a clear timeline and resource management boost with ClickUp’s Time Estimates . When assigning a task, simply click on the estimate time option to give your agile development teams a timeframe to lean on. Once you provide reasonable estimates, you can plan how long it will take to complete one user story.

This also enables you to give stakeholders a better estimate of when they can expect a new feature addition or improvement.

Pro tip: Give your team a hand when meeting deadlines by introducing them to ClickUp’s Project Time Tracking feature! This way, you’ll gather valuable information about processes that hold back your project.

An easy way to refine your estimates is by employing ClickUp’s Sprint Burndown Chart Template . Use the template to instantly locate: 

• Completed individual tasks of user stories 
• Tasks that are in progress 
• Tasks that have been pending for too long 

An effective burn chart tracks actual versus estimated work over time, with the x-axis representing time and the y-axis reflecting stories or setbacks your team encounters.

Alongside burn charts, Kanban boards offer a visual representation of ongoing tasks and stages. They enable multiple teams to monitor the advancement of epics and user stories, find gaps, and regulate work-in-progress thresholds. 

ClickUp’s Kanban Boards are the perfect tool for that—you can seamlessly browse user story tasks based on dates , assignees , status , priority , and due dates . Feel like something’s misplaced? Quickly move around board cards with an intuitive drag-and-drop feature. 🖱️

At different stages of a single epic, actively seek client input and incorporate their suggestions into the project. Modifications help refine the user stories to better align with user needs and client expectations. 

You can incorporate agile process improvement methodologies and record client feedback. Start by using ClickUp’s Form view to create customizable forms—you can convert any response into a trackable task to have your team work on it immediately and avoid backlogging. Besides that, you can: 

• Add mandatory or optional questions
• Change the priority of any response
• Set trigger-activated rules to automate the processes

To get a comprehensive view of each converted feedback, give ClickUp’s Table view a try and edit 15+ Custom Field types that let you keep all data organized.

Mastering agile epics requires a combination of strategic thinking, effective communication, and adaptability. Here are some best practices to help your agile teams excel in managing them: 

• Provide sufficient context: Ensure your team clearly understands the user stories behind their tasks and the bigger picture of the theme. This will help them create solutions in line with the broader objectives
• Ensure team engagement: Actively collaborate with stakeholders, product owners, and team members during the definition and refinement of epics. This ensures you consider diverse perspectives 👫
• Adjust time and effort estimates: Review initial estimations and compare them with the time and effort needed to complete an epic. Once you refine your processes, you’ll be able to prioritize with more accuracy
• Manage dependencies effectively: Identify and manage dependencies between epics and other project elements. This will help you prevent bottlenecks and delays. To ensure smooth collaboration, regularly communicate with relevant teams
• Iterate and adapt: Regularly review and reflect on the progress of epics, receive feedback from stakeholders, and adjust your approach based on lessons learned

Dominate Your Agile Epics with ClickUp

Now that you know all about creating agile epics effectively, you can prioritize work, manage dependencies, and deliver value throughout the project lifecycle.

Luckily, you don’t have to develop these processes manually—ClickUp has got your back. Leverage the platform’s agile project management tools like AI, Custom Fields, Whiteboards, Dashboards, and feedback forms to create, measure, and track your agile epics seamlessly. 

Sign up for ClickUp and let your team focus on what really matters—successful project development. 🥇

Questions? Comments? Visit our Help Center for support.

Receive the latest WriteClick Newsletter updates.

Thanks for subscribing to our blog!

Please enter a valid email

• Free training & 24-hour support
• Serious about security & privacy
• 99.99% uptime the last 12 months

Tyner Blain

Software product success.

Epic Problem Statement

When solving complex problems at scale, we use epics, features, and stories to align, focus, and coordinate the work of multiple teams to achieve the objectives of our organizations. 

An epic represents the investment decision to solve a tangible problem; a collection of epics together represent a broader investment decision to advance the organization’s strategy.  Most of the teams I’ve worked with in the past few years initially think about their epics in the wrong way – and once we change together how they write problem statements, it unlocks their potential to achieve great things on their own.

The Job of An Epic

A well-constructed epic achieves two objectives

• An epic aligns your teams on intent – why are we making this investment and how will we know we are done?
• An epic communicates the context of general approach – at a high level, what will we create and improve to make achieving our goals possible?

A group of epics collectively represents the purpose of a body of work the teams will perform in a period of time. Our executives validate the body of work as matching the ambition of their initiative.  Together with them, we create the epic roadmap to align and allocate the organization’s capacity to the pursuit of our strategy.  This coherence check is the first important alignment activity required to assure the organization is effectively executing on the vision of the organization.

For you to agree with my assertion about the job of the epic, you need to know the jobs of the feature and the story – to assure yourself this approach collectively gets all of the jobs of the system done.

A well constructed feature describes our approach to creating or improving a capability which we believe is necessary to realize the intended outcomes of an epic.  Any given epic will be achieved through the development of multiple features.  Each feature provides sufficient specificity to enable the organization to understand and orchestrate dependencies across the teams doing the work – and likewise provides enough information for the team to know how “good enough” will be judged – a definition of done.

An effective user story describes the user’s goal, when & why they have the goal, and how they judge their success at achieving their goal.  A collection of user stories aligned to a given feature reflect the necessary adaptation of those user goals, given the constraints of what we build to enable them to realize their goals; given the features we might choose to build and the way we would choose to build them.

The Job of the Problem Statement

In any organization, an artifact exists to support activities – creation, collaboration, coordination, and communication .  [Hat tip to Laura and Kate for the inspiration (in a discussion on the purposes of designers’ deliverables )]  An epic is no different – and we use it for each of the 4 C’s, at different times, with different people, for different purposes.  In support of those activities, we rely on the epic as a container of “intention.” A good epic organizes the description of intent such that it enables teams to support conversations around three key questions:

• What is the problem we are solving for the company with this epic?
• What is the value of this epic, assuming we solve the problem we intend to solve?
• What changes in behavior will we observe in the short term which assure us we are solving the problem we intend to solve?

The problem statement has responsibility for the first of those three – aligning with our executive sponsor on the problem to be solved.  

The problem statement is primarily a creation tool – for a product manager, properly framing the problem which truly needs to be solved is the vanguard of thinking steps in providing clarity in the backlog.  Understanding what truly needs to be accomplished is an experience of epiphany and insight; a moment of clarity.

The problem statement is secondarily  a communication tool – an elevator pitch for the epic.  Our leaders rely on us to deeply understand the context in which we make choices which make plans real .  Through the problem statement we can collaborate to achieve a shared understanding of how the teams will realize the vision.

A well written problem statement provides clarity on why an epic is valuable to the organization.  Primarily, we use this to assure completeness and correctness between a collection of epics and the initiative.  When we are misaligned, we leverage the problem statement in collaboration with our executive to achieve both alignment with and comprehensive coverage of the opportunities we are pursuing.  This alignment is a key element of strategy deployment – making sure nothing is missed , and none of the work is likely to be misaligned .  

An Effective Structure for the Problem Statement

On more than one occasion I’ve heard an effective product or business leader refer to structured artifacts as “mad libs” (and not in a good way ).  A mad lib, while fun to read, is not actually coherent or useful – arbitrary terms inserted into fields creates nonsense.  Forcing people to restructure nonsense thinking into a good format initially results in well-organized nonsense.  All is not lost, however, as this is also the first step on a journey of improvement.

We gradually adapt to the structures around us.  Forcing teams to use a fixed structure for writing problem statements is an effective way to make progress addressing the system-level problem of developing the organizational capability of collaborative problem solving.  

In the Shu Ha Ri approach to change , adoption of the structure is achieving shu-level performance.  When our problem statement includes the right elements, it improves.  Upon that improvement we can begin the journey of improving the inputs to the structure – making better choices about what problems to solve.

A Good Problem Statement has Four Elements

• A definition of the problem we intend to solve   –  this is the “why” of our product or enhancement.
• Identification of the users who are affected by the problem – this is the “who” of our product.
• Identification of the consequences of leaving the problem unsolved – this is the “pain” we are addressing with our product.
• An Imagining of a future where the problem is solved – this is an envisioning which provides multiple benefits in both completeness and correctness.

These four elements are important because we need our executives to align around concrete purpose – achieving a shared understanding of the problem, why it is important to solve, and what good enough looks like.  When teams do work which does not advance the solution of the identified problem, that work is waste.  When teams do more work than is needed to solve the problem, that work is also waste.  A well structured problem statement helps prevent both irrelevant features and gold plating.

When we activate our teams to “build the things” we are introducing waste because those things are always misaligned to the problems we need to solve.  It is critical, we instead align our teams around solving the problems.  The appropriate things to build will be discovered when it is appropriate.  And the things we choose to build can be easily changed when we realize different things are required.  All without changing direction – we are still focused on solving the problem.

• When we organize around the problems we choose to solve, instead of the solution ideas, we more effectively activate our teams, eliminate waste, and deliver predictably.
• Epics represent investment decisions to realize value (to ‘solve the problems which prevent realization of value’).
• Problem statements help us in choosing the right problems, and help us in aligning our problem choices with our strategic intent.

In future articles, I hope to write about applying techniques (like using “How Might We?…”) to improve the problems we choose to solve.  For now, we can all realize the systemic benefits which arise from using this approach to describe the problems we have chosen.

Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

2 thoughts on “ Epic Problem Statement ”

Hi Scott, Thanks for exploring the use of problem statements to build a shared understanding of the problem you’re trying to solve.

I also find that templates can be a double edged sword. Bad if they are thoughtlessly filled in, very helpful if they are used to guide conversations.

I’ve written up the technique I like to use to guide a conversation around the four bits of a problem statement here: https://www.kbp.media/problem-statement/ and linked to this post in the additional references.

Excellent, Kent. Love your stuff as always!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Notify me of new posts by email.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

How to Write Epics and User Stories

Basic principles & guidelines with an example for product managers/product owners for writing an epic and user stories.

Bindiya Thakkar

Product Coalition

Writing a good epic and user story is the most basic and the most important task at hand when you enter the role of Product Management. Hence I am going to get right to it and give you some real tips and examples of how to write epics and user stories — best case scenarios.

I understand and agree that not everything is applicable in every situation as exceptions are also part of our job. But consider this a basic guide to writing a good epic and user story.

Before proceeding to the details on how to write Epics and User Stories if you want to get a basic understanding on what is an Epic and user story ? Please read this article What is an Epic & User Story? How to name your Epic and User stories?

A well-written epic is a key to have a good understanding and material to refer in case of any doubts during development. It helps in avoiding a lot of conflicts and misunderstanding in the team. Since this is what you will refer when writing the user story and all the other team member when working on the user stories it's extremely important to collaborate and put some details in your Epic. As a product manager/owner while creating an epic include the following four things as the very basic structure.

Introduction

• Product requirement
• Technical requirement
• Design requirement

As a product manager, you are responsible for creating the epic and maintaining the epic specs sheet but from my experience, you should not try to do it all by yourself. Your major responsibility is to write the introduction and the product requirement but get as much help as you can from your engineering team, tech architect or teach lead while writing the technical requirement. Involve the UX designer or UX lead while writing the design requirement. The collaboration will serve you better in long run.

INTRODUCTION

In the introduction, you should include about ‘why’ and ‘what’ about the epic. If you are writing an epic to develop a new feature include why you have decided to develop this feature, what are the user needs you are trying to solve and what are you trying to achieve with this new feature along with the metric you plan to use for measuring the achievement of the new feature. In addition, if you have any documentation or early wireframes for the feature include those in the introduction to provide as much clear picture & information you can provide to your team. Note: shared common understanding and goal is a key to successful delivery.

In short, your introduction can include:

• summary of what the features you’re building are for and why you’re building them
• what metrics you are trying to improve
• links to specific documentation
• marketing plans, legal requirements (if any)
• early wireframes

Example : Suppose you and your team is working with a messenger service and now you want to add a feature for the user so that the user can upload the pictures from their device and share it with their contacts. So this is how your introduction can look like:

This feature will allow users to send pictures to their contact through our messenger service.

Our research shows that 60% of users would use this functionality and in user testing our designs were intuitive for users.

We expect that this functionality will increase the number of messages sent per user by 10% on avg, which will result in approx. 3% additional time spent using our service in the course of a month.

Ideally, we want people to be able to share multiple varieties of files, but for MVP we have decided only allow uploading photos from their mobile, desktop and tablet.

PRODUCT REQUIREMENT

An essential part of the epic where you provide with an explanation for the whole team working on it to understand what are they going to design, build, test or release. For example, if you are building a feature that the feature has to be fast or should be available in multiple languages, or should work on multiple devices like mobile, tablet and desktop should be mentioned in the product requirement section of your epic.

Continuing the above example your product requirement could look like below

Product Requirements

• User can initiate a photo message from the message window
• User can select a photo from their own device
• User can preview the image before sending
• User can cancel the send before it is complete
• User should be able to send any resolution photos from their device
• User should be notified about the successful upload
• User can see the uploaded photo in a preview mode and can click to open a full image

DESIGN REQUIREMENTS

While writing the design requirement collaborate with your UX designer as much as you can. Take their input as there might be things that a designer thinks is important in order to have a better user experience which wouldn't cross your mind. For example, a designer might think the preview should be of a certain size and the profile picture should always maintain certain resolution in order for a good experience than those kinds of requirement should be written here.

Continuing the example ahead this can be how your design requirements may look:

Design Requirements

• The photos should be stored in our servers so the user can see them even when they switch their devices
• Maximum photo size should be 2000X2000 pixels.
• Preview should be atleast 600X600 in the aspect ratio of the uploaded image
• Loading indicator to be shown to the user while the user is waiting for the upload, in case of any delays
• Success indicator to be shown for successful uploads

ENGINEERING REQUIREMENTS

Similar to the design requirement in this part of the epic try to involve the engineers or tech lead as much as possible. Their inputs in the early stage will be very useful while estimation and building it correctly. For example, the engineering team might want to build an API to integrate with some other system in order to fetch and maintain the quality of an image, those kinds of specifications and requirements should be mentioned under engineering requirements.

Continuing with the above example the engineering requirement can look like below:

Engineering Requirements

• Need a database that can scale to X number of images at a maximum of 5MB per image
• Pull user IDs from user profile to connect with the photos in our database
• Create an auto-delete system to delete images after 1 year to make it GDPR compliant

Having a good epic spec document will have a very positive effect on your team to collaborate and build the right thing. For you as a product manager to create user stories to slice it down and prioritize your backlog, have a smoother development process and easy shipment.

USER STORIES

User stories are basically the break down of an epic in a more user-focused way for the engineering team to understand the product requirement. In agile methodologies, everything that we build should be focused around users and hence the main purpose of the user story should be to shift the focus around a feature in a more human conversation manner.

Here is a simple template that is widely used while creating user stories:

As a (type of user), I want (some goal), so that (reason).

The point of the user story is to clearly state the feature desired from the point of view of the user.

A user story must have just the right level of detail. It should be a high-level requirement with additional detail added to the accustomed acceptance criteria. The acceptance criteria are the clear picture for the engineering team to understand ‘what’ they are building and for the QA to clearly state the acceptance test. The components to be included are:

• Acceptance Criteria
• Design attached to the user story

As we have already created an epic, to build a feature that allows the user to share the photos from their devices with their contacts. I would like to continue with the same example to write some user stories.

User story : As a user, I want to select photos from my device in the messenger service so that I can share it with my contacts.

Acceptance criteria : Given I am a user and I click the “add picture’’ button in the message window, I am presented with a popup window to choose the file I can upload, submit it with the upload button and see a preview of the uploaded image.

Given I am a user who has successfully uploaded a photo from my mobile when I click send, the image is sent to my contact and it appears in our chat window.

If you want to learn in-depth about how to write acceptance criteria you can read the article on How to write acceptance criteria? Best practices, format, examples, and tips.

Writing a clear user story with acceptance criteria helps the engineers to think through the process while building the feature. Attach all the design for the engineers and the QA to follow while working on the user story. Make estimation relatively easy for the scrum master to follow. In short a well-written user story = win… win… win…

Hope the above guidelines are helpful to you when you create your next epic and user stories.

Written by Bindiya Thakkar

Passionate Product Manager, SAFe 5 certified POPM, an artist at heart, painter, writer, & explorer. Creator of Instagram channel product_people_memes.

More from Bindiya Thakkar and Product Coalition

What is an Epic and User Story? How to name Epics & User Stories?

Basic understanding of epics & user stories..

Ally Mexicotte

What I Look For in a Senior Designer Portfolio at a Consumer-Facing Early Stage Startup

I recently completed the process of hiring for a head of design role at my current company and was surprised when i couldn’t find much….

Olivia Belitsky

We Don’t Need Perfect Solutions: About the ‘Key Motivators’ Framework

What if your b2b users loved your product.

How to write acceptance criteria?

Best practice, format, examples, and tips for writing acceptance criteria, recommended from medium.

Kshitij Saxena

How to Write a Product Requirement Document?

Unravel the essentials of a product requirement document in product development that aligns with design, engineering, and business goals.

Brandon Chu

The Black Box of Product Management

The First Principles of Product Management

Some of the best pms i know make their decisions based on first principles. a first principle is a “basic, foundational proposition or….

Good Product Thinking

A Guide to OKRs – Objectives and Key Results

Growth Marketing

Jane Sydorova

Muzli - Design Inspiration

How to Conduct Product Discovery

Product discovery is the practice of ongoing research and user validation methods to make sure you’re creating the correct solutions for….

AltexSoft Inc

Acceptance Criteria for User Stories in Agile: Purposes, Formats, Examples, and Best Practices

Imagine that you ask your development team to enable users to search for a product in an online bookstore by category. you expect a….

Chris Bauer

I learned Jira, so you don’t have to: Building a Transparent End-To-End Product Flow

Recently i’ve been working a lot in jira. like, a lot a lot. i’ve been referred to as the jira wizard at work over it (a dubious….

9 Patterns of User Story Splitting

One of the biggest challenges in agile product backlog management is how to split a user story. while one of the important practices in….

Text to speech

• Integrations
• Get in touch Get in touch
• Getting Started Guide
• Product Updates
• Get in touch
• How to Start
• First Steps
• Views: Setup & Usage
• Work With Entities
• Track and Measure Progress
• Testing Module/QA Area
• Integrations & API
• Install, Upgrade & Maintenance
• Legal Notes
• Featured Articles
• Filters & Search
• Reports & Dashboards
• Mashups Library
• Service Desk
• Troubleshooting
• Video Tutorials
• Estimating & Planning
• Bug Tracking
• Import & Export Data
• Administration & Settings
• Pricing, Payment & Billing
• Email Support
• Support Desk
• Developers & API
• Request Demo
• Blog & Articles
• Lean Budgeting

Epic Hypothesis Statement (EHS)

• Value Stream Enablement
• Budgeting by Custom Period
• Requirement Enablement
• Work Estimated Cost
• Lean Business Case (LBC)
• Lean Budgeting: Portfolio Epic MVP Cost
• Capacity allocation by value type: Business, Enabler, Technical Debt

Requires the following solution to be installed:

• Requirement Enablement (eaf4ecf8-6dfc-43a7-84b7-e637c70a487e)

Can be extended with the following solution:

• Lean Business Case (1a187fc1-5375-4b6f-b994-ffc74651c666)
• Lean Budgeting: Portfolio Epic MVP Cost (03b2ead1-4496-4c10-bb88-4dfbd1d4c627)

Solution Overview

Since Portfolio Epics are some of the most significant enterprise investments, stakeholders must agree on their intent and definition. The solution enables a Portfolio Epic Hypothesis Statement template (a new tab) for capturing, organizing, and communicating critical information about a Portfolio Epic .

 Hypothesis Statement  tab contains the following information:

• Funnel Entry Date  – shows the date that the  Portfolio Epic  entered the funnel, i.e. have been created.
• Key Stakeholders  – defines a list of Portfolio Epic stakeholders. By default, you'll see here the list of roles responsible for a Portfolio Epic. To add Key Stakeholder  and  Portfolio Epic Owner roles for a Portfolio Epic , please follow the steps described  here .
• Epic Hypothesis Statement  – describes a Portfolio Epic from hypothesis statement perspective. Read more details here .
• Business Outcomes –  defines how the success of the  Portfolio Epic  will be measured. For example, 50% increase in shoppers under 25 ; Availability increases from 95% to 99.7% , etc.
• Leading Indicators – e stablishes innovation accounting metrics to provide leading indicators of the outcomes hypothesis. For example: A   measurable change in purchaser demographics within 30 days of feature release .
• Non-Functional Requirements - N on-Functional Requirements (NFRs)  associated with the  Portfolio Epic .

Solution Installation

When you install the solution, it won't automatically add  Hypothesis Statement  template to existing Portfolio Epics . To fill the field with the template please do the following:

• Open  Settings -> Automation Rules
• Set Hypothesis Statement for existing Portfolio Epics
• Click  Save and trigger now  button
• Disable the rule after run

As a result the existing Portfolio Epics will have Hypothesis Statement template added:

----------------

Version 1.1

Still have a question?

We're here to help! Just contact our friendly support team

Using Tracker to Communicate Epic Hypothesis Statements

At Pivotal, our teams use an agile project management tool called Pivotal Tracker. This software enables real-time collaboration around a single, shared, prioritized backlog. A product manager uses Tracker to write fine-grained user stories using a syntax that supports our opinionated development process. Most feature stories contain a scenario and acceptance criteria, using the Gherkin syntax to define and communicate user value. Here’s what that template looks like:

As a persona

I want to do a thing/be prevented from doing a thing

So that user value

Given preconditions

When actions

Then results

This works well for conversations within the product team, and between the team and the product owner, who are all focused full time on the product and its progress. For a startup, this could describe all the necessary—and all the interested—parties.

Product teams that are part of larger organizations often find their stakeholders must spread their attention across multiple product teams. For casual users of Tracker, the level of detail intrinsic in small feature stories in Gherkin can be disorienting. With all these details in the way, it can be difficult to keep the big picture in view.

Fortunately, Tracker includes the concept of epics , larger scale stories or themes that can be used to group smaller feature stories into more abstract descriptions of user and business value. By directing casual users to a list of epics, we have found that they can stay informed about the product team’s progress without getting mired in the details of the Features backlog. And they are more likely to remain engaged in the agile XP process.

The epic story type includes a description field, just like the one in the feature story type. How can this be asset leveraged to communicate higher level business value for the product stakeholders?

From experience with feature stories, we know a standard syntax reduces cognitive overhead, so we’ll look for a variation of the feature Gherkin. Since the stakeholders tend to be business focused, a formal business hypothesis format is a strong contender. The goal is to craft a premise with defined goals that can be proven or disproven (measured) as the epic is built and deployed.

The first part is the value statement :

For customers

Who do a thing

The solution

Is a something (the “how”)

That provides this value

Next come the business outcomes , which state the benefits to the business if the hypothesis is proven correct. This is followed by leading indicators , the early metrics that will tell us if we’re on the right track. Finally, the nonfunctional requirements outline the systems that will have to be built or altered to support the epic.

Unlike competitor, current solution, or nonexistent solution

Our solution does something better (the “why”)

Here’s an example using a pseudo-real-world business hypothesis:

For third-party contractors

Who make changes to our data

The Snowball Epic

Is a streamlined workflow

That provides 24/7 access to a secured portion of our database

Unlike the current ZIP file export/import model

Our solution is more stable, has a shorter cycle time, and increases transparency

Business Outcome Hypothesis

• contractors’ work is not delayed when enormous ZIP files sent via email crash
• project costs decrease when data is unlocked as soon as it is available
• data access is automatically logged

Leading Indicators

• email system is removed from workflow
• staff spend less time creating a secured portion of the database than assembling, sending and debugging ZIP files
• fewer payment disputes

Nonfunctional Requirements

• Relies on SSO to internal systems, which was recently approved for use by contractors

With this level of description contained in the product epics, stakeholders can easily access most of the information they need on a day-to-day basis.

When the product manager tags the stories associated with an epic, Tracker can display progress toward completion. A stakeholder will never be at a loss to provide a status update. And they have a low-barrier introduction to the power of Tracker!

Judy van Soldt is a Staff Product Manager at Pivotal Labs.

Category: Productivity

Tags: Agile Epics How to

Have a language expert improve your writing

Run a free plagiarism check in 10 minutes, generate accurate citations for free.

• Knowledge Base

Methodology

• How to Write a Strong Hypothesis | Steps & Examples

How to Write a Strong Hypothesis | Steps & Examples

Published on May 6, 2022 by Shona McCombes . Revised on November 20, 2023.

A hypothesis is a statement that can be tested by scientific research. If you want to test a relationship between two or more variables, you need to write hypotheses before you start your experiment or data collection .

Example: Hypothesis

Daily apple consumption leads to fewer doctor’s visits.

Table of contents

What is a hypothesis, developing a hypothesis (with example), hypothesis examples, other interesting articles, frequently asked questions about writing hypotheses.

A hypothesis states your predictions about what your research will find. It is a tentative answer to your research question that has not yet been tested. For some research projects, you might have to write several hypotheses that address different aspects of your research question.

A hypothesis is not just a guess – it should be based on existing theories and knowledge. It also has to be testable, which means you can support or refute it through scientific research methods (such as experiments, observations and statistical analysis of data).

Variables in hypotheses

Hypotheses propose a relationship between two or more types of variables .

• An independent variable is something the researcher changes or controls.
• A dependent variable is something the researcher observes and measures.

If there are any control variables , extraneous variables , or confounding variables , be sure to jot those down as you go to minimize the chances that research bias  will affect your results.

In this example, the independent variable is exposure to the sun – the assumed cause . The dependent variable is the level of happiness – the assumed effect .

Here's why students love Scribbr's proofreading services

Discover proofreading & editing

Step 1. Ask a question

Writing a hypothesis begins with a research question that you want to answer. The question should be focused, specific, and researchable within the constraints of your project.

Step 2. Do some preliminary research

Your initial answer to the question should be based on what is already known about the topic. Look for theories and previous studies to help you form educated assumptions about what your research will find.

At this stage, you might construct a conceptual framework to ensure that you’re embarking on a relevant topic . This can also help you identify which variables you will study and what you think the relationships are between them. Sometimes, you’ll have to operationalize more complex constructs.

Step 3. Formulate your hypothesis

Now you should have some idea of what you expect to find. Write your initial answer to the question in a clear, concise sentence.

4. Refine your hypothesis

You need to make sure your hypothesis is specific and testable. There are various ways of phrasing a hypothesis, but all the terms you use should have clear definitions, and the hypothesis should contain:

• The relevant variables
• The specific group being studied
• The predicted outcome of the experiment or analysis

5. Phrase your hypothesis in three ways

To identify the variables, you can write a simple prediction in  if…then form. The first part of the sentence states the independent variable and the second part states the dependent variable.

In academic research, hypotheses are more commonly phrased in terms of correlations or effects, where you directly state the predicted relationship between variables.

If you are comparing two groups, the hypothesis can state what difference you expect to find between them.

6. Write a null hypothesis

If your research involves statistical hypothesis testing , you will also have to write a null hypothesis . The null hypothesis is the default position that there is no association between the variables. The null hypothesis is written as H 0 , while the alternative hypothesis is H 1 or H a .

• H 0 : The number of lectures attended by first-year students has no effect on their final exam scores.
• H 1 : The number of lectures attended by first-year students has a positive effect on their final exam scores.

If you want to know more about the research process , methodology , research bias , or statistics , make sure to check out some of our other articles with explanations and examples.

• Sampling methods
• Simple random sampling
• Stratified sampling
• Cluster sampling
• Likert scales
• Reproducibility

 Statistics

• Null hypothesis
• Statistical power
• Probability distribution
• Effect size
• Poisson distribution

Research bias

• Optimism bias
• Cognitive bias
• Implicit bias
• Hawthorne effect
• Anchoring bias
• Explicit bias

Prevent plagiarism. Run a free check.

A hypothesis is not just a guess — it should be based on existing theories and knowledge. It also has to be testable, which means you can support or refute it through scientific research methods (such as experiments, observations and statistical analysis of data).

Null and alternative hypotheses are used in statistical hypothesis testing . The null hypothesis of a test always predicts no effect or no relationship between variables, while the alternative hypothesis states your research prediction of an effect or relationship.

Hypothesis testing is a formal procedure for investigating our ideas about the world using statistics. It is used by scientists to test specific predictions, called hypotheses , by calculating how likely it is that a pattern or relationship between variables could have arisen by chance.

Cite this Scribbr article

If you want to cite this source, you can copy and paste the citation or click the “Cite this Scribbr article” button to automatically add the citation to our free Citation Generator.

McCombes, S. (2023, November 20). How to Write a Strong Hypothesis | Steps & Examples. Scribbr. Retrieved April 2, 2024, from https://www.scribbr.com/methodology/hypothesis/

Is this article helpful?

Shona McCombes

Other students also liked, construct validity | definition, types, & examples, what is a conceptual framework | tips & examples, operationalization | a guide with examples, pros & cons, unlimited academic ai-proofreading.

✔ Document error-free in 5minutes ✔ Unlimited document corrections ✔ Specialized in correcting academic texts

Jira Software

Project and issue tracking

Content collaboration

Jira Service Management

High-velocity ITSM

Visual project management

• View all products

Marketplace

Connect thousands of apps and integrations for all your Atlassian products

Developer Experience Platform

Jira Product Discovery

Prioritization and roadmapping

You might find helpful

Cloud Product Roadmap

Atlassian Migration Program

Work Management

Manage projects and align goals across all teams to achieve deliverables

IT Service Management

Enable dev, IT ops, and business teams to deliver great service at high velocity

Agile & DevOps

Run a world-class agile software organization from discovery to delivery and operations

BY TEAM SIZE

Small Business

BY TEAM FUNCTION

Software Development

BY INDUSTRY

Telecommunications

Professional Services

What's new

Atlassian together.

Get Atlassian work management products in one convenient package for enterprise teams.

Atlassian Trust & Security

Customer Case Studies

Atlassian University

Atlassian Playbook

Product Documentation

Developer Resources

Atlassian Community

Atlassian Support

Enterprise Services

Partner Support

Purchasing & Licensing

Work Life Blog

Support for Server products ends February 15, 2024

With end of support for our Server products fast approaching, create a winning plan for your Cloud migration with the Atlassian Migration Program.

Assess my options

Atlassian Presents: Unleash

Product updates, hands-on training, and technical demos – catch all that and more at our biggest agile & DevOps event.

• Atlassian.com
• Business Strategy
• Docs & Reports
• Human Resources
• Marketing & Sales
• Product Management
• Productivity
• Project Planning
• Software Development / IT

SAFe lean business case template

By scaled agile, inc..

Create a lean business case for your portfolio epic based on SAFe agile practices

Having one standardized and organized method to keep track of all of your portfolio epics is essential to successful lean portfolio management . Moreover, adopting SAFe practices allows you to manage opportunities and risks via lean business cases that are implemented through the build-measure-learn SAFe Lean Startup Cycle . With this template, you’ll be able to document a business case based on a benefit hypothesis and a defined MVP, rather than a speculative ROI that would require the full potential investment. With Confluence, you can organize all of your portfolio epic documentation in one space, making it easy to analyze inputs, record decisions, and keep everyone aligned to a common objective. Read more on the SAFe epic article .

How to use the SAFe lean business case template

Step 1. determine the scope and details of the epic..

The creation of the business case is usually the primary responsibility of the epic owner. Before diving into the creation of your lean business case, set the stage for this portfolio epic. Make sure you are creating the lean business case at the right time. It is part of the analyzing phase of the portfolio Kanban system. Too early would create waste, and too late risks making investments without understanding the context. First, decide who will be involved in the proposal, to ensure that all sponsoring stakeholders are included. Then, concisely describe the epic, define how the success of the epic will be measured in the Business Outcomes Hypothesis, and establish what leading indicators will be used to indicate progress. This will help you determine the scope of the epic, and most importantly, how to define your MVP. Make sure to include any background analyses you conducted, and leave space to capture the final go/no-go recommendation.

Step 2. Create the lean business case.

Once you’ve laid down the groundwork, you’re ready to write the lean business case. Start by using the Epic Hypothesis Statement to describe the epic. This provides a short and concise way to define the business rationale, or the “why” of this Epic. Then define what is in and out of scope for this epic, as well as any nonfunctional requirements. Then define the MVP that will be used to test the hypothesis, as well as potential features this MVP will spawn Estimate the cost, preferably in the same currency used to run participatory budgeting . Don’t forget to provide an estimate of the overall cost of the Epic, once the MVP is successful. Lastly, document the kind of value return that is expected from the investment in the epic. 

Step 3. Document any supporting data.

Document the solution analysis that was carried out during the analyzing phase. Reference any additional resources, links, and supporting evidence so other team members and stakeholders can access it easily. Ensure that the attachments are labeled, using the Notes and Comments section to jot down any miscellaneous evidence. All of this informs the upcoming go/no-go decision. Be careful of information overload. The lean business case was created to make the process of laying out a business case faster and to make the review process easier. Attaching too many support documents in this field can slow down the reviewers and negate some of the benefits.  Alternatively, this space can be used to document notes during your team planning meetings.

Step 4. Keep the epic up to date.

As analysis and implementation of the MVP continue, keep the lean business case up to date to facilitate any portfolio review meetings or future portfolio funding.

Scaled Agile, Inc. is the provider of the Scaled Agile Framework (SAFe). Through courses, trainings, partners, and solutions, Scaled Agile, Inc. provides practices for scaling agile practices across the entire company. Through SAFe, they empower large and complex organizations to achieve the benefits of Lean-Agile software and systems development at scale.

More partners templates     View all

1-on-1 meeting.

Run 1-on-1 meetings and maintain productive working relationships.

AWS architecture diagram

Visualize your infrastructure to better identify weaknesses and pinpoint places for refinement.

Brainstorming

Plan, run, and document a remote brainstorming session for your next great idea.

Have a language expert improve your writing

Run a free plagiarism check in 10 minutes, automatically generate references for free.

• Knowledge Base
• Methodology
• How to Write a Strong Hypothesis | Guide & Examples

How to Write a Strong Hypothesis | Guide & Examples

Published on 6 May 2022 by Shona McCombes .

A hypothesis is a statement that can be tested by scientific research. If you want to test a relationship between two or more variables, you need to write hypotheses before you start your experiment or data collection.

Table of contents

What is a hypothesis, developing a hypothesis (with example), hypothesis examples, frequently asked questions about writing hypotheses.

A hypothesis states your predictions about what your research will find. It is a tentative answer to your research question that has not yet been tested. For some research projects, you might have to write several hypotheses that address different aspects of your research question.

A hypothesis is not just a guess – it should be based on existing theories and knowledge. It also has to be testable, which means you can support or refute it through scientific research methods (such as experiments, observations, and statistical analysis of data).

Variables in hypotheses

Hypotheses propose a relationship between two or more variables . An independent variable is something the researcher changes or controls. A dependent variable is something the researcher observes and measures.

In this example, the independent variable is exposure to the sun – the assumed cause . The dependent variable is the level of happiness – the assumed effect .

Prevent plagiarism, run a free check.

Step 1: ask a question.

Writing a hypothesis begins with a research question that you want to answer. The question should be focused, specific, and researchable within the constraints of your project.

Step 2: Do some preliminary research

Your initial answer to the question should be based on what is already known about the topic. Look for theories and previous studies to help you form educated assumptions about what your research will find.

At this stage, you might construct a conceptual framework to identify which variables you will study and what you think the relationships are between them. Sometimes, you’ll have to operationalise more complex constructs.

Step 3: Formulate your hypothesis

Now you should have some idea of what you expect to find. Write your initial answer to the question in a clear, concise sentence.

Step 4: Refine your hypothesis

You need to make sure your hypothesis is specific and testable. There are various ways of phrasing a hypothesis, but all the terms you use should have clear definitions, and the hypothesis should contain:

• The relevant variables
• The specific group being studied
• The predicted outcome of the experiment or analysis

Step 5: Phrase your hypothesis in three ways

To identify the variables, you can write a simple prediction in if … then form. The first part of the sentence states the independent variable and the second part states the dependent variable.

In academic research, hypotheses are more commonly phrased in terms of correlations or effects, where you directly state the predicted relationship between variables.

If you are comparing two groups, the hypothesis can state what difference you expect to find between them.

Step 6. Write a null hypothesis

If your research involves statistical hypothesis testing , you will also have to write a null hypothesis. The null hypothesis is the default position that there is no association between the variables. The null hypothesis is written as H 0 , while the alternative hypothesis is H 1 or H a .

Hypothesis testing is a formal procedure for investigating our ideas about the world using statistics. It is used by scientists to test specific predictions, called hypotheses , by calculating how likely it is that a pattern or relationship between variables could have arisen by chance.

A hypothesis is not just a guess. It should be based on existing theories and knowledge. It also has to be testable, which means you can support or refute it through scientific research methods (such as experiments, observations, and statistical analysis of data).

A research hypothesis is your proposed answer to your research question. The research hypothesis usually includes an explanation (‘ x affects y because …’).

A statistical hypothesis, on the other hand, is a mathematical statement about a population parameter. Statistical hypotheses always come in pairs: the null and alternative hypotheses. In a well-designed study , the statistical hypotheses correspond logically to the research hypothesis.

Cite this Scribbr article

If you want to cite this source, you can copy and paste the citation or click the ‘Cite this Scribbr article’ button to automatically add the citation to our free Reference Generator.

McCombes, S. (2022, May 06). How to Write a Strong Hypothesis | Guide & Examples. Scribbr. Retrieved 2 April 2024, from https://www.scribbr.co.uk/research-methods/hypothesis-writing/

Is this article helpful?

Shona McCombes

Other students also liked, operationalisation | a guide with examples, pros & cons, what is a conceptual framework | tips & examples, a quick guide to experimental design | 5 steps & examples.