Pattern Description
You have lot’s of stories converted from an old fashioned requirements specification. You have enough to do for the next years. Your customer is raising the bar and starts to put pressure on your deliveries.
Issue, Problem, Risk
A rat race is a rat race is a rat race.
Nobody knows why he/she works so hard? That’s bad and quite the opposite of ‚transparency‘ (pillar #1 of Scrum). Your eco-system should cater for openness and transparency.
Does every member of your scrum team – your Product Owner in particular – have a clear understanding of each of your sprint’s ‚Sprint Goal‘? If not, you have uncertainty on what a successful sprint is and when to kill the sprint because you will miss the sprint goal.
A missing or bad sprint goal will pull your DevTeam into the ‚finish stories‘ anti-pattern. This is quite different from maximizing product/customer value/benefit through a ‚potentially shippable increment‘.
Root Cause
It is just wrong to throw top-down overboard and believe you could deliver „the next big thing“ bottom-up.
You thought Scrum (as defined in here https://www.scrumguides.org/scrum-guide.html) is enough to get the cash cow to the customer? Bad luck. It is not.
Mitigation, Remedy, How to avoid
Let’s start with the easy ones.
The SAFe Requirements Model
If you look at your very own product backlog, you may see not much more than a flat list of quite simple ‚requirements‘:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when „Done“.
The Scrum Guide.
That’s about it. And this is why a ton of methodologists had to invent something ‚above‘ this.
PRINCE2 Agile has thought about the matching of standard PRINCE2 artifacts to agile terms, and came up with four possible levels (and I selected one possibility by underlining it…):
- Vision
- Epic, feature, theme, scope
- Epic, feature, function, coarse-grained user story
- User story, fine-grained user story
SAFe is very specific about their requirements hierarchy. Please have deeper look into https://www.scaledagileframework.com/safe-requirements-model/.
- Epic, is realized by
- Capability, is realized by
- Feature, is realized by
- Story
But be warned: A high level story (feature, epic, whatever) is not just a BIGGER story. At least within SAFe it has quite different attributes for very good reasons.
In essential SAFe (https://www.scaledagileframework.com/) there are two levels of stories: features and stories. But features are not written with a story stencil in mind:
As <who> <when> <where>, I <want> because <why>.
https://en.wikipedia.org/wiki/User_story
No. As an author of a SAFe feature you should stick to this:
Features are defined using a Features and Benefits (FAB) Matrix: Feature – A short phrase giving a name and context Benefit hypothesis – The proposed measurable benefit to the end user or business
© Scaled Agile, Inc. https://www.scaledagileframework.com/features-and-capabilities
Features are driving the product increments (a set of sprints) as stories drive the sprints (iterations in SAFe terms).
And features are combined to product roadmaps. See below…
Now with this at hand, we are getting much closer to the basic intent of Agile: Optimizing the value delivered to the customer.
The Sprint Goal
The current scrum guide mentions ‚Sprint goals‘ 27 times for a good reason.
In Scrum (https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog) the sprint backlog consists of three items:
- A set of product backlog items which shall be implemented within this sprint.
- A sprint goal.
- A sprint plan on how to implement the product increment and how to realize the sprint goal.
Please have a look at https://www.scrum.org/resources/blog/getting-done-creating-good-sprint-goals to get some ideas about good sprint goals.
If you want to challenge your sprint goal, take some ideas from Fabio Panzavolta I found here: https://www.scrum.org/resources/blog/five-questions-sprint-goal
Would you please keep in mind that although the sprint goal is mandatory and very important when it comes to meaningfulness. But it is by no means sufficient to really vanquish your team’s worm’s-eye perspective.
BTW: Nexus (https://www.scrum.org/resources/online-nexus-guide) structures sprint goals by adding a higher level nexus sprint goal, which will be fulfilled by each team’s individual sprint goal. This is symmetrical to the concept of Nexus sprint planning versus team’s sprint planning.
Product Roadmaps
So, plan we must.
© Scaled Agile, Inc. https://www.scaledagileframework.com/roadmap/
Roman Pichler has got some good advice on product roadmaps (https://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/)
SAFe has got a different approach: https://www.scaledagileframework.com/roadmap/. And I quite like it.
If you think about a ’standard‘ implementation, a product increment (PI) takes one quarter because it is consisting of six two-weeks sprints (iterations). Features (turned into PI objectives, for a deeper look into the differences spend some time on how to Differentiate between Features and PI Objectives in https://www.scaledagileframework.com/pi-objectives/) drive the PI. And as a product manager you should have a clear idea about this next quarterly PI. Thus the set of features (to be precise: the set of PI objectives) in the next PI is committed.
The PI roadmap now combines this committed PI with the forthcoming PIs which contain not so clear and sure features. These forthcoming PIs are forecasts and not committed, because you have learned your lesson from
Responding to change over following a plan
This is #4 of the four values of the Agile Manifesto (https://agilemanifesto.org)
If you now commit to the next three to four PIs (or: quarters), you committed suicide, because your ability to respond to change is down to zero.
Over-commitment is committing Agile suicide.
me.
The Vision.
Scrum does not have a clear idea about the product vision. Although you may find some ideas in this blog useful:
Sadly, Robbin suggest to use a story-like stencil, which is not quite the right way to communicate successfully with top-tier management, product marketing, non-developers or anyone who is not a Scrum-disciple.
The statement of a desired future state.
PRINCE2 Agile
SAFe agrees to this:
The Vision is a description of the future state of the Solution under development.
SAFe https://www.scaledagileframework.com/vision/
But SAFe says much more about your vision: Your vision should be present on all layers of your organization:
- Starting at the C-level you should have your strategic themes at hand.
- On portfolio level you should have a clear birds-eye view on the long-term endeavors.
- On the solution level (covering multiple product and/or systems) and again on the product level (then it’s called product vision….) you should ask yourself
What will this new solution do?
What problems will it solve?
What features and benefits will it provide?
For whom will it provide them?
What Nonfunctional Requirements will it deliver?
© Scaled Agile, Inc. https://www.scaledagileframework.com/vision/
BTW: The product roadmap „is part of the vision“.