Devops for Growth

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.

Lean UX design is a mindset, culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments, determining success by measuring results against a pre-stated benefit hypothesis. That hypothesis is tested early in the process through collaborative design methods within the Agile team. The results are then fed into a minimum marketable feature (MMF), which is evaluated by real users, whose feedback is then incorporated into the next benefit hypothesis cycle. This continues refinement and learning throughout the Lean UX process (see Figure 1). Figure 1. The Lean UX lifestyle as illustrated in SAFe and (adapted from Ref [ 1]. Empirical feedback drives the decision to pivot or persevere in feature investment and centralized design standards; governance enhances consistency and autonomy of the Agile teams’ feature testing and implementation.

© Scaled Agile, Inc.
Include this copyright notice with the copied content.

Read the FAQs on how to use SAFe content and trademarks here:
https://www.scaledagile.com/about/about-us/permissions-faq/
Explore Training at:
https://www.scaledagile.com/training/calendar/

The Lean UX allows us to escape the barrier of the traditional UX process to a more agile process. Here are 5 reasons to move to Lean UX.

Ilham Guggenheim était présente à Rennes pour animer une conférence sur la transformation digitale à Inbound Marketing France. Découvrez notre compte-rendu. Transformation digitale ? Transformation numérique ? Disruption ? Dès le début de sa conférence, Ilham Guggenheim est claire : nous avons affaire à un buzzword.

In most of my work these days I don’t often use an official canvas. I prefer to pick and choose the assumptions that can be found on the Business Model Canvas, Lean Canvas and others as appro…

Usabilis était présent à la journée de conférence du Flupa UX Day. Petit tour d’horizon… 3 grands thèmes se dégagent à travers l’ensemble des conférences