example epic hypothesis statement

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 Name Last Name

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.

• Share on Twitter
• Share on LinkedIn
• Share on Facebook
• Share on Pinterest
• Share through Email

What Is An Agile Epic? Best Practices, Template & Example

I am a senior product manager with 15 years experience in a variety of companies, amongst them some of the best practice Product companies in the world like eBay and Guardian News & Media. In my varied roles I have worked in companies of various sizes and at different stages of maturity of their Product Management organizations. I have been the first product manager of the company in several of my roles and tackled introducing Product Management into a business. My other passion is User Experience. I undertook an MSc degree in Human-Centred Systems at City University London from 2010-2012. The combination of Product Management and User Experience means that user insight is always at the heart of my work. I believe that real-life Product Management can be quite daunting and the solutions to numerous challenges cannot always be found in textbooks. I hope that sharing my own experiences of what works in real life helps product managers to succeed and their products to thrive.

Agile epics are a crucial tool for grouping user stories into bigger initiatives and structure an agile backlog. Here are some pro tips on how you can use epics to their full potential.

Do you know the difference between an agile epic and a user story ? Or how to best use agile epics for your product requirements and product roadmap? If you’d like to learn how to use agile epics to your advantage, read on for my top seven tips and a template to start.

What Is An Agile Epic?

An agile epic is a useful tool in agile project management used to structure your agile backlog and roadmap.

Simply put, an agile epic is a collection of smaller user stories that describe a large work item. Consider an epic a large user story. For example, epics are often used to describe a new product feature or bigger piece of functionality to be developed.

An epic is the top informational level in an agile backlog. It contains several user stories and each user story in turn contains all the tasks required for implementation.

Agile epics are mostly used when a piece of work is too big to be delivered in a single sprint or iteration. If you use an epic to group your user stories for a new feature, it is easy to keep track of progress and know what percentage of work is completed versus outstanding. 

Epics are usually written and maintained by the product owner or product manager. 

7 Best Practices To Using Agile Epics

There is no set template for an agile epic. You can write it in any way you like as long as it helps with planning your work and communication with your agile teams and stakeholders. 

Regardless if you use a scrum or kanban or a hybrid development process, epics will help you plan your work and report on it.

Here are some tips to make sure that your agile epics are most useful. 

Stay in-the-know on all things product management including trends, how-tos, and insights - delivered right to your inbox.

• Your email *
• By submitting this form, you agree to receive our newsletter and occasional emails related to The Product Manager. You can unsubscribe at any time. For more details, please review our Privacy Policy . We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
• Email This field is for validation purposes and should be left unchanged.

1. Start With Epic Then Stories (Top Down)

Finding your epics can very usefully be done with a user story map . Your top level “Activity” in the user story map becomes an epic and the lower levels become the user stories, tasks, and acceptance criteria . 

When you are developing a whole new product, starting with epics and fleshing them out in more detail as you go along, gives you an idea of the milestones completed and outstanding. 

Often agile epics correspond to features or larger improvements (e.g. a redesign of part of your product), but it is entirely up to you how you want to structure your epics. 

2. Name An Epic Well

When you name your agile epics, think about who will consume this information. For example, your agile development teams need to understand what they are building and your stakeholders also need to understand your progress. 

Whereas a user story describes an end-user need, it’s good practice if the epic describes an outcome you want to achieve with it.

Consider these examples for epic names:

• Checkout flow V2
• Streamline checkout flow
• Increase conversion rate in checkout

The first name doesn’t describe at all what it is other than some kind of work on checkout. The second name is better as it describes that the checkout flow is to be streamlined. But the third name is even better as it includes an outcome that you want to achieve with this streamlining. 

In agile management tools, like Atlassian’s Jira for example, epics can be used for filtering, grouping, and reporting. Therefore choosing a name that speaks for itself is important.

3. Make Your Epics The Right Size

An epic is usually used when work on a backlog item requires more than a single sprint to complete. An epic can break down into as many user stories as you like as long as you can keep track of the whole list. 

An epic should be not too big and not too small. A rule of thumb would be an implementation timeframe between a few weeks and a few months. This is a good size for reporting on the percentage completed. 

Making epics too big means that progress is very slow, percentages hardly increase over a two-week sprint and reporting is not meaningful. Also if an epic takes too long to implement, there are likely to be so many changes to requirements along the way that reporting progress almost becomes meaningless. 

Making epics too small means that you will have a great number of them to juggle in your backlog or roadmap. It can become difficult to retain a high-level view of many smaller tasks. Also if epics are completed in a very short time (e.g. a single sprint), they just add additional overhead without providing much value. 

4. Use Epics To Structure Your Backlog

Epics are an excellent way to structure a product backlog that usually consists of a very long list of user stories. Not every story requires to be included in an epic, as small pieces of work are simply completed within one sprint. But to structure bigger items of work into epics has two main benefits:

• It provides a high-level view of the big items in your backlog,
• As the size of an epic is made up of the addition of story points of all its user stories, epics also provide a comparison of the relative size of initiatives for prioritization . 

The list of epics can also be used to create a high-level view of a product roadmap for senior management.

5. Use Epics To Coordinate Multiple Teams

Epics can be very useful to coordinate chunks of work across multiple agile software development teams. Combining work for multiple product teams in a single epic allows you to break down the reporting per team and track progress overall. 

6. Include Success Metrics

When defining an epic it is worthwhile thinking about what success metric can be associated with it. Ultimately all product deliverables serve to bring value to end-users. Including a success metric in your epic means that development team members and stakeholders all understand what you are trying to achieve with this piece of work. 

Some companies use OKRs to set quarterly goals. Referencing an OKR metric in an epic is an excellent way to tie an epic back to the business objectives. 

7. Make Epics Flexible In Scope

As an epic describes a high-level work item continuing over several weeks or months, it is likely that new insight arises or new technical complications are discovered as work progresses. Therefore an epic needs to be flexible in scope. 

The scope of an epic is defined by the scope of its associated user stories, usually measured in story points.  As new requirements emerge, new user stories may be added and the scope of the epic increases.

Related Read: Best Agile Product Management Software

Agile Epic Template 

There is no set format for an epic, but a few things are useful as described above.

• Choose a good name that speaks for itself.
• In the description,  give a rough outline of what the epic encompasses. Reference any company goals to illustrate how this ties in with business priorities.
• The success metric describes specifically what will be measured after completion of this epic.
• Big user story denotes a user story at the level of the whole epic. This is very useful in order to document how this epic delivers a better user experience.  

Agile Epic Example

Here is an example of an epic for a new streamlined mobile app checkout flow in order to increase conversion. 

Within this epic, we could then have user stories such as:

• Integrate Apple Pay ( “As a buyer, I want to pay with one touch on my phone so that I can complete checkout quickly” )
• Use billing address as shipping address per default ( “As a buyer, I want to enter my address details only once so that I can complete checkout quickly” )

Agile epics are a flexible tool in your agile toolkit. When starting a major new development, think about the big pieces of work required to complete it and define a few epics. You can then create all your user stories within these epics as you go along and retain a much better overview than in an unstructured backlog. 

Epics can be used in many ways. I would be very interested to learn how you use epics in your agile teams in the comments. 

For more articles with hands-on practical information about a great variety of product management topics—including agile methodology!— subscribe to our newsletter .

Also Worth Checking Out:

• Product Pricing: Value-Based Strategy, Software Packaging with Dan Balcauski
• 4 Best Online Agile Product Management Certifications

What Is A Portfolio Roadmap? How To Create Yours In 7 Steps

The OKR Roadmap: What It Is & How to Use It

Product Strategy: What It Is, and How to Nail It

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

What is an epic in agile? Complete guide with examples

Agile development is an iterative process that enables software development teams to accelerate their time to market by fostering and embracing a culture of continuous learning. Agile teams learn by doing.

In product development, the strategy and roadmap is based on data and insights from the market, which is always evolving. The product team must be dynamic enough to adapt to shifting requirements and user needs. This is a core agile value as outlined in the Agile Manifesto .

It’s not enough to anticipate user needs because they are ever-evolving. Agile development teams work in short, iterative sprints , which affords them the flexibility and pragmatism required to deliver complex products.

What is an epic?

An epic is a feature or functionality consisting of multiple building blocks and scenarios. Epics are derived from themes or initiatives and can be segmented into smaller pieces called user stories .

An epic can span across multiple sprints, teams, and even projects. The theme, epic, and user stories share the same strategic goal at different levels of the focus area.

Consider the example of building a house. If an initiative is like building the ground floor, an epic is like creating a kitchen and a user story is like building a wall, with each brick being a task.

Agile development breaks down a broad product vision into small, achievable tasks that produce frequently updated results.

Like building a house, the product development lifecycle can feel overwhelming. The direction of where to start may not be apparent to everyone working on the product. But it helps to break down the larger initiative into several themes — for example, building the foundation and the ground floor.

You can break it down further into epics — e.g., building each room — and then even further to building a wall. This gives us a clearer picture of what we need to achieve today to make meaningful progress toward the strategic initiative .

In large organizations, where several cross-functional teams are involved in product development, epics help everyone get on the same page around development goals, dependencies, and priorities.

Epics vs. user stories vs. initiatives

Depending on the organization’s size, the product’s complexity, the composition of initiatives, themes, and epic may vary in dimensions. Smaller products or organizations may only have one top hierarchy. However, if the design of scale is used within the circumference of an organization, the basic idea is the same.

A product roadmap boils down to smaller, achievable tasks. In any product development cycle, multiple features concurrently fulfill users’ needs. But that doesn’t mean the product needs to be fully developed with all features complete at the time of launch .

A core value of agile development is quick delivery and learning by doing. Breaking the theme into various levels helps shorten the product development lifecycle from ideation to execution.

This segmentation also helps in prioritization by slicing the initiative into more manageable minimum viable products (MVPs) . The MVPs can be developed and launched to the user within a short period, allowing the team to learn and iterate, validate ideas, and adjust the roadmap as necessary.

Regardless of how you structure the hierarchy structure of themes/initiatives, epics, and user stories, each level is defined with a purpose.

Themes and initiatives

Themes and initiatives define the product vision. The big idea is segmented into strategic goals.

The purpose of the theme is to be the North Star, providing a clear picture of the entire organization’s focus area.

The initiative can be closing a market gap, addressing a pain point, innovation, market fit, etc.

Over 200k developers and product managers use LogRocket to create better digital experiences

An epic is the actualization of the product roadmap. The initiative is further segmented into defined features to develop.

Epics create alignment between the organization and the product development when it comes to prioritization .

User stories

A user story is user-focused and driven by user value.

Even though the product vision and roadmap come from within the organization, development should always be completely user-centric. User stories help the development team empathize with the user and clarify the value produced as a result of the product from the customer’s perspective.

How to write an epic

An epic is a high-level requirement of a feature. When writing an epic, your goal is to align stakeholders with your product vision and roadmap. To achieve that alignment with clarity and focus, you should provide all the relevant information, including any dependencies, clarify any misunderstandings, and establish a clear direction with a measurable goal.

Collaboration is key to a good epic description. Though the product manager is responsible for writing an epic spec, they’re not expected to be an expert at all levels. When creating an epic spec document, collaborate with your team to discuss and align on solution design, UX design, and the customer journey. Bring in all the required knowledge and expertise early to avoid getting stuck later on.

What to include in an epic

Every development is different, so the epic specs will differ from product to product. Some epics include granular detail while others only highlight high-level requirements.

An epic should include at least the bare minimum information the product team requires to get started on user stories and prioritize tasks to solve the customer’s needs as efficiently as possible.

Introduction

The introduction should outline the “why” and the “what” — the reason for prioritizing and developing the feature and user pain points to solve. You should also include the metrics and KPIs for measuring the performance.

In addition, any documentation or early wireframes you can provide go a long way toward establishing a common understanding of the goal and path to successful delivery. Some things to consider:

• Summary of features and reasons for developing them
• Performance metrics and KPIs
• Links to specific documentation
• Marketing plans and legal requirements (if any)
• Early wireframes

Product requirements

An essential objective of the epic is to establish a shared understanding of the development goal. The epic should include the feature’s functional and nonfunctional requirements.

The product requirements documentation might mention availability in multiple languages or on multiple devices, for example.

Design requirements

You should always collaborate with the UX designer to write the design requirement. They are the expert and will surely have insights to share from their countless user test experiences.

Examples of product design requirements might include things like:

• Where to place search functionality for each device
• A request for a prototype to simplify future group discussions

Engineering requirements

You should strive for alignment with the target architecture while compiling the high-level requirement in an epic. Like the tech stack or solution design, consideration in the early stages will help you estimate more accurately and maximize efficiency down the line.

For example, let’s say the engineering team wants to create an API to integrate with some existing database functionality to fetch a list of songs. Investigating these opportunities during the initial stages of creating the epic helps you avoid incurring inadvertent technical debt .

KPI and metrics

KPIs guide every product development cycle. A concrete set of metrics and goals will help the teams focused and motivated to hit stated objectives.

KPIs should be tangible and measurable. A vague KPI is of no value and does not motivate action. At first, some KPIs may seem not measurable, but after aligning with data analysts, there is always a way to measure development value in numbers.

For example, increasing customer satisfaction is a good KPI, but a little vague. Instead, try adding metrics such as net promoter score (NPS) or the number of times a user interacts with a new functionality in one session.

A real-world example of an epic

Let’s consider the example of a music streaming app to demonstrate how an epic is structured. Suppose you want to add search functionality to the app. The database contains more than 1 million songs from across the globe — a key differentiator for your product, so the search functionality is deemed critical to enable users to find whatever music they are looking for intuitively.

Using the epic template below, our epic would look something like this:

Keeping with this example, an epic spec document pertaining to the items populating the template above might read as follows:

The new search functionality will allow users to narrow down their search and offer suggestions to help them find the music they want to listen to instantly.

Our research shows that 86 percent of our user base is interested in the search functionality. Since the most commonly identified problem with searching music is that people can’t remember or recognize the song’s name, a voice search service shows the most considerable demand.

We expect this functionality will increase the number of songs played per user by 10 percent on average, which will result in approximately 30 percent additional time spent per month using the app.

• Users can initiate a search from multiple suitable pages in the app
• Users can begin a voice search
• AI integration in search functionality
• Customized search suggestions
• Should include tracking on each page
• Display search suggestions in a list filtered is different categories
• Design should work with accessibility rules
• New API’s to be built only in the new backend system
• Dependencies shared with the AI integration team
• Conversion rate: Clicks on the suggested list of songs
• Use of voice search: Avg. use per session per user

A good epic spec document will help you foster collaboration and achieve alignment across your team and your organization. Epics also make it easier to write user stories, slice down and prioritize the backlog, and run a smoother scrum .

In agile development, all the frameworks, structures, and processes are created with one principle: the ability to be flexible and deliver quickly to learn iteratively.

The main goal of any process or documentation is to create alignment, avoid misunderstanding, and minimize inadvertent technical debts while accelerating time to market.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #agile and scrum

Stop guessing about your digital experience with LogRocket

Recent posts:.

Leader Spotlight: Evaluating data in aggregate, with Christina Trampota

Christina Trampota shares how looking at data in aggregate can help you understand if you are building the right product for your audience.

What is marketing myopia? Definition, causes, and solutions

Combat marketing myopia by observing market trends and by allocating sufficient resources to research, development, and marketing.

Leader Spotlight: How features evolve from wants to necessities, with David LoPresti

David LoPresti, Director, U-Haul Apps at U-Haul, talks about how certain product features have evolved from wants to needs.

7 steps to winning at product strategy

With so many conflicting sources of information, it can be difficult to grasp how to actually implement a sound product strategy.

Leave a Reply Cancel reply

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.

Table of Contents

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

Top 5 Common Obstacles of a Scrum Master in 2021

7 Keys To Being A Leader In Agile Environment 

What is the future of Agile Development?

Agile Product Manager Interview Questions and Answers

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 .

Home > Resources > Understanding Leading Indicators in Product Development and Innovation

Understanding Leading Indicators in Product Development and Innovation

It’s quite common for people to nod knowingly when you mention leading indicators, but in reality, few people understand them. I believe people struggle with leading indicators because they are counterintuitive, and because lagging indicators are so ingrained in our current ways of working. So, let’s explore leading indicators: what they are, why they’re important, how they’re different from what you use today, and how you can use them to improve your innovation and product development .

What Are Leading and Lagging Indicators?

Leading indicators (or leading metrics) are a way of measuring things today with a level of confidence that we’re heading in the right direction and that our destination is still desirable. They are in-process measures that we think will correlate to successful outcomes later. In essence, they help us predict the future.

In contrast, lagging indicators measure past performance. They look backwards and measure what has already happened.

Take the example of customer experience (CX). This is a lagging indicator for your business because the customer has to  have  the experience before you can measure it. While it’s great to understand how your customers perceive your service, by the time you discover it sucks it might be too late to do anything about it.

ROI is another example of a lagging indicator: you have to invest in a project ahead of time but cannot calculate its returns until it’s completed. In days gone by you might have worked on a new product and spent many millions, only to discover the market didn’t want it and your ROI was poor.

Online retailers looking for leading indicators of CX might look instead at page load time, successful customer journeys, or the number of transactions that failed and ended up with customer service. I often tell clients that if these leading indicators are positive, we have reason to believe that CX, when measured, will also be positive.

Don Reinertsen shares a common example of leading vs. lagging indicators: the size of an airport security line is a leading indicator for the lagging indicator of the time it takes to pass through security screening. This makes sense because if there is a large line ahead of you, the time it will take to get through security and out the other side will be longer. We can only measure the total cycle time once we’ve experienced it.

If you operate in a SAFe ®  context , the success of a new train PI planning (which is a lagging indicator) is predicated on leading indicators like identifying key roles, training people, getting leadership buy-in, refining your backlog, socializing it with the teams, etc.

Simple Examples of Successful Leading Indicators

The Tesla presales process is a perfect example of how to develop leading indicators for ROI. Tesla takes refundable deposits, or pre-orders, months if not years before delivering the car to their customers. Well before the cars have gone to production, the company has a demonstrated indicator of demand for its vehicles.

Back in the 90s, Zappos was experimenting with selling shoes online in the burgeoning world of e-commerce. They used a model of making a loss on every shoe sold (by not holding stock and buying retail) as a leading indicator that an online shoe selling business would be successful before investing in the necessary infrastructure you might expect to operate in this industry.

If you are truly innovating (versus using innovation as an excuse for justifying product development antipatterns, like ignoring the customer) then the use of leading indicators can be a key contributor to your innovation accounting processes. In his best-selling book,  The Lean Startup , Eric Ries explains this concept. If you can demonstrate that your idea is moving forward by using validated learning to prove problems exist, then customers will show interest before you even have a product to sell. Likewise, as Dantar P. Oosterwal demonstrated in his book,  The Lean Machine , a pattern of purchase orders can be a leading indicator of product development and market success.

Leading Indicators Can Be Near-term Lagging Indicators

Let’s loop back and consider the definitions of leading and lagging indicators.

• Lagging: Measures output of an activity. Likely to be easy to measure, as you’ve potentially already got measurement in place.
• Leading: Measures inputs to the activity. Often harder to measure as you likely do not do this today.

Think about the process of trying to lose weight. Weight loss is a lagging indicator, but calories consumed and exercise performed are leading indicators, or inputs to the desired outcome of losing weight.

While it’s true that both calories consumed and exercise performed are activities that cannot be measured until they’re completed, and therefore might be considered  near-term lagging indicators , they become leading indicators because we’re using them on the path to  long-term lagging indicators . Think back to the CX example: page load time, successful customer journeys, and failed transactions that end up with customer service can all be considered near-term lagging indicators. Yet we can use them as leading indicators on a pathway to a long-term lagging indicator, CX.

How to Ideate Your Leading Indicators

The most successful approach I’ve applied with clients over many years is based on some work by Mario Moreira, with whom I worked many moons ago. I’ve tweaked the language and application a little and recommend you create a Pathway of Leading to Lagging Indicators. To demonstrate this, I will return to the CX example.

If we walk the pathway, we can estimate that an acceptable page load time will lead to a successful user journey, which—if acceptable—will then lead to fewer failed transactions that revert to customer service, which ultimately will lead to a positive customer experience metric.

Work Backwards from Your Lagging Indicator

To create your Leading to Lagging Pathway, start from your lagging indicator and work backwards looking at key successful elements that need to be true to allow your lagging indicator to be successful.

At this stage, these are all presuppositions; as in, we believe these to be true. They stay this way until you’ve collected data and can validate your pathway. This is similar to how you need to validate personas when you first create them.

Add Feedback Loop Cycle Times

Once you have your pathway mapped out, walk the pathway forward from your first leading indicator and discuss how often you can and should record, analyze, and take action for that measure. You should make these feedback loops as short as possible because the longer the loop, the longer it will take you to learn.

All that’s left is to implement your Leading to Lagging Pathway. You may find a mix of measures, some which you measure today and some you don’t. For those you already do measure, you may not be measuring them often enough. You also need to put in place business processes to analyze and take action. Remember that if measures do not drive decisions, then your actions are a waste of resources.

Your leading indicator might be a simple MVP. Tools like QuickMVP can support the implementation of a Tesla-style landing page to take pre-orders from your customers.

Applying Leading Indicators in Agile Product Management

A common anti-pattern I see in many product management functions is a solution looking for a problem. These are the sorts of pet projects that consume huge amounts of R&D budget and barely move the needle on profitability. Using design thinking and Lean Startup techniques can help you to validate the underlying problem, determine the best solution, and identify whether it’s desired by your potential customers and is something you can deliver profitably.

In SAFe, leading indicators are an important element of your epic benefit hypothesis statement. Leading indicators can give you a preview of the likelihood that your epic hypothesis will be proven, and they can help deliver this insight much earlier than if you weren’t using them. Insight allows you to pivot at an earlier stage, saving considerable time and money. By diverting spending to where it will give a better return, you are living by SAFe principle number one,  Take an economic view .

Let’s look at some working examples demonstrating the use of leading indicators.

I hope you can now see that leading indicators are very powerful and versatile, although not always obvious when you start using them. Start with your ideation by creating a Leading to Lagging Pathway, working back from your desired lagging indicator. If you get stuck, recall that near-term lagging indicators can be used as leading indicators on your pathway too. Finally, don’t feel you need to do this alone, pair or get a group of people together to walk through this process, the discussions will likely be valuable in creating alignment in addition to the output.

Let me know how you get on. Find me on the  SAFe Community Platform  and  LinkedIn .

About Glenn Smith

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

View all posts by Glenn Smith

Back to: All Blog Posts

Next: traits of the stoic agilist.

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

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

SAFe Glossary

The SAFe glossary is a set of definitions for all SAFe Big Picture elements.  The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.

• Chinese (Simplified)
• Chinese (Traditional)
• French (Canada)
• French (France)
• Portuguese (Brazil)

The 5 Whys is a proven problem-solving technique used to explore the cause-and-effect relationships underlying a particular problem as part of Inspect and Adapt.

Acceptance Criteria

Acceptance Criteria provide the information needed to ensure that a story, feature, or capability is implemented correctly and covers the relevant functionality and NFRs.

Acceptance Test Driven Development

Acceptance Test-Driven Development is a test-first, Agile testing practice synonymous with Behavior-Driven Development (BDD).

Agile is a set of values, principles, and practices for iterative development most notably described by the Agile Manifesto.

Agile Manifesto

The Agile Manifesto is the seminal Agile document describing the four values and twelve principles of Agile software development.

Agile Product Delivery

Agile Product Delivery is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users.

Agile Program Management Office

The Agile Program Management Office (APMO) is an organizational function responsible for facilitating the Lean Portfolio Management process and fostering operational excellence and lean governance as part of a Lean-Agile transformation.

Agile Release Train (ART)

The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.

Agile Teams

In SAFe, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box.

Architect Sync

The Architect Sync is a Solution Train event to ensure consistency in how emerging designs and tradeoffs are managed across the Solution Train, allowing frequent opportunities to steer implementation approaches without becoming a source of delays.

Architectural Runway

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

The ART Sync is an ART event that combines the Product Owner (PO) Sync and Scrum of Scrums (SoS).

Backlog Refinement

Backlog Refinement is an activity held once or twice during the iteration or increment to discuss, estimate, and establish an initial understanding of acceptance criteria for upcoming stories in the team’s backlog.

Baseline Solution Investments (BSIs)

Baseline Solution Investments (BSIs) are those costs incurred by each value stream as it develops, supports, and operates the solutions that deliver current business capabilities.

Batch size is a measure of how much work (the requirements, designs, code, tests, and other work items) is pulled into the system during any given timebox.

Behavior-Driven Development

Behavior-Driven Development (BDD) is a test-first, Agile testing practice that provides built-in quality by defining (and potentially automating) tests before, or as part of, specifying system behavior.

Benefit Hypothesis

The Benefit Hypothesis is the proposed measurable benefit to the end-user or business as part of a feature or capability.

Big Visible Information Radiator (BVIR)

A Big Visible Information Radiator (BVIR) is a graphical display that tracks and communicates critical data at a glance (e.g. burndown charts, program board, build status boards).

Built-In Quality

Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.

Burn-Down (Burn-Up) Chart

Burn-Down and Burn-Up Charts are graphical displays that show work progress versus time.

Business Agility

Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solutions.

Business and Technology

The Business and Technology icon in SAFe describes how functional domains in all parts of the enterprise enable business agility by continuously exploring new ways to apply Lean-Agile principles and practices to their unique contexts.

Business Context

Business Context is a PI Planning agenda item presented by a business owner that describes the current state of the business, shares the portfolio vision, and presents a perspective on how effectively existing solutions are addressing current customer needs.

Business Owners

Business Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.

SAFe’s CALMR approach to DevOps is a mindset that guides ARTs toward achieving continuous value delivery by managing simultaneous advancements in delivery culture, automation, lean flow, measurement, and recovery.

Capabilities

A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.

Capacity Allocation

Capacity Allocation is a lean budgeting guardrail for backlogs that helps balance the backlog of new features, enablers, and technical debt allocated to for upcoming Program Increment (PI).

Committed PI Objectives

The Committed PI Objectives are a set of SMART objectives that are created by each team with the business value assigned by the Business Owners.

Communities of Practice (CoPs)

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Compliance refers to a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously ensuring they meet any regulatory, industry, or other relevant standards.

Confidence Vote

The Confidence Vote is held near the end of PI Planning where the teams vote on their confidence in meeting PI objectives.

Continuous Delivery Pipeline (CDP)

The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end user.

Continuous Deployment (CD)

Continuous Deployment (CD) is the process that takes validated Features in a staging environment and deploys them into the production environment, where they are readied for release.

Continuous Exploration (CE)

Continuous Exploration (CE) is the process that drives innovation and fosters alignment on what should be built by continually exploring market and customer needs, and defining a Vision, Roadmap, and set of Features for a Solution that addresses those needs.

Continuous Integration (CI)

Continuous Integration (CI) is the process of taking features from the Program Backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.

Continuous Learning Culture

The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation.

Core Values

The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

Cost of Delay

Cost of Delay (CoD) represents the money or value that will be lost by delaying or not doing a job for some time and is used in WSJF prioritization.

Customers are the ultimate beneficiaries of the value of the business solutions created and maintained by the portfolio value streams.

Customer Centricity

Customer centricity is a mindset and a way of doing business that focuses on creating positive experiences for the customer through the full set of products and services that the enterprise offers.

Customer Journey Map

A Customer Journey Map illustrates the experiences as a user engages with a company’s operational value stream, products, and services.

Daily Stand-Up

The Daily Stand Up (DSU) is a daily team event where each team member describes what they did yesterday to advance iteration goals, what they are going to work on today to achieve the iteration goals, and any blocks they are encountering in delivering iteration goals.

Decentralized Decision-Making

Decentralized Decision-Making grants decision authority to those closest to the knowledge and information to reduce delays, increase product development flow, and improve the quality of decisions.

Definition of Done

The Definition of Done communicates the completeness for an increment of value and creates a shared understanding of what work was completed as part of an Increment.

To deploy is to migrate a change from a pre-production environment to a production (or operational) environment, where it then awaits release.

Design Thinking

Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable over their lifecycle.

Develop on Cadence

Develop on Cadence is a coordinated set of practices that support Agile Teams by providing a reliable series of events and activities that occur on a regular, predictable schedule.

Development Value Streams

Development value streams (DVS) are the sequence of activities needed to convert a business hypothesis into a digitally-enabled Solution. Examples include designing a medical device or geophysical satellite, or developing and deploying a software application, SaaS system, or an e-commerce web site.

DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution.

Empathy Map

An Empathy Map is a design thinking tool that helps teams develop deep, shared understanding for their customers.

An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. Enablers are captured in the various backlogs and occur throughout the Framework.

The Enterprise represents the business entity to which each SAFe portfolio belongs.

Enterprise Architect

The Enterprise Architect establishes a technology strategy and roadmap that enables a portfolio to support current and future business capabilities.

Enterprise Solution Delivery

The Enterprise Solution Delivery competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, operation, and evolution of the world’s largest and most sophisticated software applications, networks, and cyber-physical systems.

Epic Hypothesis Statement

The Epic Hypothesis Statement captures, organizes, and communicates critical information about an epic.

Epic Owners

Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They collaboratively define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.

An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval by Lean Portfolio Management (LPM) before implementation.

Essential SAFe

Essential SAFe contains the minimal set of roles, events, and artifacts required to continuously deliver business solutions via an Agile Release Train (ART) as a Team of Agile Teams.

Estimating Poker

Estimating Poker is a collaborative technique for relatively estimating the size of stories, features, and WSJF in SAFe.

Extreme Programming

Extreme Programming (XP) is a set of Agile software engineering practices that improves software quality and responsiveness to changing customer requirements developed primarily by Kent Beck.

A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).

Final Plan Review

In the Final Plan Review activity of PI planning, teams present the final plans (PI objectives, load, risks) for communication to the ART and acceptance by the Business Owners.

The Foundation contains the supporting principles, values, mindset, implementation guidance, and leadership roles needed to deliver value successfully at scale.

Full SAFe is the most comprehensive configuration, including all seven core competencies needed for business agility.

Gemba is the place where the work is performed and where teams can observe how stakeholders execute the steps and specific activities in their operational value streams to better identify opportunities for relentless improvement.

Hackathons are innovation events where team members can work on whatever they want, with whomever they want, so long as the work reflects the mission of the company and they demo their work to others at the end of the Hackathon.

Innovation and Planning Iteration

The Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

Inspect & Adapt (I&A)

The Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.

Integration Point

An Integration Point creates a ‘pull event’ that pulls the various solution elements into an integrated whole that helps stakeholders assure that the evolving solution address real and future business needs

Investment Horizons

Investment Horizons highlight spending allocations for solutions that are created by the value streams that help value stream owners and fiduciaries make more informed investment decisions and aligns the portfolio with strategic themes while promoting overall health and growth.

Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. In SAFe, iterations are typically one or two weeks in length, with two being the most common.

Iteration Execution

Iteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.

Iteration Goals

Iteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.

Iteration Planning

Iteration Planning is an event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes the work as a set of committed Iteration Goals.

Iteration Retrospective

The Iteration Retrospective is a regular event where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

Iteration Review

The Iteration Review is a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress, and then adjusts its backlog for the next iteration.

Knowledge Worker

Knowledge Workers are people who have the skill, expertise, and education needed to solve complex problems in their domain of concern.

Large Solution SAFe

Large Solution SAFe describes additional roles, practices, and guidance to build and evolve the world’s largest applications, networks, and cyber-physical systems.

Lead Time is the time it takes from when the work was done in the previous step until it’s done in the current step.

Lean is a body of knowledge and set of practices to improve efficiency and effectiveness by reducing delays and eliminating non-value-added activities.

Lean Budget Guardrails

Lean Budget Guardrails describe the policies and practices for budgeting, spending, and governance for a specific portfolio.

Lean Budgets

Lean Budgets is a Lean-Agile approach to financial governance which increases throughput and productivity by reducing the overhead and costs associated with project cost accounting.

Lean Business Case

A Lean Business Case (LBC) is a light-weight approach to describing epics, including their MVPs and projected business value.

Lean Governance

Lean Governance is one dimension of Lean Portfolio Management that supports oversight and decision-making of spending, audit and compliance, forecasting expenses, and measurement.

Lean Portfolio Management

The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.

Lean Quality Management System (QMS)

A Quality Management System (QMS) dictates practices, policies, and procedures needed to confirm safety and efficacy. SAFe organizations move from traditional to Lean QMS governance.

Lean User Experience (Lean UX)

Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.

Lean-Agile Center of Excellence

The Lean-Agile Center of Excellence (LACE) is a small team of people dedicated to implementing the SAFe Lean-Agile way of working.

Lean-Agile Leadership

The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential.

Lean-Agile Mindset

The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices.

Lean-Agile Principles

SAFe is based on ten immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe.

Little’s Law

Little’s Law is the law of queuing theory and states that the average wait time for service from a system equals the ratio of the average queue length divided by the average processing rate.

Measure and Grow

Measure and Grow is the way portfolios evaluate their progress towards business agility and determine their next improvement steps.

Metrics are agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, ART, and Agile team’s business and technical objectives.

Milestones are used to track progress toward a specific goal or event. There are three types of SAFe milestones: Program Increment (PI), fixed-date, and learning milestones.

Minimum Marketable Feature

The Minimum Marketable Feature (MMF) is the minimum functionality that the teams can build to learn whether the feature’s benefit hypothesis is valid or not.

Minimum Viable Product

In SAFe, a Minimum Viable Product (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 storyboards, prototypes, mockups, wireframes, and other exploratory techniques, the MVP is an actual product used by real customers to generate validated learning.

Model-Based Systems Engineering (MBSE)

Model-Based Systems Engineering (MBSE) is the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders, while significantly reducing or eliminating dependence on traditional documents.

Modified Fibonacci Sequence

A Modified Fibonacci Sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is used during relative estimating to reflect the inherent uncertainty as the size of the job being estimated gets bigger.

Nonfunctional Requirements (NFRs)

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.

Objectives and Key Results

In SAFe, Objectives and Key Results (OKRs) can be used to define, organize, and communicate critical information about a strategic theme and track its progress through concrete, specific, and measurable actions.

Operational Value Streams

Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service.

Organizational Agility

The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities.

Organizational Change Management

Organizational Change Management is a collective term for all approaches to prepare, support, and help individuals, teams, and organizations in making organizational change.

Pareto Analysis

Pareto Analysis is a technique used during an Inspect & Adapt event to narrow down the number of actions that produce the most significant overall effect.

Participatory Budgeting

Participatory Budgeting (PB) is the process that Lean Portfolio Management (LPM) uses to allocate the total portfolio budget to its value streams.

Personas are fictional consumers and/or users derived from customer research that drive a customer-centric approach to product development.

Phase Gates are traditional governance milestones that are replaced in SAFe by milestones based on objective evaluation of working systems.

PI Objectives

Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).

Plan-Do-Check-Adjust

Plan-Do-Check-Adjust (PDCA) is an iterative, four-step method used for controlling variability and making adjustments in response to feedback during product development.

A SAFe portfolio aligns strategy to execution via a collection of development value streams. Operating under a common governance model, each value stream provides one or more solutions the enterprise needs to accomplish its business mission.

Portfolio Backlog

The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.

Portfolio Canvas

The Portfolio Canvas defines the development value streams that are included in a SAFe portfolio, the value propositions and the solutions they deliver, the customers they serve, the budgets allocated to each value stream, and other key activities and events required to achieve the portfolio vision.

Portfolio Kanban

The Portfolio Kanban system is a method to visualize and manage the flow of portfolio Epics, from ideation through analysis, implementation, and completion.

Portfolio SAFe

Portfolio SAFe aligns strategy with execution and organizes solution development around the flow of value through one or more value streams.

Portfolio Vision

The Portfolio Vision is a description of the future state of a portfolio’s Value Streams and Solutions and describes how they will cooperate to achieve the portfolio’s objectives and the broader aim of the Enterprise.

Pre-and Post-PI Planning

Pre– and Post–Program Increment (PI) Planning events are used to prepare for, and follow up after, PI Planning for Agile Release Trains (ARTs) and Suppliers in a Solution Train.

Problem-Solving Workshop

The Problem Solving Workshop is part of the Inspect and Adapt (I&A) event and is a structured approach to finding the root cause of systemic problems.

Product Management

Product Management is responsible for defining desirable, viable, feasible, and sustainable solutions that meet customer needs and for supporting development across the entire product life cycle.

Product Owner (PO)

The Product Owner (PO) is a member of the Agile Team who is responsible for maximizing the value delivered by the team and ensuring that the Team Backlog is aligned with customer and stakeholder needs.

Product Owner (PO) Sync

The PO Sync is an ART event to get visibility into how well the ART is progressing toward meeting its PI objectives, to discuss problems or opportunities with feature development, and to assess any scope adjustments.

Program Backlog

The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.

Program Board

The Program Board highlights the PI’s feature delivery dates, feature dependencies among teams, and relevant milestones.

Program Increment (PI)

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increment (PI) Planning

Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.

Program Kanban

The Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.

Program Predictability Measure

The Program Predictability Measure summarizes the planned vs. actual business values for all the teams on the ART and is a key indicator of the ART’s performance and reliability.

Program Risks

Program Risks are identified by the teams during PI Planning and represent risks and impediments that could impact their ability to meet their objectives.

Refactoring

Refactoring is the activity of improving the internal structure or operation of a code or component without changing its external behavior.

Relative Estimation

Relative Estimation compares jobs to one another to quickly estimate their size and value.

To release is to make functionality that has been deployed to a production (or operational) environment available for use by a defined set of end-users or systems.

Release on Demand

Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand.

Release Train Engineer (RTE)

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Relentless Improvement

Relentless Improvement is the fourth pillar of the SAFe House of Lean and encourages learning and growth through continuous reflection and process enhancements.

The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon.

ROAMing Risks

Risk ROAMing is a PI planning activity where program risks raised by teams are addressed in a broader management context.

Root Cause Analysis

A Root Cause Analysis applies a set of problem-solving tools to identify the actual causes of a problem as part of the Inspect and Adapt event.

SAFe Big Picture (BP)

The SAFe Big Picture (BP) is a visual representation of the framework’s primary roles, activities, and artifacts used to access SAFe articles through its clickable icons when viewed from scaledagileframework.com

SAFe for Government

SAFe for Government is a set of success patterns that help public sector organizations implement Lean-Agile practices in a government context.

SAFe for Lean Enterprises

SAFe for Lean Enterprises is the world’s leading framework for business agility. SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality.

The SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe.

SAFe Lean Startup Cycle

The SAFe Lean Startup cycle is 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.

SAFe Program Consultants (SPCs)

Certified SAFe® Program Consultants (SPCs) are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. SPCs come from numerous internal or external roles, including business and technology leaders, portfolio/program/project managers, process leads, architects, analysts, and consultants.

Scrum Master

SAFe Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

Scrum of Scrums

The Scrum of Scrums (SoS) is an ART event that helps coordinate ART dependencies and provides visibility into progress and impediments.

SAFe ScrumXP is an Agile Team method used by Agile Release Trains (ARTs) to plan, execute, retrospect, and deliver customer value in a short time box. It combines the power of Scrum with Extreme Programming (XP) practices.

Set-Based Design

Set-Based Design (SBD) is a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.

Shared Services

Shared Services represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.

Silos are functionally-aligned organizational constructs that locally optimize for specialists with policies and procedures that ensure repeatable, efficient operations within the functional unit without understanding the larger flow of value across functional units.

Each development value stream develops one or more Solutions, which are products, services, or systems delivered to the customer, whether internal or external to the Enterprise.

Solution Architect/Engineering

Solution Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision across a Solution Train to help ensure the system or Solution under development is fit for its intended purpose.

Solution Backlog

The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Solution Context

Solution Context identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

Solution Demo

The Solution Demo integrates the development efforts from all ARTs and suppliers on the Solution Train every PI and makes them visible to Customers and other stakeholders for evaluation and feedback.

Solution Intent

Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, and functional and nonfunctional tests; and traceability.

Solution Management

Solution Management is responsible for defining and supporting the building of desirable, feasible, viable and sustainable large scale business solutions that meet customer needs over time.

Solution Train

The Solution Train is the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI).

Solution Train Engineer (STE)

The Solution Train Engineer (STE) is a servant leader and coach for the Solution Train, facilitating and guiding the work of all ARTs and Suppliers in the Value Stream.

Spanning Palette

The Spanning Palette contains various roles and artifacts that may apply to a specific team, program, large solution, or portfolio context.

A Spike is a type of exploration Enabler Story that gains the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

Sprint is a term that comes from the Scrum method and is synonymous with the term Iteration in SAFe.

Stories are short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration.

A Story Map is a design thinking technique that organizes a sequence of stories according to the tasks a user needs to accomplish their goal.

Story Point

A Story Point is a singular number used in relative estimating that represents a combination of quantities: volume, complexity, knowledge, and uncertainty.

Strategic Themes

Strategic Themes are differentiating business objectives that connect a portfolio to the strategy of the Enterprise. They influence portfolio strategy and provide business context for portfolio decision-making.

Sunk Costs refers to money already spent, which should be ignored when making future investment decisions to pivot effectively.

A Supplier is an internal or external organization that develops and delivers components, subsystems, or services that help Solution Trains and Agile Release Trains provide Solutions to their Customers.

SWOT Analysis

SWOT Analysis is a strategic planning technique used to identify strengths, weaknesses, opportunities, and threats related to the current business situation as part of a SAFe portfolio vision.

System Architect/Engineering

System Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.

System Demo

The System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).

System Team

The System Team is a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.

Systems Thinking

Systems Thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.

Team and Technical Agility

The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers.

Team Backlog

The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.

Team Kanban

Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

Team Topologies

Team Topologies define four organization types that provide a clear model for organizing Agile teams and ARTs.

Technical Debt

Technical Debt reflects the implied cost and accumulating interest of future work that is commonly caused by knowingly or unknowingly choosing a suboptimal or incomplete solution.

Test-Driven Development

Test-Driven Development (TDD) is a mindset and practice that involves building and executing tests before implementing the code or a component of a system.

TOWs Analysis

TOWS Analysis is used in conjunction with a SWOT analysis to help identify strategic options to create a better future state as part of a SAFe portfolio vision.

U-curve Optimization

The U-curve Optimization for batch size determines the optimal batch size by balancing transaction costs and holding costs.

Uncommitted Objectives

Uncommitted Objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictability measure. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective.

Value represents the benefits an enterprise delivers to its customers and stakeholders and appears in different contexts in SAFe.

Value Stream Coordination

Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams.

Value Stream Identification

Value Stream Identification is an activity that portfolios use to identify development value streams and the operational value streams they support.

Value Stream KPIs

Value Stream Key Performance Indicators (KPIs) are the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes.

Value Stream Management (VSM)

Value Stream Management is a leadership and technical discipline that enables maximum flow of business value through the end-to-end solution delivery life cycle.

Value Stream Mapping

Value Stream Mapping is an essential tool to improve the flow of value across the continuous delivery pipeline by providing the visibility needed to identify bottlenecks and problem areas to flow that cause delays.

Value Streams

Value Streams represent the series of steps that an organization uses to implement Solutions that provide a continuous flow of value to a customer.

Velocity is equal to the sum of the points for all the completed stories that met their Definition of Done (DoD).

The Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.

Weighted Shortest Job First (WSJF)

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (for example, Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by the job duration.

Work in Process

Work in Process (WIP) represents partially completed work. Having too much WIP confuses priorities, causes frequent context switching, and increases overhead.

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.

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.

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 at scale.

More partners templates View all

Aws architecture diagram.

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

1-on-1 meeting

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

Want to create or adapt books like this? Learn more about how Pressbooks supports open publishing practices.

5.5 Introduction to Hypothesis Tests

One job of a statistician is to make statistical inferences about populations based on samples taken from the population. Confidence intervals are one way to estimate a population parameter.

Another way to make a statistical inference is to make a decision about a parameter. For instance, a car dealership advertises that its new small truck gets 35 miles per gallon on average. A tutoring service claims that its method of tutoring helps 90% of its students get an A or a B. A company says that female managers in their company earn an average of $60,000 per year. A statistician may want to make a decision about or evaluate these claims. A hypothesis test can be used to do this.

A hypothesis test involves collecting data from a sample and evaluating the data. Then the statistician makes a decision as to whether or not there is sufficient evidence to reject the null hypothesis based upon analyses of the data.

In this section, you will conduct hypothesis tests on single means when the population standard deviation is known.

Hypothesis testing consists of two contradictory hypotheses or statements, a decision based on the data, and a conclusion. To perform a hypothesis test, a statistician will perform some variation of these steps:

• Define hypotheses.
• Collect and/or use the sample data to determine the correct distribution to use.
• Calculate test statistic.
• Make a decision.
• Write a conclusion.

Defining your hypotheses

The actual test begins by considering two hypotheses: the null hypothesis and the alternative hypothesis. These hypotheses contain opposing viewpoints.

The null hypothesis ( H 0 ) is often a statement of the accepted historical value or norm. This is your starting point that you must assume from the beginning in order to show an effect exists.

The alternative hypothesis ( H a ) is a claim about the population that is contradictory to H 0 and what we conclude when we reject H 0 .

Since the null and alternative hypotheses are contradictory, you must examine evidence to decide if you have enough evidence to reject the null hypothesis or not. The evidence is in the form of sample data.

After you have determined which hypothesis the sample supports, you make a decision . There are two options for a decision. They are “reject H 0 ” if the sample information favors the alternative hypothesis or “do not reject H 0 ” or “decline to reject H 0 ” if the sample information is insufficient to reject the null hypothesis.

The following table shows mathematical symbols used in H 0 and H a :

NOTE: H 0 always has a symbol with an equal in it. H a never has a symbol with an equal in it. The choice of symbol in the alternative hypothesis depends on the wording of the hypothesis test. Despite this, many researchers may use =, ≤, or ≥ in the null hypothesis. This practice is acceptable because our only decision is to reject or not reject the null hypothesis.

We want to test whether the mean GPA of students in American colleges is 2.0 (out of 4.0). The null hypothesis is: H 0 : μ = 2.0. What is the alternative hypothesis?

A medical trial is conducted to test whether or not a new medicine reduces cholesterol by 25%. State the null and alternative hypotheses.

Using the Sample to Test the Null Hypothesis

Once you have defined your hypotheses, the next step in the process is to collect sample data. In a classroom context, the data or summary statistics will usually be given to you.

Then you will have to determine the correct distribution to perform the hypothesis test, given the assumptions you are able to make about the situation. Right now, we are demonstrating these ideas in a test for a mean when the population standard deviation is known using the z distribution. We will see other scenarios in the future.

Calculating a Test Statistic

Next you will start evaluating the data. This begins with calculating your test statistic , which is a measure of the distance between what you observed and what you are assuming to be true. In this context, your test statistic, z ο , quantifies the number of standard deviations between the sample mean, x, and the population mean, µ . Calculating the test statistic is analogous to the previously discussed process of standardizing observations with z -scores:

where µ o   is the value assumed to be true in the null hypothesis.

Making a Decision

Once you have your test statistic, there are two methods to use it to make your decision:

• Critical value method (discussed further in later chapters)
• p -value method (our current focus)

p -Value Method

To find a p -value , we use the test statistic to calculate the actual probability of getting the test result. Formally, the p -value is the probability that, if the null hypothesis is true, the results from another randomly selected sample will be as extreme or more extreme as the results obtained from the given sample.

A large p -value calculated from the data indicates that we should not reject the null hypothesis. The smaller the p -value, the more unlikely the outcome and the stronger the evidence is against the null hypothesis. We would reject the null hypothesis if the evidence is strongly against it.

Draw a graph that shows the p -value. The hypothesis test is easier to perform if you use a graph because you see the problem more clearly.

Suppose a baker claims that his bread height is more than 15 cm on average. Several of his customers do not believe him. To persuade his customers that he is right, the baker decides to do a hypothesis test. He bakes ten loaves of bread. The mean height of the sample loaves is 17 cm. The baker knows from baking hundreds of loaves of bread that the standard deviation for the height is 0.5 cm and the distribution of heights is normal.

The null hypothesis could be H 0 : μ ≤ 15.

The alternate hypothesis is H a : μ > 15.

The words “is more than” calls for the use of the > symbol, so “ μ > 15″ goes into the alternate hypothesis. The null hypothesis must contradict the alternate hypothesis.

Suppose the null hypothesis is true (the mean height of the loaves is no more than 15 cm). Then, is the mean height (17 cm) calculated from the sample unexpectedly large? The hypothesis test works by asking how unlikely the sample mean would be if the null hypothesis were true. The graph shows how far out the sample mean is on the normal curve. The p -value is the probability that, if we were to take other samples, any other sample mean would fall at least as far out as 17 cm.

This means that the p -value is the probability that a sample mean is the same or greater than 17 cm when the population mean is, in fact, 15 cm. We can calculate this probability using the normal distribution for means.

A p -value of approximately zero tells us that it is highly unlikely that a loaf of bread rises no more than 15 cm on average. That is, almost 0% of all loaves of bread would be at least as high as 17 cm purely by CHANCE had the population mean height really been 15 cm. Because the outcome of 17 cm is so unlikely (meaning it is happening NOT by chance alone), we conclude that the evidence is strongly against the null hypothesis that the mean height would be at most 15 cm. There is sufficient evidence that the true mean height for the population of the baker’s loaves of bread is greater than 15 cm.

A normal distribution has a standard deviation of one. We want to verify a claim that the mean is greater than 12. A sample of 36 is taken with a sample mean of 12.5.

Find the p -value.

Decision and Conclusion

A systematic way to decide whether to reject or not reject the null hypothesis is to compare the p -value and a preset or preconceived α (also called a significance level ). A preset α is the probability of a type I error (rejecting the null hypothesis when the null hypothesis is true). It may or may not be given to you at the beginning of the problem. If there is no given preconceived α , then use α = 0.05.

When you make a decision to reject or not reject H 0 , do as follows:

• If α > p -value, reject H 0 . The results of the sample data are statistically significant . You can say there is sufficient evidence to conclude that H 0 is an incorrect belief and that the alternative hypothesis, H a , may be correct.
• If α ≤ p -value, fail to reject H 0 . The results of the sample data are not significant. There is not sufficient evidence to conclude that the alternative hypothesis, H a , may be correct.

After you make your decision, write a thoughtful conclusion in the context of the scenario incorporating the hypotheses.

NOTE: When you “do not reject H 0 ,” it does not mean that you should believe that H 0 is true. It simply means that the sample data have failed to provide sufficient evidence to cast serious doubt about the truthfulness of H o .

When using the p -value to evaluate a hypothesis test, the following rhymes can come in handy:

If the p -value is low, the null must go.

If the p -value is high, the null must fly.

This memory aid relates a p -value less than the established alpha (“the p -value is low”) as rejecting the null hypothesis and, likewise, relates a p -value higher than the established alpha (“the p -value is high”) as not rejecting the null hypothesis.

Fill in the blanks:

• Reject the null hypothesis when              .
• The results of the sample data             .
• Do not reject the null when hypothesis when             .

It’s a Boy Genetics Labs claim their procedures improve the chances of a boy being born. The results for a test of a single population proportion are as follows:

• H 0 : p = 0.50, H a : p > 0.50
• p -value = 0.025

Interpret the results and state a conclusion in simple, non-technical terms.

Click here for more multimedia resources, including podcasts, videos, lecture notes, and worked examples.

Figure References

Figure 5.11: Alora Griffiths (2019). dalmatian puppy near man in blue shorts kneeling. Unsplash license. https://unsplash.com/photos/7aRQZtLsvqw

Figure 5.13: Kindred Grey (2020). Bread height probability. CC BY-SA 4.0.

A decision-making procedure for determining whether sample evidence supports a hypothesis

The claim that is assumed to be true and is tested in a hypothesis test

A working hypothesis that is contradictory to the null hypothesis

A measure of the difference between observations and the hypothesized (or claimed) value

The probability that an event will occur, assuming the null hypothesis is true

Probability that a true null hypothesis will be rejected, also known as type I error and denoted by α

Finding sufficient evidence that the observed effect is not just due to variability, often from rejecting the null hypothesis

Significant Statistics Copyright © 2024 by John Morgan Russell, OpenStaxCollege, OpenIntro is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License , except where otherwise noted.

Share This Book