purpose of 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

Kristina Suchan

• Jul 23, 2023

E like Epic: Mastering Portfolio Epic Statements in SAFe

In the world of Agile and Lean Portfolio Management, the Portfolio Epic Statement holds a significant role. It encapsulates essential information about a Portfolio Epic in the Scaled Agile Framework (SAFe), providing clarity, alignment, and strategic direction. In this blog post, we'll delve into the details of Portfolio Epic Statements, exploring why they are crucial, what information they encompass, the timeframe of portfolio epics, and the benefits they bring to organizations.

Defining the Portfolio Epic Statement

A Portfolio Epic Statement is a concise and comprehensive description that captures the essence of a significant solution development initiative within a portfolio. It serves as a guiding document that aligns stakeholders and teams, ensuring a shared understanding of the epic's purpose, objectives, and desired outcomes. The Portfolio Epic Statement acts as a focal point for decision-making, prioritization, and ongoing collaboration throughout the epic's lifecycle.

Key Information Included in the Portfolio Epic Statement

Epic Summary: A brief overview of the epic, highlighting its purpose, business value, and strategic alignment. This section provides a snapshot of the epic's significance and its potential impact on the organization.

Business Objectives: Clearly defined business objectives articulate the desired outcomes and benefits expected from the epic. These objectives align with the organization's strategic goals and serve as a guiding compass for solution development.

Hypothesis Statement: The epic hypothesis outlines the assumptions and expectations associated with the epic's success. It serves as the foundation for the Minimum Viable Product (MVP) and guides the validation process throughout the epic's implementation.

Target Customers and User Segments: Identifying the target customers and user segments helps focus the solution development efforts and ensures the epic addresses the specific needs of the intended audience.

Success Criteria: Defining measurable success criteria allows stakeholders to evaluate the epic's impact and determine its effectiveness. These criteria provide clear benchmarks for assessing the epic's progress and validating its outcomes.

Timeframe of the Portfolio Epic

A portfolio epic operates within a defined timeframe, typically spanning multiple Program Increments (PIs) in SAFe. The specific duration may vary based on the complexity and scope of the epic. The timeframe provides a strategic planning horizon, enabling organizations to allocate resources, establish milestones, and monitor progress effectively.

Every portfolio epic has an assigned Epic Owner who takes responsibility for its successful delivery. The Epic Owner acts as the primary advocate for the epic, collaborating with Product and Solution Management, System Architects, and other stakeholders. They drive the epic's implementation, coordinate backlog refinement, and prioritize the development of features and capabilities.

Benefits of Portfolio Epic Statements

Alignment and Clarity: The Portfolio Epic Statement brings stakeholders and teams together, ensuring a shared understanding of the epic's purpose, objectives, and expected outcomes. It aligns the organization's efforts towards a common goal, reducing ambiguity and improving collaboration.

Strategic Direction: By articulating the epic's business objectives and alignment with strategic goals, the Portfolio Epic Statement provides a clear direction for solution development. It helps prioritize initiatives, allocate resources effectively, and make informed decisions throughout the epic's lifecycle.

Risk Mitigation: The hypothesis statement within the Portfolio Epic Statement guides the validation process, reducing the risk of investing in solutions that may not meet customer needs. It promotes an iterative and data-driven approach, enabling organizations to learn, adapt, and make course corrections as necessary.

Stakeholder Engagement: The Portfolio Epic Statement serves as a powerful communication tool, engaging stakeholders at all levels of the organization. It facilitates transparency, fosters collaboration, and encourages active participation in the epic's definition, planning, and execution.

Portfolio Epic Statements play a crucial role in the SAFe methodology, providing a clear and concise description of significant solution development initiatives within a portfolio. By capturing essential information, defining business objectives, and guiding the hypothesis-driven approach, these statements empower organizations to deliver value-driven solutions, mitigate risks, and align efforts strategically. Embrace the power of Portfolio Epic Statements and unlock the full potential of your Lean Portfolio Management endeavors.

Ready to master the art of Lean Portfolio Management? Explore our comprehensive training courses and resources to enhance your SAFe knowledge and skills. Don't miss out on driving impactful business value with well-defined Portfolio Epic Statements. Check out our book, "Mastering the Art of Lean Portfolio Management with SAFe ," and start your journey today.

• Lean Portfolio Management Lexicon

Recent Posts

Mastering Portfolio Epics: How to Drive Business Success with SAFe

What Is Portfolio Kanban System and Why Is It Important?

How to Measure the Success of Your Lean Portfolio Management Implementation

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

7 Keys To Being A Leader In Agile Environment 

Why Bug/Defect Triage is Important in Software Testing

Agile Metrics: 5 Tips to Achieve Product Success

How to Establish an Agile Finance Team

agility at scale

• Team and Technical Agility Assessment Service
• Agile Product Delivery Assessment Service
• Case Studies
• Agile Leadership
• Agile Planning
• Agile Practices
• Agile Requirements Management
• Distributed Teams
• Large Scale Scrum (LeSS)
• Lean and Agile Principles
• Organizational Culture
• Scaled Agile Framework (SAFe)
• Scaling Agile

Implementing SAFe: Portfolio Kanban

Table of Contents

The SAFe Portfolio Kanban

SAFe Portfolio Kanban is a method for visualizing and managing the flow of portfolio Epics, aligning strategy and execution in SAFe.

In SAFe, Portfolio Kanban is a crucial tool for managing the flow of portfolio Epics, guiding them from ideation to analysis, implementation, and completion. It’s part of the larger SAFe framework, which encompasses various Kanban systems at different levels, such as team, program, solution, and portfolio Kanban systems. Each of these systems plays a role in enhancing the flow of value through the Continuous Delivery Pipeline.

Portfolio Kanban is vital because it aids in aligning strategic goals with execution by identifying, communicating, and governing the selection of the most significant and strategic initiatives, known as Epics, within a SAFe portfolio. This alignment is crucial for the overall success of the organization.

In essence, SAFe Portfolio Kanban is a structured approach that defines the stages or ‘states’ an Epic progresses through from its inception to its ultimate completion. It provides visibility and control over these strategic initiatives, ensuring they are executed in alignment with the organization’s strategic goals.

Who is responsible for managing the Portfolio Kanban?

Lean Portfolio Management manages the Portfolio Kanban in the SAFe framework.

Within the Scaled Agile Framework (SAFe), Portfolio Kanban’s responsibility falls under the Lean Portfolio Management (LPM) purview. LPM focuses on aligning an organization’s strategy with its execution by overseeing the flow of work in the portfolio.

There are 5 key stakeholder groups in Agile Portfolio Operations, and they are:

• Value Management Office (VMO) : This group ensures value delivery and alignment with the organization’s strategic objectives.
• Lean Agile Center of Excellence (LACE):  The LACE promotes and supports adopting Agile practices, tools, and culture across the organization.
• Release Train Engineer (RTE):  The RTE facilitates and supports the work of ARTs and Solution Trains, ensuring alignment and effective execution of initiatives.
• Scrum Master/Team Coach : provide coaching and support to individual teams, helping them adopt and adhere to Agile principles and practices.

LPM is responsible for ensuring that the Portfolio Kanban system is effectively used to visualize and manage the flow of portfolio Epics. They play a central role in identifying, communicating, and governing the selection of the most significant and strategic initiatives (Epics) within a SAFe portfolio.

LPM also utilizes strategic portfolio review and portfolio sync events as crucial mechanisms for managing and monitoring the work flow within the portfolio. These events help ensure that the organization’s strategic objectives are met through the proper execution of Epics.

In summary, Lean Portfolio Management is the designated entity responsible for managing the Portfolio Kanban system within SAFe, making it a critical component of aligning strategy and execution in agile enterprises.

How do you use Lean Portfolio Kanban to manage the portfolio backlog?

The Portfolio Kanban creates a visual workflow for Business Epics and Enablers. It enables tracking Epic’s progress and identifying process bottlenecks or areas for enhancement.

The six key elements of managing the Portfolio Backlog with Lean Portfolio Kanban are listed below:

• The Portfolio Kanban system provides a visual representation of the progress of Business Epics and Enablers , making it easy to track their status and identify bottlenecks or opportunities for improvement.
• Epic Owners are responsible for the essential collaborations to manage Epics within the Portfolio Kanban system. They ensure that Epics are effectively developed, prioritized, and moved through the process.
• Enterprise Architects guide Enabler Epics , which supports the technical considerations for Business Epics . Their expertise ensures that the organization’s technical infrastructure aligns with its strategic goals.
• The Portfolio Kanban system helps to align strategy and execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (Epics) for a Lean Portfolio.
• Lean Portfolio Management (LPM) oversees the Portfolio Kanban , ensuring that it is effectively used to manage and monitor the flow of Epics within the organization.
• Strategic Portfolio Review and Portfolio Sync Events : The Portfolio Kanban system is often used during these events to facilitate discussions around Epics’ prioritization, selection, and progress. This helps to maintain alignment between the organization’s strategy and the initiatives in the portfolio.

The SAFe Portfolio Backlog

The SAFe Portfolio Backlog is a vital component in managing the strategic direction of an organization’s portfolio. It is a dynamic repository for business and enabler epics to enhance the portfolio’s products, services, and solutions.

Key features of the SAFe Portfolio Backlog:

• Strategic Alignment : The Portfolio Backlog plays a pivotal role in ensuring that the work at the portfolio level aligns with the organization’s overall strategic objectives. It captures the high-level initiatives, known as epics, crucial for achieving strategic goals.
• Epics Management : Within the Portfolio Backlog, epics are categorized and prioritized based on their strategic importance and business value. This process ensures that resources are allocated to the most critical initiatives directly contributing to the portfolio’s success.
• Visibility and Transparency : The Portfolio Backlog provides a clear and transparent view of all the epics under consideration for implementation. This visibility helps stakeholders, including executives, decide which initiatives to pursue and when.
• Continuous Prioritization : Epics in the Portfolio Backlog are subject to constant prioritization based on changing market conditions, customer feedback, and evolving business priorities. This adaptability is essential in the fast-paced world of business.
• Collaboration : Cross-functional teams collaborate to refine and elaborate on the epics in the Portfolio Backlog. This collaboration fosters a shared understanding of the work and ensures that it aligns with the organization’s objectives.
• Dependencies Management : The Portfolio Backlog also highlights dependencies among various epics. Identifying and managing these dependencies is critical to avoiding bottlenecks and delays in executing strategic initiatives.
• Capacity Planning : Organizations can effectively plan and allocate resources to work on epics by maintaining a well-organized Portfolio Backlog. This prevents overloading teams and optimizes the utilization of available resources.
• Flow of Value : Ultimately, the Portfolio Backlog feeds into the SAFe Portfolio Kanban system, where work is visualized and managed at a higher level. It ensures that epics flow smoothly through the various stages of implementation, from ideation to delivery, thereby delivering value to customers.

Building and Refining the Portfolio Backlog

Building and refining the portfolio backlog in SAFe involves identifying, describing, and prioritizing epics.

The construction and refinement of the portfolio backlog is a continuous process that starts with identifying potential epics. Stakeholders across the organization propose new ideas, which are then captured as epics and entered into the funnel stage of the Portfolio Kanban system. Each epic is then elaborated upon, capturing its intent and business value. Refining involves analyzing these epics for their strategic alignment and financial feasibility. It includes go/no-go decisions made during the review phase. Epics that align with the organization’s strategic themes and provide substantial value are prioritized and moved into the portfolio backlog, where they await implementation.

There are eight steps involved in refining the Portfolio Backlog, and they are:

• Strategic Review:  This is where the organization’s strategic themes, budgets, and business context are reviewed to ensure the portfolio backlog items align with them. This step also considers changes in market trends, technology, and other factors that might impact the direction of the initiatives in the portfolio backlog.
• Identify Epics: The epics are high-level initiatives that will drive the portfolio’s work. They are typically broad in scope, cross multiple teams or programs, and take a long time to implement. Key stakeholders identify the epics, including business owners, product managers, system architects, and others.
• Review and Prioritize Epics:  After the epics have been identified, they are then reviewed and prioritized based on the organization’s strategic goals, the value they deliver, and the costs and risks associated with them. The Weighted Shortest Job First (WSJF) method prioritizes epics in SAFe.
• Analyze Epics:  Each epic is analyzed in detail to determine its potential impact, feasibility, and estimated cost. This analysis helps determine whether the epic should proceed to the portfolio backlog or be discontinued.
• Define Epic Hypothesis: An epic hypothesis statement is created for each epic still under consideration after the analysis. This statement provides a high-level description of the epic, including its purpose, the value it will deliver, and the metrics used to measure its success.
• Lean Business Case: For each epic, a Lean Business Case is developed to elaborate further on the business need, the potential solutions, the estimated cost, the expected benefits, and the associated risks. This helps the stakeholders decide whether to proceed with the epic.
• Approval and Implementation: The portfolio stakeholders implement the Epic based on the lean business case. If approved, the epic is added to the portfolio backlog, broken down into features or capabilities, and then pulled into the Program or Solution Backlogs for implementation.
• Review and Adjust:  The portfolio backlog is continuously reviewed and adjusted as new information or conditions change. This could include adding new epics, removing or reprioritizing existing ones, or adjusting the epics’ scope based on implementation feedback.

What are Portfolio Epics?

Portfolio Epics are significant strategic initiatives within the SAFe framework that represent large-scale business objectives and are managed through the Portfolio Kanban system.

Portfolio Epics are substantial endeavors within an organization’s SAFe portfolio. They are not typical day-to-day work but represent significant strategic initiatives and objectives crucial for achieving the organization’s long-term goals. These Epics are often characterized by their complexity, impact, and strategic importance.

In the Portfolio Kanban system context, these Epics are visualized and managed as they progress from the initial idea stage through analysis, development, and, ultimately, approval or rejection. Before an Epic is committed to implementation, it undergoes a thorough analysis and approval process.

Responsibility for these Portfolio Epics is divided among Epic Owners and Enterprise Architects. Epic Owners focus on the essential collaborations required for business Epics, while Enterprise Architects guide the enabler Epics, which supports the technical aspects of the business Epics.

The Portfolio Kanban system is instrumental in managing these Epics, helping to align an organization’s strategy with execution. It identifies, communicates, and governs the selection of the most significant and most strategic initiatives (Epics) within the SAFe portfolio.

Lean Portfolio Management (LPM) oversees the Portfolio Kanban and ensures that Epics are aligned with the portfolio’s strategic themes, vision, and economic framework. LPM plays a key role in facilitating the flow of Epics and making informed decisions about which initiatives to pursue.

Achieving a better future state in the SAFe framework involves Development Value Streams adopting a ‘one-portfolio’ mindset, where they collaborate to achieve the portfolio’s higher-level objectives and the broader enterprise goals. This collaboration is essential for successful portfolio management.

Managing The Portfolio Backlog with Kanban

Managing the Portfolio Backlog with Kanban involves visualizing and controlling the flow of business epics and enablers within the SAFe framework.

In SAFe, the Portfolio Kanban system is a powerful tool for managing the portfolio backlog, which consists of significant initiatives known as portfolio epics. These epics represent strategic objectives and are taken from the initial idea stage through various process states until either approved for implementation or rejected.

Before an epic is committed to implementation, it undergoes a crucial phase of analysis and approval. This process is orchestrated by Epic Owners, individuals responsible for essential collaborations required for business epics. Additionally, Enterprise Architects play a role in guiding enabler epics, which support the technical considerations of business epics.

One of the challenges organizations face is a lack of rigor in managing their portfolio backlog, leading to less critical efforts continuing. At the same time, potentially more valuable initiatives are delayed or starved of resources. Choosing the best ideas is insufficient to advance the portfolio; it demands a purposeful journey.

Lean Portfolio Management (LPM) plays a pivotal role in this process. LPM and stakeholders identify specific epics aligned with the portfolio’s vision. The Portfolio Kanban system facilitates the alignment of strategy and execution by identifying, communicating, and governing the selection of the most strategic initiatives (epics) for the SAFe portfolio.

While opportunistic epics are considered, LPM has a fiduciary responsibility to ensure the flow of epics that best align with the portfolio’s strategic themes, vision, and economic framework. Achieving a better future state involves “Development Value Streams” adopting a ‘one-portfolio’ mindset, collaborating to achieve higher-level objectives and broader enterprise goals.

The figure below illustrates the epic’s journey through the Portfolio Kanban system, from the Funnel stage to completion. The Reviewing, Analyzing, and Ready states have explicit Work in Process (WIP) limits. In contrast, the MVP sub-state has an implicit WIP limit based on available capacity and value stream budgets.

The design of the Kanban system should evolve to meet the specific needs of a portfolio, incorporating continuous improvements. These enhancements may involve adjusting WIP limits, reconfiguring Kanban states, or introducing classes of service to optimize the flow and priority of epics, ensuring the portfolio backlog is effectively managed.

Portfolio Kanban States

The subsequent section describes the default states within the portfolio Kanban. It’s crucial to emphasize that these states serve as an illustrative process. The Kanban’s configuration may adapt over time, incorporating enhancements drawn from practical portfolio insights. Such enhancements might encompass modifications to Work in Process (WIP) limits, partitioning or consolidating Kanban states or integrating service categories to enhance the management of epic flow and prioritization.

The “Funnel” Kanban state is an intake stage for significant business and technology ideas within a specific portfolio. These ideas can originate from various sources, including strategic considerations, Agile Teams or Agile Release Trains (ARTs), or suggestions from customers and partners. The primary purpose of this state is to capture ideas that are expected to be substantial, potentially exceeding the epic threshold guardrail or significantly impacting the portfolio’s strategic or business model.

Epics entering the Funnel are initially described in the form of an Epic Hypothesis Statement. Unlike other Kanban states, the Funnel does not have Work in Process (WIP) limits because it functions as a repository for these initial ideas, which may or may not progress further in the portfolio management process. These ideas are essentially candidates for consideration.

If, upon an initial review, it is determined that an idea is unlikely to exceed the epic threshold guardrail or isn’t a significant portfolio concern, it may be moved to the Kanban of the Agile Release Train (ART) or Solution Train, as it may be more relevant at that level.

Initiatives that contribute to the portfolio’s vision and roadmap, including updates from the enterprise strategy or other portfolios, are identified and fed directly into the Kanban portfolio, which includes the Funnel. Additionally, the Continuous Exploration process plays a role in discovering user and market needs, often identifying epics that are then considered within the Funnel state.

During the “Reviewing” state, “Epics,” which are significant enterprise investments, are evaluated and refined. During this state, an Epic Owner takes responsibility for the epic and its definition.

In the “Reviewing” state, the primary focus is on defining the intent and purpose of the epic. The Epic Owner collaborates with relevant stakeholders to develop a comprehensive Epic Hypothesis Statement, which includes four main components:

• Epic Description: This structured portion provides a high-level description of the epic in general terms, helping stakeholders understand its scope and purpose.
• Business Outcome Hypothesis: This component outlines the anticipated quantitative or qualitative benefits that will be realized if the hypothesis behind the epic is proven true.
• Leading Indicators: Early measures are identified during this stage, which can help predict the potential business outcomes of the epic. These indicators are crucial for tracking progress and success.
• Nonfunctional Requirements (NFRs): Attributes such as security, reliability, performance, maintainability, scalability, and usability are defined as constraints or restrictions for the epic.

Additionally, in the “Reviewing” state, Work in Progress (WIP) limits may be specified, indicating the maximum number of epics allowed in this state simultaneously. If there is no available Epic Owner to work on the epic, it effectively serves as an implicit WIP limit, preventing unnecessary backlog buildup.

The “Reviewing” state also involves establishing preliminary size and cost estimates for the epic. This information calculates the Weighted Shortest Job First (WSJF) estimate, which helps prioritize the epic relative to other items in the reviewing state.

Finally, the epic undergoes review as part of the regular portfolio synchronization agenda. If there is sufficient knowledge and consensus that the epic is ready for further analysis and development, it may be approved to progress to the “Analyzing” state. However, if the epic does not appear viable or aligned with the portfolio’s strategic themes or guardrails, it is moved to the “Done” state. This decision frees up capacity for more promising alternatives within the portfolio.

During the “Analyzing” Kanban, promising Epics undergo in-depth evaluation and analysis to determine their viability and potential for further investment.

Several vital roles collaborate actively during the “Analyzing” state, including Business Owners, Enterprise Architects, System and Solution Architects, Product and Solution Management, and Agile Teams. This collaboration is essential to ensure a comprehensive assessment of the epic.

Key activities that typically occur during the “Analyzing” state include:

• Identification and Review of Solution Alternatives: Various potential solutions or approaches are identified and thoroughly reviewed to determine the most suitable path for the epic.
• Defining the Minimum Viable Product (MVP): The core features and functionalities required for the MVP are described, clearly understanding what needs to be developed initially.
• Establishing Refined Cost Estimates: Precise cost estimates are calculated not only for the MVP but also for the full scope of the epic, allowing for better financial planning.
• Creating the Lean Business Case: A Lean Business Case is developed, outlining the rationale, expected benefits, and financial aspects of the epic. This document plays a crucial role in decision-making.
• Small Research Spikes: Research spikes are conducted to assess the technical and business viability of the epic. These spikes provide valuable insights into the feasibility of the proposed solutions.
• Initial Customer Validation: Early validation with potential customers or stakeholders is carried out to gather feedback and ensure alignment with their needs and expectations.
• Updating WSJF (Weighted Shortest Job First): The WSJF of the epic is recalculated concerning other epics in the “Analyzing” state. This helps in prioritizing and sequencing work effectively.

The decision-making process in the “Analyzing” state is more rigorous. The Lean Business Case and WSJF are used as a basis for the ‘Go/No-go’ decision by the Lean Portfolio Management (LPM). A ‘Go’ decision indicates that the epic is approved for implementation and will be sequenced using WSJF. In contrast, a ‘No-go’ decision moves the epic to the “Done” state, signaling it won’t proceed.

Typically, only a limited number of epics are in the “Analyzing” state at any given time and are subject to regular review by LPM. Since initiating and implementing an epic consumes valuable capacity, careful evaluation and alignment with strategic objectives are essential before progressing to the next stage. Additional considerations beyond WSJF, such as the Lean Business Case, are considered to make informed decisions. During portfolio synchronization meetings, LPM makes the final determination, ensuring that the Epics selected for implementation align with the organization’s goals and priorities.

Epics in the Analyzing state with the highest priority are pulled into the Ready state as soon as space is available. This is a low-cost wait state where Epics are periodically reviewed and prioritized by updating WSJF and other relevant factors.

Implementing

In SAFe Portfolio Kanban, the “Implementing” state represents the phase where epics are actively worked on by Agile Release Trains (ARTs) and Solution Trains for development. This phase involves breaking Epics into features and capabilities, pulling them into backlogs, and initiating Epic’s Minimum Viable Product (MVP) development.

The “Implementing” Kanban state in SAFe Portfolio Kanban signifies the execution phase of Epics within the framework. At this stage, the focus is on turning high-priority epics into tangible deliverables. Here’s a breakdown of what happens during this state:

• Epic Decomposition : The Epic Owner collaborates with various stakeholders to dissect the epic into smaller, manageable components known as Features and Capabilities. This decomposition process ensures that the epic’s objectives are translated into actionable work items.
• Backlog Inclusion : The features and capabilities resulting from the decomposition are then included in the backlogs of the responsible Agile Release Trains (ARTs) and Solution Trains. These backlogs serve as the prioritized lists of work items to be tackled.
• MVP Development : The primary goal during the “Implementing” state is to initiate the development of the Minimum Viable Product (MVP) associated with the epic. The MVP represents the core features and functionalities that will provide value to customers and users.
• Progress Monitoring : Throughout this phase, Lean Portfolio Management (LPM) closely monitors the progress of the MVP. This monitoring involves tracking leading indicators, Value Stream Key Performance Indicators (KPIs), and conducting demonstrations to assess the MVP’s business outcome hypothesis.
• Resource Allocation : It’s crucial to understand the available capacity within the ARTs, as the prioritization and sequencing of work are influenced by it. The Weighted Shortest Job First (WSJF) prioritization method is often used to decide which epics should advance to the MVP state based on capacity and value.
• Budget Considerations : The allocation of funds for the MVP is closely managed. The work on the MVP continues until the allocated budget has been expended or until the hypothesis associated with the MVP can be effectively evaluated.
• Adaptability : SAFe emphasizes adaptability, and organizations can adjust these rules and processes to suit their specific needs. Flexibility is essential to ensure that the framework aligns with the unique context and goals of the organization.

Implementing: MVP

In SAFe Portfolio Kanban, the “MVP” sub-state is a crucial phase within the “Implementing” Kanban state. It’s where Epics with the highest Weighted Shortest Job First (WSJF) advance to develop the Minimum Viable Product (MVP). The Epic Owner collaborates with Agile Teams during this sub-state to work on the MVP and evaluate its business outcome hypothesis.

The “MVP” sub-state encompasses the following key aspects:

• WSJF Prioritization : Epics that have the highest WSJF, which considers factors like value, time criticality, risk reduction, and opportunity enablement, are selected to move into the “MVP” sub-state. This prioritization ensures that the most valuable and time-sensitive work receives immediate attention.
• Epic Owner’s Role : The Epic Owner leads during the “MVP” sub-state. They collaborate closely with Agile Teams, which are responsible for implementation. Their primary tasks include overseeing the activities needed to develop the Minimum Viable Product and assessing the business outcome hypothesis associated with it.
• MVP Development : Work during this sub-state is focused on developing the Minimum Viable Product. The MVP represents the minimal features and capabilities that can be deployed to provide value to customers and users. It serves as a crucial step toward delivering the epic’s intended benefits.
• Budget Management : The work on the MVP continues until the allocated budget has been exhausted or until the hypothesis can be effectively evaluated. Budget management is a critical aspect of this sub-state to ensure that resources are optimally utilized.
• Adaptability : As with other aspects of SAFe, organizations can adapt the rules and processes of the “MVP” sub-state to align with their specific needs and circumstances. Adaptability allows organizations to tailor SAFe to their unique context.

Implementing: Persevere

In SAFe Portfolio Kanban, the “Persevere” sub-state is where epics advance if their associated business outcome hypothesis is proven true during the “MVP” sub-state. In this phase, teams continue implementing additional features and capabilities, with Agile Release Trains (ARTs) managing ongoing feature prioritization in various value streams.

The “Persevere” sub-state involves the following key elements:

• Hypothesis Validation : Epics that successfully validate their business outcome hypothesis during the “MVP” sub-state progress to the “Persevere” sub-state. This means that the MVP delivered the expected value and outcomes.
• Continuous Development : In the “Persevere” sub-state, teams continue to work on the epic by implementing additional features and capabilities. These enhancements contribute to the ongoing development and evolution of the epic.
• ART Responsibility : Agile Release Trains (ARTs) take on the responsibility of managing the ongoing prioritization of features within various value streams. This prioritization ensures that the most valuable work is continually addressed.
• “Done Enough” State : The goal in the “Persevere” sub-state is to reach a state where the epic is considered “done enough” to meet the needs and objectives. This means the Epic has delivered sufficient value and functionality to fulfill its intended purpose.
• WSJF Adaptation : Over time, as the epic matures in the “Persevere” sub-state, the WSJF prioritization may shift to prioritize new capabilities and features from other sources as higher priorities. This adaptive approach ensures that the portfolio remains aligned with changing business needs.
• Epic Owner’s Role : Epic Owners remain available to assist Agile Release Trains (ARTs) and Solution Trains responsible for implementation. Their involvement helps ensure that the epic continues to deliver value and meets evolving business requirements.
• Flexibility : SAFe allows organizations to adapt and tailor the “Persevere” sub-state to their specific needs and evolving contexts. This adaptability is a fundamental aspect of the SAFe framework, allowing organizations to optimize their Agile practices.

In SAFe Portfolio Kanban, an Epic’s “Done” state signifies that it is no longer a portfolio concern. It can occur when certain conditions are met, such as ejection from the portfolio kanban, MVP results, or no need for additional portfolio governance.

The “Done” Kanban state in SAFe Portfolio Kanban is a significant milestone that indicates the status of an Epic from a portfolio perspective. It is essential to understand that achieving Epic’s “Done” state does not necessarily mean completing the entire scope outlined in the Lean business case. Instead, an Epic is considered “Done” when one of the following conditions is met:

• Ejection from Portfolio Kanban : An Epic can be considered “Done” if it is removed or ejected from the portfolio kanban by Lean Portfolio Management (LPM) at any of the earlier states within the kanban workflow. This may occur due to strategic shifts, changing priorities, or other reasons that make the Epic no longer relevant to the portfolio.
• MVP Disproves the Hypothesis : If the Minimum Viable Product (MVP) developed for the epic disproves the original business outcome hypothesis, the Epic can be considered “Done.” This means that the expected value or outcomes were not achieved, and further investment in the epic may not be justified.
• Hypothesis Proven, No Governance Needed : In cases where the hypothesis associated with the epic is proven to be true, LPM may determine that additional portfolio governance is no longer required. This decision may be based on the epic’s successful outcomes and alignment with portfolio objectives.

In scenarios where the epic reaches the “Done” state, it may still have some ongoing activities or responsibilities. Various Agile Release Trains (ARTs) may continue working on the epic, and the Epic Owner may be tasked with stewardship and follow-up. However, the epic itself is no longer a primary portfolio concern.

To keep LPM informed of the epic’s progress and outcomes, leading indicators, Value Stream Key Performance Indicators (KPIs), and Guardrails are utilized. These metrics help ensure that the portfolio remains aware of the epic’s status and any potential impacts on the overall portfolio strategy and goals.

Setting up a Portfolio Kanban Board

Define columns and swimlanes.

In SAFe Agile, setting up a Portfolio Kanban Board begins with defining columns and swimlanes. Columns represent different stages of the portfolio management process, like “Backlog,” “In Progress,” “Review,” and “Done.” Swimlanes to categorize different initiatives, epics, or portfolios, providing a visual separation and organization of work items.

Identify Work Item Types

The next step is to define the work items that will be managed on the board, such as initiatives, epics, and features. Each work item type should have clearly defined criteria, including its purpose, size, and priority. This clarity ensures that all stakeholders have a common understanding of the portfolio components.

Establish WIP Limits

Setting Work in Progress (WIP) limits for each column is crucial to prevent overloading and optimize flow. WIP limits control the amount of work initiated, focusing the team on completing work items efficiently. This approach prevents bottlenecks and maintains a steady, manageable workflow.

Add Metrics and Visualizations

Incorporating relevant metrics and visualizations on the Kanban board, like cycle time, lead time, and cumulative flow diagrams, is essential. These metrics provide insights into the performance of the portfolio management process. They help teams to identify areas for improvement and make data-driven decisions.

Facilitate Collaborative Decision-Making

The final step is encouraging collaborative decision-making by involving all relevant stakeholders in the Portfolio Kanban board. This inclusivity ensures the alignment of the portfolio management process with the organization’s strategic goals. It enables effective prioritization and resource allocation, fostering a unified approach to portfolio management.

Implementing SAFe Portfolio Kanban

Define portfolio-level policies.

The first step in implementing SAFe Portfolio Kanban is to define portfolio-level policies. This foundational action involves creating clear guidelines for managing the portfolio Kanban board. It encompasses setting criteria for initiating, prioritizing, and managing work items at the portfolio level. Additionally, it involves establishing roles and responsibilities for stakeholders, ensuring a structured approach to portfolio management.

Populate Portfolio Kanban Board

Once policies are set, the next step is populating the Portfolio Kanban board with relevant work items. This action aligns the board with the organization’s strategic goals and priorities. It’s essential to ensure work items are accurately represented on the board, with detailed descriptions, dependencies, and deadlines. This step effectively visualizes the organization’s strategic initiatives and promotes efficient workflow management.

Monitor and Manage Workflow

Continuous monitoring and managing the Portfolio Kanban board workflow are crucial. This involves tracking the progress of work items, updating their status, and managing dependencies and blockers in real-time. Utilizing metrics and visualizations on the Kanban board, such as cycle time and cumulative flow diagrams, is key to identifying bottlenecks, risks, and areas for improvement.

Collaboration and Decision-Making

Encouraging collaboration among stakeholders and facilitating decision-making at the portfolio level is essential for effective Portfolio Kanban implementation. The Kanban board is a visual aid for discussions, reviews, and prioritization sessions. Regular portfolio reviews are crucial for evaluating progress, ensuring alignment with strategic goals, and making informed decisions.

Continuous Improvement

The final step in implementing SAFe Portfolio Kanban is fostering a continuous improvement culture. Regularly reviewing and refining the Portfolio Kanban board and associated policies is vital. Encouraging stakeholder feedback and utilizing it to identify opportunities for optimization and innovation in the portfolio management process drives ongoing enhancements and adaptability.

How does the Portfolio Backlog feed into PI Planning?

The Portfolio Backlog feeds into PI Planning by providing the prioritized Epics, broken down into Features and User Stories, forming the basis of work for the Agile Release Trains during the upcoming Program Increment.

This key event has four critical intersections with the portfolio backlog:

• PI Planning and Portfolio Backlog Prioritization : PI Planning helps Agile teams to understand and prioritize the most important work items in the portfolio backlog. The event allows for discussion and understanding of business goals, thus enabling teams to align their work items with these strategic objectives.
• Refinement of Epics through PI Planning : During PI Planning, teams can refine and break down epics into features and user stories, providing additional details to the portfolio backlog. This results in a more effective implementation of the epics.
• Visualizing PI Objectives in the Lean Portfolio Kanban : The PI Planning outputs, particularly the PI Objectives, can be visualized and tracked in the Lean Portfolio Kanban. This provides transparency into the progress of work across the organization.
• Feedback Loop and Continuous Learning : PI Planning also serves as a feedback mechanism, allowing teams to learn and adapt their strategies based on the results of the previous PI. This feedback can then update and refine the portfolio backlog, leading to a more effective and efficient workflow.

What are the SAFe Core Competencies?

SAFe Core Competencies are a set of seven capabilities essential for achieving Business Agility.

The Scaled Agile Framework (SAFe) defines seven core competencies, and they are:

• Lean-Agile Leadership:  Inspires adoption of Agile practices.
• Team and Technical Agility :  Enhances team capabilities and technical skills.
• Agile Product Delivery :  Delivers customer value through fast, integrated delivery cycles.
• Enterprise Solution Delivery:  Manages large-scale, complex solutions.
• Lean Portfolio Management:  Aligns strategy and execution.
• Organizational Agility:  Enables quick, decentralized decision-making.
• Continuous Learning Culture:  Encourages innovation and improvement.

These competencies provide a roadmap for organizations to navigate their transformation to Lean, Agile, and DevOps practices.

What are the SAFe Principles?

The SAFe Principles are a set of ten fundamental principles derived from Lean and Agile methodologies that guide the implementation of SAFe.

SAFe principles are guidelines derived from Agile practices and methods, Lean product development, and systems thinking to facilitate large-scale, complex software development projects. The ten principles that make up the SAFe framework are as follows:

• Take an economic view:  This principle emphasizes the importance of making decisions within an economic context, considering trade-offs between risk, cost of delay, and various operational and development costs.
• Apply systems thinking:  This principle encourages organizations to understand the interconnected nature of systems and components and prioritize optimizing the system as a whole rather than individual parts.
• Assume variability and preserve options:  This principle highlights the importance of maintaining flexibility in design and requirements throughout the development cycle, allowing for adjustments based on empirical data to achieve optimal economic outcomes.
• Build incrementally with fast, integrated learning cycles:  This principle advocates for incremental development in short iterations, which allows for rapid customer feedback and risk mitigation.
• Base milestones on an objective evaluation of working systems:  This principle emphasizes the need for objective, regular evaluation of the solution throughout the development lifecycle, ensuring that investments yield an adequate return.
• Make value flow without interruptions:  This principle focuses on making value delivery as smooth and uninterrupted as possible by understanding and managing the properties of a flow-based system.
• Apply cadence and synchronize with cross-domain planning:  This principle states that applying a predictable rhythm to development and coordinating across various domains can help manage uncertainty in the development process.
• Unlock the intrinsic motivation of knowledge workers: This principle advises against individual incentive compensation, which can foster internal competition and instead encourages an environment of autonomy, purpose, and mutual influence.
• Decentralize decision-making:  This principle emphasizes the benefits of decentralized decision-making for speeding up product development flow and enabling faster feedback. However, it also recognizes that some decisions require centralized, strategic decision-making.
• Organize around value:  This principle advocates that organizations structure themselves around delivering value quickly in response to customer needs rather than adhering to outdated functional hierarchies.

Related Content

Implementing safe: requirements model (v6).

"Software development is a complex and often challenging process. As development teams grow in size, managing requirements becomes increasingly difficult. The Scaled Agile Framework (SAFe) provides a comprehensive framework for managing requirements in an Agile environment, ensuring that development efforts are aligned with the overall business…

Mastering Agile Product Delivery with SAFe

This comprehensive guide explores Agile Product Delivery in the context of the Scaled Agile Framework (SAFe). Through it, we delve into key aspects such as Business Agility, Customer Centricity, Design Thinking, Lean UX, and the principles of Developing on Cadence and Releasing on Demand. We further examine how to manage the Agile Release Train…

Implementing SAFe: Lean Budgets

Implementing Lean Budgets transforms financial management in Agile environments. This approach decentralizes decision-making, establishes continuous funding cycles, and emphasizes objective progress measures, challenging traditional project budgeting methods.

Mastering Lean Portfolio Management with SAFe

Lean Portfolio Management (LPM) in the Scaled Agile Framework (SAFe) is a modern approach to managing a portfolio of initiatives. It utilizes Lean-Agile thinking and Agile teams to deliver continuous value to customers. Key competencies within LPM include Strategy and Investment Funding, Agile Portfolio Operations, and Lean Governance. By…

Name (required)

Email (required)

Privacy Preference Center

Privacy preferences.

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

Epics and Outcomes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comment (1)

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

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

Leave a comment

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

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

Never Miss A Post

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

To improve entrepreneurial outcomes and hold innovators accountable, we need to focus on the boring stuff: how to measure progress, how to set up milestones, and how to prioritize work. This requires a new kind of accounting designed for startups—and the people who hold them accountable. —Eric Ries, The Lean Startup [1]

Applied Innovation Accounting in SAFe

by Joe Vallone, Principal Consultant, SPCT/SAFe Fellow

Introduction

Unfortunately, traditional financial and accounting metrics have not evolved to address the need to support investments in innovation and business agility. As a result, organizations often use lagging financial indicators such as profit and loss (P&L) and return on investment (ROI) to measure the progress of their technology investments. While these are useful rear-view mirror business measures, these results occur far too late in the solution lifecycle to inform the actual solution development . Even NPV (Net Present Value) and IRR (Internal Rate of Return), though more forward-looking, is based on estimating the unknowable future cash returns and speculative assumptions of investment costs and discount rates. Moreover, even when used in conjunction with a sensitivity analysis (i.e. “what if” calculations), these financial metrics neither reflect, nor inform the learning obtained from incremental product development.  Thus, these traditional metrics aren’t helpful in our move to iterative, incremental delivery and business agility.

We need a better plan —a different kind of economic framework—one that quickly validates product assumptions and increases learning. In SAFe, this is reflected, in part, by applying the Lean Startup Cycle (see Figure 1), a highly iterative cycle that provides the opportunity to quickly evaluate large initiatives and measure viability using a different kind of financial measure: Innovation Accounting .

What is Innovation Accounting?

Innovation Accounting is a term coined by Eric Ries’ The Lean Startup . The Innovation Accounting framework consists of 3 learning milestones :

• Minimum Viable Product (MVP) – establish a baseline to test assumptions and gather objective data.
• Tune the Engine – quickly adjust and move towards the goal, based on the data gathered.
• Pivot or persevere – Decide to deliver additional value, or move on to something more valuable, based on the validated learning. (Lean thinking defines value as providing benefit to the customer; anything else is waste.)[2]

To validate learning and reduce waste, a fast feedback loop is essential, also referred to as ‘ build-measure-learn, ’ as illustrated in Figure 2. Applying the learning obtained from real customer feedback results in increased predictability, decreased waste, and improved shareholder value.

Leading Indicators versus Vanity Metrics

Innovation Accounting asks us to consider two questions: 1) Are we making progress towards our outcome hypothesis? 2) How do we know? In The Lean Startup this is known as a “ leap of faith assumption” ; one that requires that we understand and validate our value and growth hypothesis before we move further forward with execution. This becomes a basic part of the economic framework that drives effective solution development.

To answer these questions, and make better economic decisions, we support innovation accounting by using leading indicators , actionable metrics focused on measuring specific early outcomes using objective data. Leading indicators are designed to harvest the results of development and deployment of a Minimum Viable Product (MVP). These indicators may include non-standard financial metrics such as active users, hours on a website, revenue per user, net promoter score, and more.

It’s important to be aware of vanity metrics , which are indicators that do not truly measure the potential success or failure of the real value of an initiative. While they may be easy to collect and manipulate, they do not necessarily provide insights on how the customer will use the product or service. Measures such as the number of registered users, number of raw page views, number of downloads may provide some useful information or make us feel good about our development efforts, but they may be insufficient to provide the evidence necessary to decide if we should pivot or persevere with the initiative’s MVP.

There are some practical ways we can avoid being deceived by vanity metrics and instead work to evaluate our hypothesis. A/B testing or split-tests enable us to validate our outcome hypothesis using actionable data. For example, group A may get the new feature and group B does not. By establishing a control group, we can evaluate the results against our hypothesis and make decisions as part of our feedback loop. We can also avoid vanity metrics by focusing on customer-driven data. We can use cohort analysis to examine the use of a new product, service, feature, etc. over time as it pertains to a cohort (group). For example, suppose we wanted to see how a new feature on our website was improving the conversion rate to paying customers. We could look at new registrations per week (i.e. cohort) and report on the percentage of conversion to paying customers. We can analyze this information on a weekly basis and see if the conversion rate remains constant for each cohort (the group of registered users). If it does, we have a clear indication of how the feature is affecting the conversion rate. If it does not remain constant, then we have a chance to tune the engine or pivot.

Applying Innovation Accounting in SAFe

Measuring epics.

The implementation of large, future-looking initiatives is an opportunity for organizations to reduce waste and improve economic outcomes. In SAFe, large initiatives are represented as Epics and are captured using an epic hypothesis statement . This tool defines the initiative, its expected benefit outcomes, and the leading indicators used to validate progress toward its hypothesis.

Example of Airline Website Epic

For example, consider an airline that wants to develop a website for purchasing tickets. This is a significant endeavor that will consume a considerable amount of time and money. Before attempting to design and build the entire initiative, the epic hypothesis statement template should be used to develop a hypothesis, test assumptions, and gain knowledge regarding the expected outcome (see Figure 3).

We might hypothesize that the website will help reduce call center volume and ultimately reduce costs to the airline, resulting in better profit margins per ticket sold. Thus, one assumption we are making is that the website will be faster and easier than a phone call to the customer service department.

To test that hypothesis, we could release an incremental feature or set of features, i.e., an MVP that allows customers to research flight schedules. To validate and measure the efficacy of the feature(s), we could analyze the call volume as well as the types of questions the help desk received. Then we could quickly compare the trends of inquiries on the website vs. those at the call center. Additionally, using good DevOps practices, we could build telemetry into the feature and analyze customer interaction. The information captured in Figure 4 shows that call center activity has decreased and use of the website has increased. These leading indicators demonstrate that the MVP appears to validate our hypothesis.

Leading indicators can provide immediate feedback on usage patterns. By analyzing the objective data, we can test our hypothesis and decide to continue releasing additional features, tune the engine , or pivot to something else. Thus, the Epic’s MVP and the leading indicators enable us to make faster economic decisions based on facts and findings. It is interesting to note that in figure 4, the visits to the site metric by itself might be considered a vanity metric. On its own, this metric doesn’t tell us much about the success of our MVP or the viability of the Epic. However, placed in context with the other metrics, it gives us an indication of where customers are spending their time when they visit the website.

Example of Autonomous Vehicle Epic

With their direct connection to large numbers of users and their interactions, as well as the ability to quickly evolve the UI, websites are a convenient place to consider how to apply Innovation Accounting. However, Innovation Accounting has far broader applicability than that. Let’s consider a different example, an Epic which describes the sensor system of a new autonomous vehicle.

Our epic hypothesis (see Figure 5) is that the sensor system will quickly detect and help us to avoid collisions with objects. Our assumption is that the information will be provided fast enough for the vehicle to stop or take evasive action (as that is the entire point!).

To test the hypothesis, we would like to find out if the sensor system can detect objects and if it is indeed fast enough for our purposes before we build the entire system. We could build a single sensor and basic data capture software to validate the distance between the object and speed of vehicle control system interface. As an MVP, suppose we mounted the sensor on the front of a car and connected it to a laptop within the vehicle. Next, we place several objects on a test track and drive the vehicle toward them. We could use the software to record information from the sensor as our leading indicator. We could also use software to measure how long it takes for the message to be generated and sent to the vehicle control system interface by using a mocking framework instead of waiting for the vehicle control system to be built. This would give us an early indication of compliance with our NFR. Figure 6 describes the leading indicators for this cyber-physical system.

Based on the data generated during the MVP testing, we have some more questions to answer before we move forward with additional features in the Epic. Perhaps we can tune the engine  and see if we can decrease the message sending time. Why didn’t the sensor detect the road sign? Would going slower have helped for the initial tests? What happens if we place the sensor on the roof of the car? Based on the answer to these and other questions, we may need to pivot to a different technology.

‘Failing fast’ is an Agile value. The implication is that failure in small batch sizes is acceptable, as long as we learn from it . Thus, validated learning becomes the primary objective of testing the hypothesis. As previously mentioned, SAFe uses the Lean Startup Cycle to iteratively evaluate the MVP of Epics and to pivot (change direction, not strategy), or persevere (keep moving forward) decision against the outcomes hypothesis. This is done incrementally by developing and evaluating features from the Epic.  The empirical metric we use to prioritize the features is Weighted Shortest Job First ( WSJF ). Using WSJF, we can rapidly evaluate the economic value of the feature and the overall progress of the Epic towards its Business Outcome. This allows us to quickly and iteratively make a pivot-or-persevere decision based on objective data.

The decision to persevere indicates there is still additional economic benefit. Leading indicators validate our hypothesis and MVP, resulting in the development and release of additional features. The decision to pivot may occur when sufficient value has been delivered, or on learning that our hypothesis was incorrect. Deciding to pivot is so difficult that many companies fail to do it.[2] Often companies will continue to invest in an initiative despite (or lack of) data to the contrary. We have the opportunity to reduce waste of money and time, by utilizing fast feedback loops and leading indicators to avoid working on features that customers don’t want or need.

It’s important to note that Innovation Accounting, as applied to SAFe, does not consider sunk cost (i.e., money already invested). To pivot without mercy or guilt, we must ignore sunk cost, as discussed in SAFe Principle #1, Take an economic view . Although Lean and Agile budgeting may allocate funding to a value stream up front, we use the Lean Startup Cycle to continually evaluate the benefit hypothesis based on value delivered rather than on money or time spent. Consequently, the initial allocation of funds does not equate to the actual spending of funds ; which is why the decision to pivot or preserve is a critically important financial decision.

Variability and risk are part of every large technology initiative. However, traditional financial metrics used to measure the value of those initiatives during development have not evolved to address the need for innovation and business agility. Innovation Accounting was developed as part of the Lean Startup Cycle to provide validated learning and reduce waste. Developing and measuring a Minimum Viable Product is used to validate the hypothesis, obtain results, and reduce risk before committing to the investment in the entire system. This fast feedback loop, based on objective data and actionable metrics, enables incremental learning. Focusing on the right leading indicators ensures we make the vital pivot or preserve decision. SAFe’s use of Innovation Accounting and the Lean Startup Cycle enables the enterprise to reduce waste and accelerate learning while enhancing business outcomes.

Last update: 11 October 2021

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.

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 .

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.