Pattern Description

You now have hundreds of stories, all copied from each of your team’s backlogs and have no clue what your forthcoming Product Increment (PI) is going to deliver.

Your stories somehow have vague headlines, you declare as „features“, but they are rather what they are: headlines of groups of team stories.

The team’s stories are quite detailed, but lack a consistent view or perspective on the definition of ‚Done‘ (or something similar).

Thus it is very likely that these „features“ do not have a single trustworthy benefit hypothesis and that the feature acceptance criteria are empty.

Issue, Problem, Risk

• Since the headlines called ‚features‘ are team dependent, the features are not oriented on generating high level (and team over-arching) customer value, but on realizing something in a team, driven by the team’s product owner.
• Since you don’t have features focussing on generating customer value, the mandatory benefit hypothesis is either weak or non-existent.
• Since the feature is generated from team stories, there is a high risk the acceptance criteria are not focussing on the ART level customer’s perspective, but on a team level perspective.
• Since this is de-facto a bottom-up approach business owners and product managers will have serious problems with the product roadmap and the product vision. 

Root Cause

We see the root cause somewhere in between the following:

• a weak product manager, maybe not very experienced nor trained: he/she is dependent on the input of the teams‘ product owners, but is not able to turn these low level items into high level items the stakeholders really need.
• missing communication between customer (representatives), stakeholders, business owners and product manager(s) – and systems architects (typically responsible of creating enabler features).
• lack of time to successfully groom the feature backlog, complete the feature and benefit matrix (FAB) and the acceptance criteria, and prioritize the features using the WSJF method.

Mitigation, Remedy, How to avoid

Don’t write features as stories

• If you write features using the „As…, I need…, to get…“ templates, you lose the high level perspective and maybe you lose your stakeholders too.
• As SAFe expresses it: A feature is ‚a short phrase giving a name and context.‘

Prioritize using the WSJF method

SAFe makes it clear: ‚The WSJF prioritization model is used to sequence jobs (e.g. features, capabilities) based on the economics of product development flow.‘

So, use it!

Write proper acceptance criteria

Acceptance criteria as founding SAFe are looking like this:

Product Management is using these acceptance criteria to define and determine if the product features are properly implemented and if the nonfunctional requirements are met.

Lean UX

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

Eric Ries

If you start using Lean UX concepts including the minimum viable product (MVP) or the minimum marketable feature (MMF) on the feature program level or above, you make sure high level requirements and necessities are met, customer’s expectations are understood and communicated, and short & fast feedback loops lead to ‚elimination of waste‘.