Posts Tagged ‘product discovery’

I recently attended the regional Scrum Gathering for 2015 in Johannesburg. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions.

First, watch this video about making toast.


I really enjoyed the workshop on story mapping. Sadly, I still feel that although I ‘get it’ at a theoretical level, I still cannot see easy ways to use it in practice. It seems harder to create a map than it looks!

Suggested approach to creating your story map:

  1. Create a vision (e.g. using the Business Model Canvas)
  2. Write up the process or map (as described in the video). Think about the various user roles.
  3. Explore the map with questions. “What if…?” “What about…”?
  4. Group your activities to form a backbone. Focus on breadth and not depth. Consider the goals for your user personas.
  5. Slice your activities into outcomes based on your persona goals.
  6. Build your development strategy (order in which you will release)
Other notes
  • On average, you will usually identify about 15 user roles. These can usually be combined into about three user personas.
  • Unless you are working with a mature product in a stable environment, your road-map should be about delivering goals and not features.
  • When building your development strategy, it usually makes sense to build your high value, high risk items first.
More on Story Mapping

Have you tried story-mapping? Was is successful? What worked for you? What did you struggle with?

These are some tweets I made while reading “User Story Mapping” by Jeff Patton.

It’s a great read that I highly recommend!


How inspirational!







I like this because it can be applied regardless of the type of product you’re delivering or product life-cycle stage you are in.




If you have the book, I’m referring to the picture on page 71





A.k.a. an organisational profile




Grooming ideas



Grooming to envision a product that is valuable, usable and possible to build.












Grooming to plan your development strategy. Intention is building what you need to learn the most, first.


Grooming to plan your next development cycle (sprint).


In a recent retrospective, one of the developers raised that there wasn’t always a clear understanding between what we were doing at a sprint level and the real value to the business. It was felt the delivery team was lacking some of the business context. As a result, during our next retrospective, we evaluated the Product Savvy pillar of agile (one of seven you can rate as part of an agile spiderweb retrospective).

After reading and discussing the points related to the pillar (see below), I asked the team to rate themselves out of five. Our average came to about 2.7 which made it clear that the team generally felt we were not doing well in this aspect. We bounced some ideas around and came up with a couple that we thought were worth trying out, including:

  1. Learning more about the business context by having our in-house client services staff (who were also users of our system) come and chat us through common issues they experience when dealing with customer queries.
  2. Make business value more visible through things like business value points on epics, up-front metrics for success to rate against, and getting a better grip on how to access and ‘read’ Google analytics.
  3. Understand our users better through listening to recorded calls, sitting with customer service users for a period to observe real life calls, and sharing generic user feedback or research results in our weekly knowledge sharing sessions.
  4. Know where to find information about design or implementation decisions that the team made in the past (and make sure to still capture those decisions and reasons).
  5. Get better at asking or telling others on the team the ‘why’ i.e. if you’re conveying information, remember to include the why. If you’re working on some task and don’t know the why, then ask someone who can tell you.
  6. For bigger epics that are still being broken down, have at least one developer involved from the very beginning.

There were some great ideas, but obviously we couldn’t take on everything! As it turned out, our Product Owner was already planning on defining metrics for our future work and our architect was intending inviting business to share more with us during our weekly knowledge sharing sessions. As a team, all except the analyst (who takes time to meet with business on a regular basis anyway) felt that taking one hour out of the next sprint to shadow someone from client services would be useful. This is the action we took forward and we’ll discuss what the team learned at our next retro.

Take a look at the pillar below: how product savvy is your team?

 Product Savvy Agile Pillar Characteristics

Product Savvy Slides