Archive for the ‘Product Development’ Category

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.

maps

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.
Links
More on Story Mapping

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

Advertisements
Dual Track Scrum

Dual Track Scrum

This week I stumbled across an article which referenced something called “Dual Track Scrum” (see the links below). Intrigued, I researched a little more and was fascinated to discover that there was a documented process/approach to product development and delivery that was very similar to what had evolved for a product team I previously worked with.

This isn’t the first time this has happened to me. The last significant deja vu experience was when I found that there was a name for a software development approach that included: time boxing; daily team check-ins; planning and estimation as a team; work defined on a physical card on a white board; a definition of done for the time box that included all delivery activities; and a list of features that could be traded in and out if not yet started. Yes, that was the day I discovered that the approach our team had “created” to successfully deliver an off-shore project was, actually, called Scrum.

Links: