This blog will give you a big picture on how you get in a very natural way from a solid idea (vision) to a very good prioritized backlog in a pretty short time frame and can reap additional benefits as a very nice side effect.
How did I get there?
It was in 2009 when my former employer SAP started to move towards LEAN principles and agile development. This made a huge difference for SAP looking back and brought SAP successfully from waterfall to iterative and agile development and by this way closer to taking customer feedback and priorities into account - as it was in the early days of SAP when the founders were sitting next to their customers and understanding their real problems. And solving those and making SAP a #1 global player in the business software world.
I was part of product management in the R&D board area and at the time Jim Hagemann-Snabe was head of product development on the Executive Board and later CEO of the company and he did - IMHO - an awesome job in Change Leadership.
Besides the overall change effort to getting SAP in total towards a LEAN mindset, it was obviously one of the core activities to getting the standard development organization to adopt this new approach. The whole SAP organization from the very top (executive management) down to each and every one of the workforce was addressed in a way specific to the respective role. As I was a product manager in standard development, this was affecting the way we were used to work in a dramatic way - luckily. We were sensitized about the benefits of working LEAN and agile in general, but also very specifically to our key responsibilities, which means e.g. to having a “cross functional product team” (product manager, lead architect, lead technical writer, Q, Go-To-Market lead, …) in place and working with development teams (scrum teams) in the right way. I clearly remember the trainers and coaches telling us that (simplified view), if you have a good backlog, you need to work with the team(s) in sprints of 2 or 4 weeks. Define for the sprint the sprint backlog out of your overall (release) backlog and many more important aspects. The team needs to understand, estimate and commit to the backlog in sprint planning - if they feel they can do so. And then let them work in the sprint until the sprint review, while you already prepare for the next sprint. And so on. Sounds good so far. But nobody was able to tell “how to come to a good backlog”, which is key for the overall success. So I went into research on my end and met with colleagues in the broader community facing the same issue. And this is where “vision grounding” was born. And no, it wasn’t called like this at the beginning. But it answered this very key question!
What is “Vision Grounding”?
Vision Grounding (VG) is an approach and a combination of methodologies. There are two core elements to it:
The most important element is getting the cross functional team to have a common perspective on the “product vision” and by this “grounding” the initial vision with the diverse perspectives of all relevant players in this cross functional “product team”.
The second part is an extended version of Jeff Patton’s “User Story Mapping” (LINK), which is needed to put more meat on the bones of the aligned product vision by breaking it down along multiple dimensions into a prioritized product or release backlog. And by going down into personas and user stories or epics (depending on the size of the investment) “grounding” the vision into something more tangible.
This is also why I came up at some point with the name “vision grounding”, because this is what it does. It ensures the vision is being grounded in multiple dimensions.
How does “Vision Grounding” work?
Agree on a product vision statement
The start of everything is to make sure that the cross functional product team including key stakeholders (usually those who are the driving people of the business case) come together for a workshop - ideally face2face - and agree on the “product vision”.
But what is a product vision? The product vision is a non-blabla, brief and crisp description of 10-20 lines or a bulleted list of what you will deliver at the far end. It usually starts with “We will deliver <product> which enables our customers to do <capability 1>, <capability 2>, … “. It is key to describe this in a completely non-tech way, so that EVERYBODY knows what you’re talking about. Including and most importantly your customers and in a way that they immediately grasp the value. It is important to NOT take a given description of some manager as carved in stone. It might be a starting point, but facilitating the team to come up with a joint and agreed and understood product vision statement is key. You would be surprised how often I had already heard by some manager “Why should we do this? The vision is clear to everybody.” and after four hours of heated discussions and finally agreeing they said “I didn’t expect this. Only now we have a joint understanding of where we’re heading. This was absolutely key to do first!”. Because only then all members of the cross functional product team can take decisions in their respective area of responsibility in full awareness of the overall goal and by that are way more flexible and agile, because they know the big picture and the impact of their decisions.
A key aspect is that you have a first and solid common understanding. But the product vision is not carved in stone. Not for the time of the workshop and even less for the time after, when you keep learning from your customers.
Sketch the high level architecture vision
As your lead architect / engineer is part of the cross functional product team, (s)he now also has a solid understanding of what you want to achieve at the end. And most importantly the lead architect will develop an understanding of what the high level software architecture will be supporting this goal in a sustainable way.
These are key questions like cloud versus hosted versus onPrem versus mobile … but also the major components. And I really mean major - no detailed architecture please. It shows only the handful of major building blocks.
It is also important to understand that this will not necessarily be the final architecture because you keep learning over time. And also the architecture of version 1 can be very different to the eventual architecture given certain go-to-market (GTM) decisions.
Map out the major capabilities using personas and eUSM
Now you start putting meat on the bones of the product vision. I usually started by asking the teams I was coaching to list the personas, which they see using / working with the product and describing their main aspects to make them most tangible for all discussions. I ask the workshop participants to give them names like “Conny Consumer”, “Brad Buyer” and at some point the team talks about “what else would Brad need”. This is where they start having empathy for their users. There’re many good examples for the format (like LINK) and you might Google for your best way forward. I’m personally very much a friend of table-like formats with bullets, because they’re easy to grasp at the first glance, but make up your mind what suits you best.
Until here I usually coach the teams to doing this in plenum, because it is key to having all these discussions together and let it evolve. Now I recommend going into sub-working groups for the sake of efficiency (assuming you have a team which can be meaningfully split, i.e. >= 4 persons). Let the working groups pick their personas and make them tangible, come back to the plenum and present their results and agree them.
Caution: Do not go overboard with too many personas. Think about max a handful, if need be simplify or restrict to the most important ones to not make your life too complicated at the beginning. This would be overwhelming and can kill energy right at the start.
Think about the “usage sequence” of your product, i.e. from the install (if applicable) to configuration (if needed) via major business steps until support and maintenance. Whole point is not to forget something important, so that you have a perfect software at the end, but nobody can download / install … don’t take more than five “usage steps”.
The next step is to take the personas and talk about their day-in-the life-of. Do this again in the sub-working groups. I typically keep the groups as they were and they can continue their discussions on “their” personas, because they have already started developing empathy. Start by thinking what persona A does in the early morning as the very first thing and how the day ends. Do not take too many “activities” because it will make life too complicated (not more than 5 - 10 or so). The whole point of this is being able to later on give your backlog an inner structure along which you can also prioritize. Just having a huge stack of best ever user stories at the end does not allow you to deal with your backlog properly.
Now you have the backbone of what you want to deliver. It is a broad view on who will use your product and how it fits in their day.
This backbone is now the basis for getting into User Story Mapping (USM) as introduced by Jeff Patton. We had enhanced the approach a little at SAP, which is why I refer to it as eUSM, i.e. extended User Story Mapping.
Build working groups and let them think along a persona. This is a natural flow to developing even more empathy for the persona in your team. Think about what you need to develop to make the activity work for the persona. Here comes your possibly long feature list, but not as a huge pile of user stories, but in a nicely structured way - very natural. And don’t be too picky in the first go about the size of the user story. You will automatically figure out if one is too large - whatever “large” means in your context. I had used this approach for giving an investment of 30k person days (PD, i.e. the number of days a person like a developer - or multiple - has to work in order to achieve the desired outcome) an initial structure and there 300 PD was totally ok for a story. Whereas in other situations it was not and having a story of 10 PD was more appropriate.
Assess your user stories by moving those higher up in their column that you want to address first. Baseline for assessing the priorities is oftentimes a combination of business value, estimated effort, technical risk and I tend to add for portfolio management reasons the so called Kano value. More on this in a later blog.
Now build the plan for your next release or sprint or … by drawing the line. User stories above the line are part of the next iteration and others not. Drawing the lines sometimes forces you to rearrange the priorities of your user stories within a column, because you may figure out dependencies.
Now you have an executable and prioritized backlog for product / release / version / … You will likely have to detail out selected user stories when assigning them to the next sprint, but that is working out the details on the “right user stories”.
Iterate and adjust
NO, this is not the end! I typically recommend teams that I’m coaching to update their user story map every 3-6 months (no, not continuously). Digest what you’ve learned on the customer side and / or architecture side. This will help you keep your skeleton up2date with usually only minor adjustments needed.
What other positive side effects cannot be avoided
As you can easily imagine after reading until here, this whole exercise also helps tremendously in getting a pretty good understanding of the UX perspective through very good empathy for the persona and their flow. On top it helps you straight away in the whole test area like BDD, acceptance testing, test case development, …
In which context does “Vision Grounding” work?
Based on my experience, the size of the investment doesn’t matter. I experienced this approach working for
Investment of 30.000 person days
New product development of 5.000 person days
Release planning for 1.000 person days
Small investment of 150 person days.
I personally coached about 20-30 teams and we had established a community of USM coaches at SAP in order to be able to get this approach into the huge development organization of SAP.
One personal note: I’m totally convinced that “just reading and applying” is not good enough. You should have an experienced coach guiding you at the beginning, i.e. facilitating the initial workshop and checking in once in a while whether the team is still on the right track.
And a colleague of mine actually used it for organizing the planning of the “main features” of his new house :-).
How does “Vision Grounding” relate to “Design Thinking”?
A very esteemed colleague of mine once put it very nicely into a slide deck about the “innovation phases”. Design Thinking (DT) is often seen as the starting point if you’re still very unclear about what exactly the problem of your customers is and need ideation. Then you get into validating the whole thing (especially if you’re a startup) with “Lean Startup Framework” (I like and use the “Running Lean” from Ash Maurya a lot). And then you get into planning and execution, where scrum plays a critical role.
IMPORTANT: Do not think this waterfall-like! You go back and forth as needed also for subtopics.
And Vision Grounding is basically taking the result of a DT phase (or otherwise produced result) and planning this out as far as needed until you can go scrumming. You remember the initial question we wanted to answer?
“How do I get from a vision to a very good backlog?” - well, this is how it works!
Vision Grounding ...
I’m offering coaching on Vision Grounding through my Aventurin Consulting and would love to help you get from your vision to a very good backlog to making your product successful.
Let’s get in touch! You can reach me at achim.becker@aventurin.one and / or click this LINK for a LinkedIn connection.