My last blog was focused on what I learnt about the Scaled Agile Framework (SAFe). The theme quote for that blog was:
“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!”
So what are the small things we should do well at the team level or at scale? Breaking the work up, avoiding big batches, and letting the work flow was one of the recommendations.
This blog will focus on the integration of techniques to deliver goal-orientated scope (that breaks up the work) and take a look at how you might start to visualise and manage the flow at the portfolio level.
Delivering Goal-Orientated Scope
I am using an infographic as the tool to illustrate the integration of scoping techniques such as Impact Mapping and Story Mapping promoted by Gojko Adzic and Jeff Patton (respectively). The illustration is not an introduction to those topics (use the links to find out more) but instead a guide to the integration of these techniques, represented on a single sheet, with some key supporting messages.
My first experiment is to ask you to click on the infographic and digest it on its own without additional narrative.
Walking the Infographic
Now for some additional narrative on the illustration:
Scope Initiatives and Goals
We start in the top left hand corner with an example of the types of initiatives that typically instigate the delivery of new scope. Each of these initiatives should translate to goal(s) that need to be achieved so they converge into a set of Goal definition(s) in a common format.
Portfolio Backlog (Goals)
Each goal defines a problem to be solved, who it targets, and how success will be measured. This list of goals form the portfolio backlog; it is a prioritised ordered list. The method and cadence for prioritisation is not defined, but it would require the engagement of senior stakeholders and prioritisation policies would need to be explicit and transparent. Translating all initiatives into goals starts to break up larger batches (e.g. projects), these goals can then be prioritised amongst the other goals to be achieved. This helps to ensure we are working on the smallest most valuable thing, and avoid commiting capacity to long running projects, where some of the scope can often be of lesser value.
The next highest prioritised goal is analysed using an Impact Map. This looks at the impacts to behaviour needed to help achieve the goal, along with the deliverables that will support those changes. Each level in the map can be prioritised independently to help focus in on the deliverables that might have the biggest impact.
The impact map helps define the problem to be solved, connecting deliverables to behaviour impacts to goals to be achieved. Assumptions that have been made are visualised through the map. Can any of these assumptions be validated ahead of further work? This is an opportunity for “problem interviews” with a wider set of customers to confirm the problem and validate some of these assumptions.
Metrics have been defined at the goal level; it may be appropriate to break down these measures to individual deliverables that contribute to the goal. A separate table showing how the success for each deliverable will be measured may be required.
As we further analyse the scope to be delivered, we uncover whose life will be touched by the changes to be made. Stakeholder analysis involves continually understanding, cataloging, classifying, prioritising, engaging and empathising with the people that matter.
Program Backlog (Deliverables)
The selected deliverables form the program backlog; it is a prioritised ordered list. Not all deliverables from an impact map may get selected to enter the program backlog.
Scoping and Story Mapping
The next highest prioritised deliverable(s) are analysed through scoping workshops where customer segments are narrowed and personas created. Story Maps are created for each deliverable. Working backwards from outcomes the desired user activities are visualised and supporting system epics created (user story format). Using the visual prioritisation on the story map lines are drawn to indicate Minimum Viable Products (MVPs) outlining the smallest possible thing that could be built and released. MVP’s may cut across more than one deliverable (e.g. across Story Maps).
The story map, along with other supporting artefacts (e.g. UX wireframes, workflows etc.) start to form solutions to the problem being solved. Assumptions will have been made, so this is a opportunity for “solution interviews” with a wider set of customers to seek validation ahead of building the next MVP.
Release Backlog (MVPs)
The identified MVPs form the release backlog; it is a prioritised ordered list. Not all MVPs from the story map may get selected to enter the release backlog. The backlog will be hierarchical in nature, items high in the backlog will be more granular (e.g. story level) and those lower in the backlog more coarse grained (e.g. epic level).
Architectural spikes may be included in the backlog for risks already identified and prioritised accordingly. Non-Functional Requirements (NFRs) may manifest themselves as individual backlog items or as constraints applying to all backlog items.
MVPs prioritised for delivery
When a delivery team becomes available for delivery (capacity is created) they would pull the next prioritised MVP from the release backlog creating their next team backlog for delivery.
Foundation activities focused on reducing risk will be undertaken before development iterations get underway. Mature long-lived teams with established practices will have some of the identified activities already in play.
Development Iterations, Release and Validate Learning
Start to build MVP increments within your adopted “build-measure-learn” implementation. The infographic does have an emphasis on specification by example as part of defining scope (NB. there are further practices after “refine the specification” not represented in the illustration).
The MVP released does not have to be a “big bang” approach; it can be controlled (feature toggling) and targeted to particular customer segments, or time periods, to capture specific measurements and compare alternatives (e.g. A/B testing).
Validated learning is key; comparing actual metrics to expected outcomes can provide new knowledge and truly validate assumptions. With this new learning what adaptions are required? Do goals need to change? Are amendments to existing impact maps, deliverables and/or story maps required? What’s your next MVP?
How would you visualise and manage this flow at the Portfolio level?
Here is an example Kanban view of how you might start to visualise and manage this flow (click on it to see it in more detail).
In the example all cards that relate to the same goal are in the same colour and some columns have a Work In Progress (WIP) limit set.
Teams will still operate their own team level story walls for the MVP they are working on.
8 thoughts on “Delivering Goal Orientated Scope”
thank you for this great posting. The way from the vision to the product backlog is a big issue most of the agile teams are facing in they daily work. It has been left open by the most agile frameworks like scrum and I can´t understand it. It´s the most critical stage to save the product, to do the right thing. A good software has no value if it is not accepted by the end user.
I am also working on this area and was some weeks ago on workshops of Tom Gilb and I liked that. It´s about focusing on the business and product value and quantifying them to be able to measure the success . I also liked the concept of Impact Estimation Tables but I am not really confident how to use it in real life. Any Experiences about that?
Thanks for the comments. That’s what’s great about Impact Mapping, linking everything you do back to the goal you want to achieve to deliver on your strategy to achieve your vision. If impact mapping doesn’t fit your context than the Vision Board is an alternative. Have you got anything to share on your work in this area? It’s early days for me with Impact Mapping, that’s a recent addition to the other elements on the infographic which I have been using. For measurements Gojko mentions 4 strategies (1. bullet points against nodes, 2. rephrase nodes to reflect measurement, 3. separate metrics table, 4. attach additional nodes). I have favoured the metrics table to keep the illustration simple but there is one key difference. Gojko in his examples mostly shows the metrics against the goal but does also mention the possibility of attaching to impacts. I am taking that a slight step further by potentially breaking down the goal measures to individual features. The intent would be to try to break down the goal to what that individual feature will contribute (e.g. a subset of the measures either in type and/or level). The reason might be that your first MVP might only deliver one of those features so how do you measure success of that individual feature (towards the goal) to PIVOT when there is still work ahead to achieve the full goal. Where the decomposition does not make sense then just roll up to a higher node level in the impact map (using one of the other 3 strategies). Does this help?
I am a product owner with experience mainly in development of mature products. I am about to begin work on a project to build a product from the ground up. The vision is fairly well understood although we need to do some additional discovery and persona validation. I came to this post in a search for help to learn how to beging the initial product backlog where we’ll need to do those foundational activities before feature development. So first, thanks for putting that step into context for me. But where can I find more info about scoping and managing those foundations? I’ve never done this before as a PO. Thanks!
Hi there… I am a product owner and pretty much all of my experience has been working on fairly mature products. I’m about to start on a ground-up product and I found your page, via Roman Pichler’s blog, in search for creating the initial backlog items to create those foundational items that you mentioned above. Unfortunately, neither this post, nor the original one on Pichler’s blog actually go into detail about how to go about defining those first steps of development. Got any advice? How do I keep the team focused on the product goals when they’re trying to figure out architecture and preliminary design? How long should that go before we start putting features in place? Is it enough to build the foundations for the first MVP? Does it make sense to establish an architecture that can do the feature toggling and A/B from the beginning? (I think yes — but how do I as PO encourage that kind of technical design without dictating the how? Would love to hear your thoughts or please point me to some relevant resources?
Hi Jenny, just about to jump on a flight, give me a day and I’ll get back to you.
The infographic shows an example of a flow of activities from business goals to delivery with validated learning. The initial discovery work depicted (impact mapping, problem validation, story mapping, solution validation) and the foundational activities are normally grouped together as an initial phase and people might refer to these activities as an Inception or similar. I’m focussing instead on the scoping flow (not the phase) but need to highlight that some activities are required to reduce risks to delivery before a team starts iterating on the build of a MVP – these are what I have grouped together and labelled Foundation. The principle is to do just enough and make it as short as possible, established teams will have much already under control, all will need to work on ensuring a shared vision for this next MVP though, some team members may/will not have been involved in the earlier discovery work, estimating and creating a release plan may be necessary (that requires the whole team), some very high level architecture and design may be needed and, very importantly, there maybe some technical risks that could derail the whole MVP so they need to be spiked before iterations get underway to ensure the MVP is viable. It is a balancing act to do only what is necessary in these foundation activities to keep it as short as possible but also addressing risks sufficiently so you are not derailed in delivery.
So to address some of your points and answer some questions, considering the above, as well as the following agile principle:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
– avoid doing any big upfront requirements, architecture or design work in these foundation activities, it’s high level architecture, design and spikes to lower risk to delivery and make it as short as possible
– the backlog should reflect the outputs from the discovery work, if you used impact mapping then by definition the team should only be focused on work related to stories that impact goals
– yes the context for these activities is only for the next MVP being undertaken
– i would suggest that a feature toggle and support for A/B testing is not complicated, it does not present high risk to de-rail the MVP, so have it as part of your backlog and do the work within the iterations
I hope this helps!
Really like your blog on delivering goal-orientated scope. I am having trouble reading your scoping6.png image especially the grey text in A4 format. Do you have a larger version where text is easier to read. Thanks
Glad you liked it Paul, I did that a while ago now so it’s bit outdated now based on my current thinking, experiences and learning. The essence of it, techniques and small messages are still valid though I think. I would redo it if I had the time. Anyhow here is a link to a larger version you can download https://drive.google.com/open?id=0BzjZIymXjoMbRVhWekhleTh5VEE
Comments are closed.