Last week we had a chance to take part in a two-day workshop about “Product Owner Key Skills: Impact mapping, story mapping and valuable user stories” with Gojko Adzic.
Gojko is a well-known expert and author of numerous books. One of his books “Specification by example” is a must-read for everyone in the industry, regardless of their role.
We constantly want to learn, how to build the right thing and “product owner” is a key role in our projects. As strange as it may sound, it is difficult to motivate customers to pay close attention to their own requirements. Therefore methods that help us to find out what the customer really wants are among the most valuable items in our toolbox. The workshop was pretty much based on Gojko’s books “50 Quick Ideas To Improve Your User Stories” and “Impact Mapping“. If you haven’t already, get your copy and start reading. I also highly recommend all of Gojko’s other books.
In the workshop we learned techniques useful for managing requirements for product development and projects:
The main thesis was, that only stories that change the user’s behaviour, are worth implementing. We are so obsessed with huge backlogs, because we think, that every single thing needs a separate user story. Changing the behaviour of users is the real goal of every feature. If a feature is not changing the behaviour, it is pointless. That is true, but how to get the customer to think that way?
Rephrasing user stories is one easy way. Write user stories describing behaviour change! Throw away all the others or just re-type them to tasks. No customer really cares about setting up a dev-environment or a server etc. Just let those user-stories in the backlog which really matter. Gojko mentioned teams with only 10-15 user stories in their backlog and I can really imagine, that it works. What if you need time-tracking? Just do it with simple tasks, but never write user-stories about building a server infrastructure. According to Gojko, behaviour change is the only one thing we really have to remember after his workshop.
I would also like to remember and start using impact mapping, since it is a perfect method for pointing the customer to the real impact of a goal. We did an exercise about how a goal can change, if you analyse its impact on user’s change of behaviour. Very impressive and we will definitely take a closer look at it. I can imagine it to be really useful when requirements are thrown “over the fence” without a clear example, how it changes the world of the user. Wasting time for pointless features shouldn’t be an issue anymore, if everyone in the team – including the customer – knows, what the impact of a feature is and it should really give everybody the motivation to implement useful features. “Useful” always means “changing behaviour”.
Measurement is another very important part of a product owner’s work Gojko pointed out the following questions we should ask about measuring and milestones:
Among other questions, the important one is “what is the current state?”. In our and Gojko’s experience, it is often difficult to establish what the current state of a project is. It is crucial to start measuring things from the very beginning of the project . Every goal must be measured and for every goal a failure level must be set. As Gojko put it, it is easier to know if you failed than if you succeeded. Another good advice was that setting intervals for goals is much better than setting fixed values. Often it is “good enough” to reach a “more or less” level. The lesson for our work is, that for every project we will put more emphasis on clarifying measurement with our customer and with our teams. Answering the questions above will also bring us to measure the “right thing”. My favourite statement is “you easier get to know if you failed than if you succeeded”.
Part of the workshop were strategies for managing requirements in different environments as you can see in the following picture:
From that quadrant we can choose how we can achieve more according to customer processes and situations. It is particularly helpful for us, because we often have to carefully introduce change in projects without disturbing the overall process. I think this one will also be among our top 5 from now on.
Splitting opportunities for user-stories was another very interesting topic. We learned how to encourage the customer to accept, that solving smaller problems leads to better products. This is not new, but it’s always hard to explain, why customer’s expectations can be better fulfilled iteratively by splitting and experimenting. For example, when we can reduce the effort of building a huge dashboard and just show the data first in an Excel diagram to demonstrate to the customer, what the end result could be. It is again about changing behaviour. If we see, that the behaviour changes for the better, we can still implement the full solution. The picture below shows, which kind of splitting opportunities we have:
We also learned how to use user-story-maps in the right way. We have used them in the past but were not very happy with the results. Our mistake was, that we tried to build ONE map for everything. Gojko’s advice, building maps for personas is the one thing we missed. That will improve our process and will probably be the next thing we will use in one of our projects to build user story maps the right way. One piece of obvious advice was, to sell the problem first and not the solution. That is particularly true in our daily live. Discussions too often tend to be about solutions without finding out what the real problem is. We really need to improve customer communication and always ask, why we need to implement something we do not really understand. I bet, we will find out, that the problems are not the ones, we are trying to solve. Changing behaviour and solving real problems is a no-brainer but you need to remember that every day, all the time. Talking about solutions (especially on the technical level) is fun but completely pointless. We should not accept “solution designs” we get from customers, without repeatedly asking “Why?”. In the end it is all about the users.
The two days were fun and we’ve learned a lot. The most important lessons for me are:
Thanks to Gojko for another opportunity to improve what we do.