Pin the maturity cards on the wall. Ask how well do we foresee the change we’re going to inflict with the planned features. “Customers will love it”, the engineer proclaims putting a few features on tree level. The sales rep sourly adds: “If they’ll ever grasp it”, moving them up into the clouds.
A first maturity tool on our list are the fields of expertise. Experts tend to rate the maturity according to their field of expertise, with different results. Made explicit, the differences can be discussed.
1) Rate maturity per field of expertise
Here are possible interpretation of the maturity levels per field of expertise:
- Market (M): How sure are the market experts, that the thing will earn enough money so the investment pays off? Stars: cool idea; clouds: there is a claim, a first business case, a promising spot on the market; trees: product positioning defined; road: gathering in-market feedback.
- Experience (X): How sure are the experience experts, that the customers have a great time when using the products? Stars: why not; clouds: there are a few solutions we can choose from; trees: we can show that customers love to use it; roads: collecting market feedback.
- Domain (D): How sure are the domain experts, that the thing will actually create a benefit for customers? Stars: just a wild guess; clouds: some estimates based on laboratory prototypes or simulations; trees: some estimates based on a prototype; road: some estimates and even measurements from usage.
- Technology (T): How sure are the technology experts, that they can do it with reasonable costs? Stars: no idea; clouds: quite confident that it can be built; trees: how to do it roughly agreed; road: built.
- Business / Strategy (B): How sure are the business experts, that this is the right thing to invest in? Stars: come back later, clouds: great thing, go ahead and invest more; trees: that fits into the overall picture; road: done deal.
- Corporate Abilities (A): How sure are the stakeholders, that the thing can be developed, produced, distributed, sold, supported and more. Stars: no idea, we’ll see later; clouds: could work; trees: We have a plan and the resources to do it; roads: we’re operational.
To make one thing clear: discussing is the important thing. And it’s really worth investing some time to properly phrase, what prevents the rating to get closer to road per each field of expertise. If this rationale is recorded, the team knows what to do next.
The fields you need depend on your situation. In the illustration above, stakeholder commitment (SH) and intellectual property (IP) have been added. In another situation standard compliance (C) or safety (S) might be topics important enough to rate them on the highest level.
2) Discuss the reasons and record them
From this discussion, deriving the overall maturity is as easy as that: take the weakest link. If the market is on clouds level and technology is already moving from tree to road then technologist might argue that the product is almost finished. But as the uncertainty of the market makes it quite likely, that a lot of changes to the technology have to be made, this perception of being almost on the road is obviously misleading.
3) The weakest link defines the overall maturity
Now having agreed on the overall maturity level, it’s time to agree upon next steps. That’s what the rationale is most helpful for. it points out what prevents the rating of being close to road. As a rule of thumb, start with the weakest link.
4) Agree on the next steps
The maturity rating can be done for the whole package delivered by a project. This gives the team and the stakeholders a good big picture on how to proceed: From stars to cloud, the most promising steps are exploratory research, simulations, mocks and throw-away prototypes that allow to quickly resolve the major questions. From clouds to trees, much things happen on choosing what exactly to do and how to do it best. It’s time to agree on and proof the chosen solution. From tree to road most of the development works happen.
5) Break it up to feature level
It’s also a good idea to rate the individual features – we assume that features are high-level requirements or epics in agile lingo – developed by a project. This allows to play a very interesting game: when do we start working on the cloudy features and when on those on tree level? What does it take for a feature to mature further? Do we implement a cloudy feature as defined or do we implement a slightly altered version that is already on tree level?
The worksheet above, e.g. done with sticky notes on a white board, illustrates the process and the result of such a release planning.
The last tool we propose in this post is maturity profiling. Here is an example. It would look great mounted on the wall right besides the product backlog.
The sketch above shows the maturity ratings at three consecutive point in times of the same project. The blue circled features were the ones the team committed to work on next. What do you think about the project’s progress? What about the fact that the project has features in the stars? Should projects have such items at all? What about F9 that when working on it more turned out to be on star level rather than cloud level? What about the most recent state, where the features are either on road level or high up and only F3 is ready for development?
What is really interesting is comparing different projects, how their profile changes over time and why. We’re looking forward to hear from you about emerging patterns!
As a concluding remark: Here are three tools a product owner can use that tie in very well with agile development. And other than the destructive approach of managing project risk, these tools constantly asks, what to do next in order to make items more mature. The levels of maturity even give hints on when to start developing the real stuff and when to use quick models to answer questions, as this discussion about planning poker shows.