– or how to tie Product Strategy, Lean Startup, Design Thinking, and Agile together.
Scrum is a simple and yet powerful framework, but one artifact, The Product Backlog, is too simplistic to capture the future of a complex product. Likewise, Refinement is insufficient to ensure the balance between the strategic direction and the deliveries on the short term. As a consequence, it is hard to maximize the value for the users. The main reason is that a simple Product Backlog does not ensure enough transparency to engage stakeholders at different levels in collaboration around the value creation.
That said, I think the Product Backlog is a powerful concept. Enforcing an ordered list of product backlog items (PBIs) with higher prioritized PBIs refined to more detail at the top and less valuable coarse-grained PBI’s at the bottom and an understanding that the success criteria is not to deliver everything, are both significant steps forward compared to fixed scope projects.
However, with today’s complex products the ordered list of PBI’s is either too small to be explicit about all the ideas that can generate the value or too large for anybody to consciously pick the most valuable ideas to develop. Pretending that all PBI’s (fine or coarse-grained) can be described in the same way and simply compared as such is an illusion.
So, how do we ensure that we are refining and developing the most valuable stuff if we have lost the overview?
We need to take the concept of the Product Backlog to another level. In this article, I will try to unfold the agile planning process into what I call the Agile Planning Circles and provide the ambitious Product Owner/team with a set of artifacts and methods that support them in reaching a much higher value creation (second part). This combines Lean Startup, Design Thinking, and Agile.
Two Common Ways to Reduce Complexity
I don’t blame Product Owners who reduce the complexity of the Product Backlog by simply limiting the size, because it is always good for enabling collaboration and transparency that ensures proper prioritization. In regard to product development, I find that it is limiting creativity and exploration because the focus gets too narrow and shortsighted for real value creation. There are usually an infinite number of options to create value, and if there are many stakeholders, they all want to see that what they care about is in the list, ie, it gets very long. Especially investors internally in your company or outside are keen to understand the priorities for the future.
Another way to reduce complexity is to see planning as a layered discipline. My first encounter with this in an agile context was in Mike Cohn’s Agile Estimating and Planning1 book. He calls it the planning onion (see figure right), and I’ve later also encountered it as the 5 (6) levels of agile planning.
The idea is that planning is iterative with different cadences from daily alignment to yearly strategic planning. It makes good sense from an agile perspective since it is iterative and the inner layers are actually in Scrum.
While the traditional Product Backlog is sufficient to contain what’s inside an Agile release, people are struggling when it comes to the product, portfolio, and strategic levels. This struggle has, in my opinion, led to non-agile practices finding a harmful way into Agile putting the fundamental agile values under pressure.
The worst two are work-breakdown-structures and a hierarchy of product owners. Let me explain:
Work-breakdown-structures comes from traditional project management and is adopted by some in the agile community as Themes, Epics, Features and User Stories or some variant of that. It leads to the thinking that to complete a Theme, all Epics within that Theme must be delivered, to deliver an Epic, all Features must be finished and so on. Doing everything before carrying on is in direct conflict with the idea in Agile that we want to deliver as much value as possible with the least amount of effort/output/code. Most value will come from a smaller set of User Stories, and it is not predictable up front which they are. According to the Pareto principle2, 80% of the value comes from 20% of the effort, so developing everything in a work-breakdown-structure will lead to a lot of waste compared to a more direct search for value.
If you are using the hierarchy of Themes, Epics, Features and User Stories, it is very tempting to map that hierarchy to the organizational hierarchy and let different people own Themes, Epics and so on. Suddenly Themes are for the C-level, Epics has other owners, eg, a Chief Product Owner, and we have reduced the Product Owner and teams to somebody who delivers on higher ranked peoples ideas. Again very far from the values of Agile and those who have witnessed a fully empowered team will know how much energy, passion, ideas are lost. The hierarchy also tends to amplify the work-breakdown-structure effect and political gaming in the prioritization process. Political prioritization never maximizes value because individuals interests set aside the customer/user focus.
Reduce complexity by empowerment
To be able to deliver maximum customer/user value, we must push decisions to where the insight is – and that is where feedback ties usage to the development effort. We must empower the Product Owner and team to work in all Agile Planning Circles in this model. Tying their release cycle with the product- and strategic planning, the latter will also be much more agile and support maximum value creation.
Below the layers of Cohn’s onion are mapped to the Agile Planning Circles (strategic to red, product to blue, release to green, iteration and day to orange). The reason for drawing them as connected circles is that each circle, not only have different cadences but they are iterating different ways around different artifacts – not all around the same ordered list. I will give you more about this in the next part.
Before I add more to the model, I must emphasize that it is a cross-functional team3 that moves around the circles together – not just the Product Owner alone, not an exploration team in one circle and a development team in another. Jeff Gothelf, the writer of the Lean UX book, has written several articles to warn against separating exploration and development4.
My experience is that there are so many synergies and opportunities for delivering more value with less effort, if the whole team collaborates, and the methods suggested in the next parts are so simple and efficient that the full team can participate.
Joining Strategy, Design Thinking, Lean Startup and Agile
Let’s start unfolding the model in further detail, going from right to left. The Iteration Circle (orange) is basic Scrum with a Sprint Backlog, with its well-known events and the team stays in this circle until release (see the figure below) This, of course, often happens (every sprint) to increase feedback from real users. If this is not obvious to you, you should go a bit deeper in the Scrum guide5.
If you use Kanban instead of Scrum and release your product several times within the timeframe of a sprint the Iteration circle (orange) of course disappears and the Daily planning circle happens directly on the green circle. If you can do that, you certainly should, since it increases the interaction and feedback from real users.
The Release circle (green) is a Lean Startup build-measure-learn circle, and I love the way that Eric Ries in his book The Lean Startup6 has made it very explicit and operational how to handle the assumptions/hypotheses about what users like and use the build-measure-learn loop to guide decisions about the next User Stories to implement. If you haven’t read the book, it’s time! I’m not going to repeat much more here.
To understand the power of Lean Startup, you must believe the facts:
- we never know what the user needs, we can only assume
- the user doesn’t know what he needs and is ready to pay for before he has tried it
We need to iterate fast with user input from something simple, to ensure we get as much value as possible while investing minimal effort.
When you have delivered the desired value, you might want to leave the Release Circle for a short while to explore a new area of your product and get realigned as a team around the future of the product. My absolute favorite method to do so is the Design Sprint by Jake Knapp7. It is a very efficient way to bring Design Thinking into the team, and I’ve seen fantastic innovation coming from those just five days. There is no need to embark on a lengthy analysis journey in the Product Circle (blue). It’s better to get back delivering to your customers and getting feedback in the Release- and Iteration circles. If you’re considering that the Product Circle should take longer time, be aware that you’ll probably be very tempted to split the exploration and development into parallel processes, and as an effect of this: split the team, introduce handovers and lower diversity in ideas and commitment in development, as I warned earlier.
In Lean Startup, you pivot and leave the green circle, when you realize from the close interaction with users that you won’t reach your goals, that you need to change your hypotheses and challenge your understanding of the market, customers, etc. A pivot might send you all the way to the Strategic Circle (red) to change your strategic direction completely, which I’ll get back to shortly. A pivot is an example that it is the PO/team that initiates strategic changes.
You will also enter the Strategic circle when you have achieved your desired goals, or you want to adjust your (product) strategy, or you might want to reallocate your capacity to other products in your company. In those cases, you will enter the red Strategic circle.
One possible journey for a team when assigned to a product is to elaborate on a strategic description in the red circle, followed by a Design Sprint (blue), start build-measure-learn (green) with releases to users (orange), and then back to green, a few new orange iterations, etc. The sequence is not fixed but defined by the feedback from users on the teams’ hypotheses. A time sequence could look like the figure below:
In my opinion, the Product Owner/team should be the driving force in all circles except the Strategic Circle (red). Here the decisions are taken across products/ the entire organization, and therefore, these must be taken by a board that spans the organization. It doesn’t mean the PO/team shouldn’t be involved and active, but the final decisions are probably not theirs to make.
This concludes the first part of this series on the Agile Planning Circles where the Refinement process was taken to the next level. In the next part, I will give you my favorite artifacts for a PO to support the Agile Planning Circles, and it will be evident how a Product Backlog will look in the Agile Planning Circles.
Part 2: Agile Planning Circles – the Artifacts
- Mike Cohn : Agile Estimation and Planning. https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415/
- https://en.m.wikipedia.org/wiki/Pareto_principle
- Søren Raaschou: http://www.managecomplexity.dk/blog/2018/06/28/agile-is-organizational-re-design
- Jeff Gothelf: https://medium.com/swlh/5-rules-for-integrating-ux-with-agile-scrum-b048babb9a89
- The Scrum Guide https://www.scrumguides.org
- Eric Ries : The Lean Startup. https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898/
- Jake Knapp : Sprint. How to Solve Big Problems and Test New Ideas in Just Five Days. https://www.amazon.com/Sprint-Solve-Problems-Test-Ideas-ebook/dp/B010MH1DAQ/