feature hypothesis fully evaluated safe

The ART of SAFe

Applying Lean and Agile techniques at scale to bring about effective, sustainable improvement in Culture, Execution and Business Results

Monday, January 8, 2018

Effective feature templates for safe, introduction, how much detail is needed, and by when.

• Prior to WSJF assessment
• Prior to PI Planning

Feature Canvas

New Product: “The current state of the [domain] has focussed primarily on [customer segments, pain points, etc]. What existing products/services fail to address is [this gap] Our product/service will address this gap by [vision/strategy] Our initial focus will be [this segment]”

Existing Product: “Our [service/product] is intended to achieve [these goals]. We have observed that the [product/service] isn’t meeting [these goals] which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?”

“We believe this [business outcome] will be achieved if [these users] successfully achieve [this user outcome] with [this feature]”.

Sample Completed Canvas

A glimpse at how you might visualise your next WSJF estimation workshop

Detail beyond the Canvas

• User Journeys:  Some framing UX exploration is often very useful in preparing a Feature, and makes a great support to teams during PI planning.  
• Architectural Impact Assessment: Some form of deliberate architectural consideration of the potential impact of the feature is critical in most complex environments.  It should rarely be more than a page – I find a common approach is one to two paragraphs of text accompanied by a high level sequence diagram identifying expected interactions between architectural layers.
• Change Management Impacts: How do we get from deployed software to realised value?  Who will need training?  Are Work Instructions required?  

Tuning your Template

Who completes the canvas/template, 30 comments:.

Awesome work Mark! We have created some for clients too that we can't share. :-(

Thanks for sharing Mark - these are really useful. I really like the hypothesis statements for features and think that this is a major enhancement in SAFE 4.5. I wrote a blog post about it here: http://runningmann.co.za/2017/09/25/the-power-of-feature-hypotheses/ that you might be interested in.

These are awesome Mark. Thanks for sharing

Thanks for sharing your experience on this area with the community Mark. Feature Templates are a very common requirement for Agile practitioners, maybe you can persuade the SAFe community to include an artefact like this in the framework.

Information was good,i like your post. Looking forward for more on this topic. product management

This is great! Do you have the template format available so we don't have to replicate?

great stuff, how would you differentiate this from SAFe Epics

Other problems include editing resistance, lack of or significantly delayed communications and lack of professionalism. website

I discovered your blog site site on the search engines and check several of your early posts. Always maintain up the very good operate. I recently additional increase Rss to my MSN News Reader. Looking for toward reading much more on your part later on!… apple tablet mockup

I genuinely treasure your work , Great post. ipad mockups

When I originally commented I clicked the -Notify me when new surveys are added- checkbox and from now on every time a comment is added I buy four emails with similar comment. Perhaps there is any way you are able to eliminate me from that service? Thanks! web design company san francisco

Good post and a nice summation of the problem. My only problem with the analysis is given that much of the population joined the chorus of deregulatory mythology, given vested interest is inclined toward perpetuation of the current system and given a lack of a popular cheerleader for your arguments, I’m not seeing much in the way of change. web design company san francisco

Cutting up pictures, reestablishing of old photos, working around with watermarks, and other progressed tips and deceives can likewise be found in a high caliber and significant Adobe photograph shop instructional exercise. Professional graphic design

Very efficiently written information. It will be beneficial to anybody who utilizes it, including me. Keep up the good work. For sure i will check out more posts. This site seems to get a good amount of visitors. essay writing service

Their willingness to partner with us has been great. UI design agency

Hey enormous stuff or pleasant information you are offering here. best branding agencies

Nice blog Mark How can I get a downloadable version of this Canvas?

I think you can make video about it. If you want to promote your channel on youtube you can buy youtube subscribers for it

Thanks for this incredible information. I think you could make a video about feauture templates for sale and post it on Instagram. By the way if you want to get more followers for your profile, you can repeatly use the help of https://viplikes.net/buy-instagram-followers to quickly boost their number.

Socialize Club- Buy Facebook live stream views cheap in price but high in quality.We provide you with 100% Real Facebook live stream views delivered at your facebook live video instantly.

Packaging should function as a barrier to air, water vapor, dust, and other contaminants. Because food items might be in liquid form, they must be leak-proof to avoid loss during transportation. BOPP film supplier

percetakan buku online di jakarta percetakan murah jakarta percetakan online jakarta percetakan Jakarta timur cetak murah jakarta cetak online jakarta digital printing jakarta print murah jakarta jasa print murah cetak buku murah di jakarta timur

I use the aforementioned off-page SEO techniques and am currently seeing the results of my labors with page 1 Google search engine rankings. For example, Deanna Hibbs, a full-time working mother, discovered internet marketing while searching for a work schedule other than 9 to 5. SEO philadelphia

thank you for share an informative blog article with us. kitimesblog

Essential phases

This comment has been removed by the author.

Produk Elektronik Terbaik Saat Ini Bahan dapur memasak ikan Bumbu dapur ayam goreng Menjual bahan dapur Shin Tae Yong coah terbaik sepanjang masa Justin hubner bek andalan timnas indonesia Nathan Tjoe a on bek bule berdarah indonesia yang membela timnas Jualan tanpa modal hanya dengan perlengkapan dapur

Try for free

Minimum Requirements for a Feature

Minimum requirements for a feature: what is a benefit hypothesis, minimum requirements for a feature: who writes acceptance criteria, feature definition.

A feature, within the scaled Agile definition (SAfe), requires a benefits hypothesis and acceptance criteria. These establish what and why you are testing and how you will determine success or failure. Each feature will usually have three key components that form the minimum requirements: Beneficiaries. These are needed upfront to establish the hypothesis and the acceptance criteria. Benefit hypothesis.  Acceptance criteria.

.css-uphcpb{position:absolute;left:0;top:-87px;} How do you write a feature in agile?

The minimum requirements already discussed can be made more detailed by covering a few related areas:

The beneficiaries.

The benefit hypothesis. 

The feature’s business value.

A clear feature description.

Acceptance criteria.

The two fundamental elements of the benefits hypothesis and the acceptance criteria can be unpacked in a little more detail to illustrate their individual and collective roles for features.

The benefit hypothesis is the business value that the feature is expected to deliver. Similar to a scientific hypothesis, this is a statement that will ultimately be tested to see if it is correct. A good formula to use is:

If (proposition), then (benefit)

The proposition is what your team plans to deliver, while the benefit is the value that this will deliver. Benefits can be business-side and include:

Increased efficiency.

Greater transparency.

Cost reductions.

Improved data streams.

Increased revenue.

On the client-side, benefits can include:

Increase customer satisfaction.

Improved functionality.

Greater simplicity for better customer experiences (CX).

How likely is this proposition able to deliver this benefit? 

Is this feature’s success rate quantifiable? 

You must be able to validate your hypothesis to measure the relative success or lack of success of the related feature. Ongoing optimization or even a decision to pivot will not be possible without the ability to quantify how well the proposition succeeded in delivering the benefit.

In Scaled Agile Frameworks (SAFe) a feature’s acceptance criteria are usually written by the stakeholder or the product owner. The acceptance criteria should provide a framework to measure whether the benefit is being delivered by the proposition. In other words, has the feature shown the benefit hypothesis to be correct? If not, is it possible to optimize or would it be better to pivot?

The main functions of acceptance criteria are:

Determine if the feature has been implemented correctly.

Establish whether the business benefits are being delivered.

Mitigate implementation risks.

Facilitate early validation testing to prevent unnecessary costs and effort.

Inform user stories and functional tests.

General FAQ

Glossary categories

Feedback Management

Prioritization

Product Management

Product Strategy

Roadmapping

Prioritize with confidence

Book a demo

Experience the new way of doing product management

The Running Mann

Humorous Anecdotes, Observations & Accounts of Marathon Running & Agile Adventures.

The Power of Feature Hypotheses

One of the improvements SAFe version 4.5 introduced was incorporating practices from “ The Lean Startup ” into the framework – specifically the use of benefit hypothesis statements into features and epics. This is a story of how well this worked for us.

We were worried about the standard of feature writing across our teams and also wanted to bring them up to speed with the SAFe 4.5 feature hypothesis thinking. Therefore, we organised a Friday afternoon “Lunch and Learn” session for interested team members.

The main objective was to go over a practical example from one of our feature teams and convert an existing feature into a ‘ valuable feature hypothesis statement ‘.

[If you are unfamiliar with the Lean Startup concept of hypotheses, please see supporting post:  Using Hypothesis Statements for Features in Software Development ]

Getting A Feature Benefit Hypothesis Statement

We started with the feature captured below that, no disrespect to team, was not very well written. The definition I like to use for a well written feature is that: ‘ someone outside the team can read it once and understand what needs to be done ’. At this stage I don’t even think that most of the team understood the feature.

Luckily we had the product owner (PO) in the room. We asked him a few probing questions that went something like this.

Team: Why are we doing this change? What is the benefit? PO: We need to update the audit report fields for our customers. Team: Why do they need the additional fields. PO: So that customers can check for errors before they submit them to us for processing. Team: Why do they check for errors? How does this work? PO: All customers have a QA person or someone similar checking these reports to prevent errors being processed. When errors get missed and processed, it wastes time and causes a lot of frustration. Team: So what exactly is the current problem? PO: Today, customer auditors can’t see all the relevant information on the audit reports for cross-checking and referencing so many errors are still processed. Team: What is the intended result of this change? PO: We’ll reduce the error rate by 95%. [And BAM! We get our hypothesis]

Interesting takeout: The PO did not come right out with the “95% error reduction” even though it was in his head from the start – it required a conversation to get his knowledge shared with the rest of the team. This is part of the magic of conversation within collocated teams – and the importance of having a PO who works with the team.

The benefit hypothesis makes the “why” clear to without having to write a long document. Everyone in the room quickly came to the same understanding as to what needed to be done and why. A well worded hypothesis statement helps remove ambiguities and focuses the team on what really needs to be done. [To understand why “why?” is important – see Simon Sinek’s TED Talk below.]

The other (perhaps even more) positive outcome is that it gives “purpose” to the teams’ work. I asked the group, “Would you rather (a) update some fields on an audit report or (b) reduce error rates by 95%?” – unsurprisingly there was unanimous agreement that (b) was the more exciting option.

“Reducing error rates by 95%” gives meaning to the team’s work. I am unlikely to go home and proudly tell my kids I updated some fields on an audit report. But telling them that I helped reduce foreign exchange error rates by 95% makes my job as a developer on a transactional banking system sound sexy and important!

Feature Acceptance Criteria & Slicing

We then moved onto the feature acceptance criteria (AC). The simple way I view feature AC is, “ How will we UAT the feature to know that it’s complete and fit for purpose? ” (as opposed to user story AC which are the actual unit test cases).

If you are not able to write clear AC you don’t know enough to proceed with the feature so this was a good test of the strength of our feature hypothesis. Once again it was an interesting and valuable discussion with participants throwing various questions at the PO. A summary is below:

Which countries are in scope?

The PO initially said “all countries”. Further conversation sliced it down to two countries (South Africa and Uganda) where there was definite current need – from there it made sense to split the feature into one for each country. South Africa had the most urgent need so we focused on that and the lower priority Uganda feature went onto the backlog (where it will remain until it becomes priority). The requirement that the initial feature for South Africa be scalable for other countries was included as a non-functional requirement.

Attempted slipping in of a production defect

The PO tried to slip a production defect into the AC (the format of the onscreen and printed reports are different). The team deftly managed to slice the defect off the feature (the defect fix is roughly the same size as the eventual feature). The valid defect was added to the team backlog (where the PO can prioritise it against other work to determine when it will get fixed).

Attempted scope creep

The PO also tried to slip a new requirement into the AC – the ability to be able to save audit reports as a .pdf file. Once again the team deftly convinced the PO that this was not part of the minimum viable product (MVP) by referring to the hypothesis statement (i.e. we don’t need to save to .pdf to test the hypothesis). The valid requirement was also added to the team backlog (and the PO gets to decide when it’s priority enough to be built).

Interesting takeout: In my opinion, the PO was doing his job perfectly – trying to get as much as possible into the feature to maximise the customer benefit. Because he’s part of the overall team having the conversation he gets to understand the trade-offs involved with different decisions. When posed with the question, “Do you want to have the feature done in 2 weeks if we just do MVP or do you want to wait for 2 months if we do ‘ all this other stuff ‘?” a good PO will always go for “ small and fast “.

By reducing the feature to a single (highest priority) country and omitting other requirements that (whilst important) had no impact on the hypothesis statement, the feature ended up being at least 10 times smaller than if we’d tried to include everything. Slicing the feature down to get the most value with the least amount of work drastically increases the speed with which it can be built and dramatically reduces risk.

The team left the room knowing exactly what needed to be done. More importantly everyone had agreed on what didn’t need to be done “right now” (i.e. in the next sprint) because they were not MVP (however these requirements have been added to the team backlog and can be done when the PO prioritises them). The PO was also part of all the decisions taken so he should get no nasty surprises when the feature is presented back as “done”.

Conclusion: Super-Quick Delivery

The best part of this story was that two weeks later when I asked the team “How’s the feature going?”, the reply was “It’s already done.”

The team was able to fully design, build and test a valuable feature in less than two weeks (fitting easily into a 2-week sprint). In the past a feature like this would usually take 12 months to deliver (see the supporting post “ 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery “). By slicing the feature down to its true MVP and the team knowing exactly what was needed and why, the feature flew through the development value stream.

Of course, now the real test is to measure whether our hypothesis proves true and we successfully reduce the error rate by 95% – let’s hope so! We’ll know pretty soon…

The actual reduction in client error rates was 80%. As it stands this has been deemed sufficient. There are no plans to build additional features to further reduce the error rates (as there have been higher priority features to work on). Likewise, the production defect has not been fixed (and may never be) since it has never been a priority compared to other more beneficial work.

I delivered a presentation on “The Power of Feature Hypotheses” at Agile Africa 2018 using this and other examples. Here is the video link from the conference:  https://youtu.be/CUVX1AiqQak?list=PLp6xQ3fl72zIu8FJjDtBUFUS0w1FPQhPZ

I am also more than happy to submit a speaker proposal for your conference. Feel free to contact me via email: [email protected] or Twitter @runningmann100 /  @StuartDMann .

4 Replies to “The Power of Feature Hypotheses”

• Pingback: 6 Reasons: From 12 Months to 2 Weeks for Feature Delivery - The Running Mann
• Pingback: Using Hypothesis Statements for Features in Software Development - The Running Mann

Good account of what we discussed in the session and what was learnt. Going forward it will definitely provide a mechanism for us to access information on the sessions to further unpack.

• Pingback: How George Costanza, Frogger & a Craving For Sushi Help Explain Features & User Stories - The Running Mann

Leave a Reply Cancel reply

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

Please enable JavaScript to submit this form.

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

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

Luck is what happens when preparation meets opportunity. —Seneca

Enablers bring visibility to all the work necessary to support efficient development and delivery of future business requirements. Primarily, enablers are used for exploration, evolving the architecture, improving infrastructure and compliance activities. Since enablers reflect real work they cannot remain invisible. Instead, they’re treated like all other value-added development activities—subject to estimating, visibility and tracking, Work in Process (WIP) limits, feedback, and presentation of results.

Type of Enablers

Enablers can be used for any activities that support upcoming business requirements and generally fall into one of four categories:

• Exploration enablers – These support research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective Solutions and evaluating alternatives.
• Architectural enablers – These are created to build the Architectural Runway , which allows smoother and faster development.
• Infrastructure enablers  – These are created to build, enhance, and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster  Continuous Delivery Pipeline .
• Compliance enablers  – These facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals.

Creating and Managing Enablers

Enablers exist throughout the Framework and are written and prioritized to follow the same rules as their corresponding epics, capabilities, features, and stories.

• Enabler Epics  – Are written using the ‘Epic Hypothesis Statement’ format, in the same way as business epics. Enabler epics typically cut across  Value Streams  and  Program Increments (PIs) . To support their implementation, they must include a ‘Lean Business Case’ and are identified and tracked through the  Portfolio Kanban system.
• Enabler Features and Capabilities  – Defined by Agile Release Trains (ARTs) and Solution Trains . Since these enablers are a type of  Feature or Capability , they share the same attributes, including a short phrase, benefit hypothesis and acceptance criteria. They also must be sized to fit within a single PI.
• Enabler Stories  – Must fit in  Iterations  like any  Story . Although they may not require the user voice format, their acceptance criteria clarify the requirements and support testing.

Enablers are often created by architects or by engineering. They might be Enterprise Architects supporting the portfolio backlog, or System and Solution Architects/Engineers supporting ARTs and Solution Trains . Architects steer enablers through the Kanban systems, providing the guidance to analyze them and the information to estimate and implement them.

To improve the existing solution, some enablers will emerge locally from the needs of the  Agile Teams , ARTs or solution trains to ensure that enough emphasis is placed on furthering the solution and extending the architectural runway. Those that make it through the Kanban systems will be subject to capacity allocation in the  Program and Solution Backlogs . This can be applied for enabler work as a whole, or it can distinguish between different types of enablers.

Applying Enablers

Exploration.

Applying enablers for exploration provides a way for Agile teams to discover the details of requirements and design. The nature of Solution Intent  is that many requirements begin as variable intent. After all, at the beginning of development little is known about what the customer needs or how to implement it. Customers themselves often don’t understand exactly what they want. Only through iterative product development and demos do they begin to figure out what they need and the solution intent can become fixed.

On the solution side, there are many technical possibilities for how to implement a business need. Those alternatives must be analyzed and are often evaluated through modeling, prototyping, or even concurrent development of multiple solution options (also known as  Set-Based Design ).

Architecture

The architectural runway is one of the constructs SAFe uses to implement the concepts behind  Agile Architecture . The runway is the basis for developing business initiatives more quickly, on appropriate technical foundations. But the runway is constantly consumed by business epics, features, capabilities, and stories, so it must be maintained. Enablers are the backlog items used to maintain and extend the runway.

Some architectural enablers fix existing problems with the solution—for example, the need to enhance performance. These enablers start out in the backlog, but after implementation, they may become  Nonfunctional Requirements  (NFRs) which can be considered constraints on new development. In fact, many NFRs come into existence as a result of architectural enablers and tend to build over time, as can be seen in Figure 1.

Infrastructure

Agile development is built on frequent integration. Agile teams integrate their work with other teams on the ART at the System Demos in every iteration. The trains that are part of a Solution Train integrate every PI as part of the  Solution Demo . Many  Enterprises  implement  Continuous Integration  and Continuous Deployment to ensure that the solution is always running. This reduces the risk at the integration points and permits deployment and early release value.

The System Team assists one or more ARTs in building and using the Agile development environment infrastructure—including the continuous delivery pipeline toolchain—as well as integrating assets from Agile teams. Infrastructure enablers are used as backlog items to advance this work, both to support new user scenarios and to enhance the agility of the enterprise.

By incrementally building the necessary artifacts in the Solution Intent over a series of PIs, SAFe supports continuous verification and validation. Verification activities are implemented as part of the normal workflow (e.g., backlog items or Definition of Done [DoD]). While the artifacts will satisfy the objective evidence needed at the end of development, they are created iteratively throughout the life cycle. Validation occurs when Product Owners, customers, and end-users participate in ART planning and system demos, validating fitness for purpose.

For example, consider that regulations often require design reviews and that all actions need to be recorded and resolved. The design review enabler backlog item offers evidence of the review, and its DoD ensures that actions are recorded and resolved according to the Lean Quality Management System (QMS). If needed, the actions themselves could be tracked as enabler stories. Regulations may also require that all changes be reviewed, which is addressed by a compulsory peer review DoD for all stories.

Implement Architectural Enablers Incrementally

The size and demands of architectural enabler work can make it overwhelming. So, it’s important to remember that it needs to be broken down into smaller stories that fit in an iteration. This can be difficult, however, as architectural and infrastructure changes can potentially stop the existing system from working until the new architecture/infrastructure is in place. When planning enabler work, make sure to organize it so that the system can operate for most of the time on the old architecture or infrastructure. That way, teams can continue to work, integrate, demo, and even release while the enabler work is happening.

As described in [1], there are three options:

• Case A  – The enabler is big, but there is an incremental approach to implementation. The system always runs (operates).
• Case B  – The enabler is big, but it can’t be implemented entirely incrementally. The system will need to take an occasional break.
• Case C  – The enabler is  really  big, and it can’t be implemented incrementally. The system runs when needed. In other words, do no harm.

Examples of incremental patterns are also described in [2], where the legacy subsystems are gradually ‘strangled’ over time, using proven patterns such as asset capture or event interception.

By creating the technology platforms that deliver business functionality, enablers drive better economics. But innovative product development cannot occur without risk-taking. Therefore, initial technology-related decisions cannot always be correct, which is why the Lean enterprise must be prepared to change course on occasion. In these cases, the principle of sunk costs [3] provides essential guidance: Do not consider money already spent. Incremental implementation helps, as the corrective action can be taken before the investment grows too large.

Implement Enabler Epics Across ARTs and Value Streams

Enabler epics and enabler capabilities can cut across multiple value streams or ARTs. During the analysis phase of the appropriate Kanban system, one of the important decisions to make is whether to implement the enabler in all Solution Trains/ARTs at the same time or to do so incrementally. This is a trade-off between the risk reduction of implementing one solution or system at a time versus the Cost of Delay (CoD) caused by not having the full enabler, as Figure 2 illustrates.

Last update: 10 February 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.

• Find Flashcards
• Why It Works
• Tutors & resellers
• Content partnerships
• Teachers & professors
• Employee training

Brainscape's Knowledge Genome TM

Entrance exams, professional certifications.

• Foreign Languages
• Medical & Nursing

Humanities & Social Studies

Mathematics, health & fitness, business & finance, technology & engineering, food & beverage, random knowledge, see full index.

SSM SAFe 5.0 > Experiencing PI Planning > Flashcards

Experiencing PI Planning Flashcards

When looking at the Program Board, what does it mean when a feature is placed in a team’s swim lane with no strings?

That the feature can be completed independent from other teams.

What is one thing the Scrum Master does during the IP Iteration?

Updates capacity.

What are common anti-patterns during PI planning?

• Pressure is put on the team to over commit
• The team under commits due to fear of failure
• Over planning ahead of time to make it more efficient loses the essence of PI Planning
• The plan, rather than the alignment, becomes the goal

Which two actions are part of the Scrum Master’s role in PI Planning?

• Maintain the time box
• Ensure the team builds a plan they can commit to
• Make sure the team is honest in their confidence vote
• Facilitate coordination with other teams without doing it for them
• Act as a request buffer for a team that has a lot of dependencies
• Manage the Program Board
• Facilitate the retrospective

When is a feature hypothesis fully evaluated?

When the customer uses the feature in production.

What is accomplished in the first part of the PI Planning meeting?

Items are selected from the Program backlog.

During PI Planning, who owns feature priorities?

Product Management

What Agile Manifesto principles describe the importance of PI Planning in SAFe?

The most efficient and effective methods of conveying information to and within a development team is face-to-face conversation.

Why is a confidence vote held at the end of PI Planning?

To build shared commitment to the program plan.

When working with an Agile Team, what is expected from Product Management?

To clarify the scope of feature work.

PI Objectives summarize data into meaningful information that enhances alignment and provides what outcome?

Visibility for all.

What are PI Planning inputs?

• Vision/Product Vision

- Top 10 Features

What are PI Planning outputs?

• PI Objectives (Team and Program)

- Program Board

What are some of the benefits provided by PI Objectives?

• Common language for communicating with business and technology stakeholders is created
• Near term focus and vision is created
• AV (Achieved business Value) can be assessed by the Agile Release Train
• Contribution by Team to business value is communicated/highlighted
• Dependencies that require coordination are exposed

SSM SAFe 5.0 (6 decks)

• Characterizing the Role of the SM
• Introducing Scrum in SAFe
• Experiencing PI Planning
• Facilitating Iteration Execution
• Finishing the PI
• Corporate Training
• Teachers & Schools
• Android App
• Help Center
• Law Education
• All Subjects A-Z
• All Certified Classes
• Earn Money!