Mike’s website

One of my favourite product management books is User Story Mapping by Jeff Patton. 

The technique of story mapping, especially when working with a group works best with a heap of post-it notes and a big wall, however when working with a distributed team or when organising your own product thoughts a digital story mapping tool can come a close second.

I recently came across a forum post asking for a recommendation for any great tools for user story mapping, so here’s my recommendation .

Of the story mapping tools that I have tried, storiesonboard.com is my favourite. It strikes a good balance between being quick to enter new stories, fairly easy to navigate and also integrates well with other tools such as Jira, Trello, Azure Devops and others.

Unlike other story mapping tools that I have tried, adding new cards, dragging them around and navigating the screen are pretty painless. This is probably largely down to stories onboard being focussed on story mapping, rather than trying to be a more general white boarding tool such as Mural or Realtimeboard.

Where a digital story map comes into it’s own, and one of the few reasons to use one over a wall of post-its, is when planning how to release the work. The ease of re-ordering stories, breaking them down to be more granular and splitting steps of the user journey up is so much easier in a digital tool. Equally creating horizontal slices across the map to plan out releases, dragging stories up into those releases to define the scope of that release, and making it super clear what is and is not in scope right now is again far simpler than in any other tool.

I also really like the two way sync with other apps like Trello (I have only used it with Trello), sending a batch of cards to Trello and updating the status of the cards on the map as tickets are moved across the Kanban board is great.

If I could change anything about Stories on Board then I’d really like to be able to add realtime collaboration, whilst you can share the map with other users, being able to all work on it at once and to see the changes that other users make in realtime would be super powerful.

A recent addition has been the personas feature, and as a not exactly massive fan of personas I’ve not used this myself, I’d rather see more information written into the story description and acceptance criteria about who needs a feature and why.

So there it is, stories on board is the best story mapping tool I have found, this is one of the few work tools that I pay for out of my own pocket as I like it so much.

There are loads of great books out their for product managers, some very tactical and some thought provoking. Here’s a list of my favourites that I come back to again and again.

No affiliate links as I don’t know how to do that.

Badass: Making User’s Awesome
Kathy Sierra

Kathy Sierra’s beautiful book reminds us all that ‘Customer’s don’t buy your product, they want a better version of themselves’. If you are involved in the creation of any kind of product this is a reminder that your users and customers are trying to get shit done, and your product is there to help them be better at that. Full of thought provoking advice on how to structure the user’s journey to help them become better at the work they are trying to do.

Watch Kathy speak at Mind the Product if need you convincing before buying.

User Story Mapping: Discover the Whole Story, Build the Right Product
Jeff Patton

Masquerading as a book about a specific technique (which it is) Jeff Patton shows us how to work through the messy business of synthesising all the suggestions, ambitions, ideas and feedback that come together to make or develop a product and to bring focus back to helping the user achieve their goals.

User story mapping might just be the best book I’ve read for helping to make plans more clear, gain consensus and shared understanding between development teams and customers, and to unambiguously show what is in the next release and why.

Watch Jeff on Youtube to see him teach this technique in a class setting

Running Lean Iterate from Plan A to a Plan That Works
Ash Maurya

If you read the Lean Startup and were after some guidance on how to apply those principles in a more structured way than throwing shit at the wall to see what sticks, then this book is for you.
Ash Maurya’s Running Lean outlines an excellent framework for identifying and testing the biggest assumptions and risks hiding in your plans, and working to eliminate them or learn from them.

He proposes a process to identify a problem worth solving and to collaborate closely with customers as you iterate towards a solution that meets their needs. His lean canvas, based on the excellent Business Model Canvas provides an alternative way to quickly summarise a product plan and to work to identify the riskiest areas that needs addressing first.

Hooked – How to build habit forming products
Nir Eyal

Nir Eyal’s Hooked describes a model by which products become habits and proposes a process to make a product more habit forming.

You could argue that habit forming products are something that maybe we should be striving to avoid creating, but nonetheless this is an eye opening look at how some of the most popular apps of recent times have worked their way into our consciousness, and what keeps users coming back.

Crossing the Chasm – Marketing and Selling Disruptive Products to Mainstream Customers
Geoffrey Moore

Any oldie but a goodie, in Crossing the Chasm Geoffrey Moore teaches that the thing that made a product appeal to those early adopters is not necessarily going to help get more mainstream adoption. 

He outlines a strategy to focus on a specific market and to become the defacto tool in that market before attempting to cross the chasm to more mainstream users in the same industry.

Required reading if you are aiming to build a product to serve a broad user base.

Turn the ship around! A true story of turning followers into leaders
David Marquet

Not about product management itself, but an excellent parable about leading a team to get the benefit of their collective knowledge and abilities. David Marquet was assigned the unenviable post of commanding the worst performing nuclear submarine in the US Navy. The story of how he lead his crew to become a team of leaders, not followers is accompanied by guidance on how to apply his principles to other organisations and teams.

Bonus Points

Confession, I have not yet got to these two, they’re on my reading list since so many people recommend them

Escaping the build trap
Melissa Perri

Having seen her talk at Agile on the Beach I know that Melissa has some great insights into how to focus your product management efforts on achieving great outcomes for customers, rather than focussing on shipping features.

Inspired –  How to create tech products that people love
Marty Cagan

Given that Marty is referred to by many as the most influential person in the product space, I should have read his book by now. Frequently recommended by Product Managers everywhere so join me in adding it to your reading list

What have I missed, and which books have you added to your reading list recently?

When writing a user story for development team, the acceptance criteria are the oft overlooked part that can make the difference between whether what is built does what is needed, or not.

We’ve all seen vague user stories that say something like:

As a patient:
I want an appointments screen
So that I can make an appointment

That might be enough information to get some sort of functionality but not necessarily something that works the way that your customers need it to, or that handles all the ways that this screen might be used.

What you need are some acceptance criteria for this story…

What are acceptance Criteria?

The acceptance criteria are the criteria agreed by the team and the product owner that will be used when the story is complete to agree that it can be signed off.

Why do we need them?

A good set of acceptance criteria makes it super clear to everyone on the team what this story covers, anything not included in the acceptance criteria doesn’t need building.

Having a clear scope of exactly what is in the story makes estimating the story simpler, if that is something you do, and makes writing test cases simpler as well.

A story without clear acceptance criteria can devolve into a more complicated piece of work, with important scenarios being missed, and superfluous features being included.

What makes a good one?

A good set of acceptance criteria describes the situation that we are addressing for the user, and the results that we expect from different actions. These are written as a number of scenarios, each with an unambiguous action and outcome.

How do we use them?

Each scenario should be discussed with the development team (and stakeholders if necessary) prior to the team starting work on the story. If the team aren’t clear on each scenario and what it is trying to achieve then update it with them until there is a shared understanding of what needs building.

When it comes to reviewing the completed story each of the scenarios in the acceptance criteria is used to sign the story off. 

If the resulting work doesn’t address all of the acceptance criteria then don’t sign it off.

If the complete story is missing something that was not in the acceptance criteria then the acceptance criteria is what is wrong, not the development

Show me how to write one

There are loads of different ways you could write these, my favourite is to use the Gherkin style from behaviour driven development. Written as Given, When, Then.

The format goes something like this:

Scenario name:
   Given the initial state
   When an action occurs
   Then a thing will happen

Here’s an example from a user story, “As a patient I want to book a doctors appointment online so that I don’t have to wait on hold on the phone”

Scenario: Logged in user views appointments
   Given that I am signed in to the surgery website
   When I choose to make an appointment
   Then I will see a list of available appointments in the next 48hrs

Scenario: Non logged in user views appointments
   Given that I am not signed in to the surgery website
   When I choose to make an appointment
   Then I will be shown options to login or register

Scenario: User Selects an available appointment
   Given that there is an appointment available
   When I select a specific date and time for an appointment 
   Then I will be asked to confirm the booking

etc.

Notice that these acceptance criteria do not talk about what the button looks like or what it says on the button or how the appointments are presented.  This is not a UI design spec. These are about the journey that the user may go down to get their job done, and the scenarios that they may encounter on the way.

That’s not to say that you couldn’t write every list detail of what happens when you click on a dropdown or submit a form, but you’d end up with way too many scenarios, even for a very simple story.

In more advance development organisations your testers or developers may use these gherkin tests to form the basis of automated testing, but even if that’s not something your team does this way of documenting behaviour remains powerful and unambiguous.

There are more complex rules that you can add into your gherkin to capture more complex scenarios, but this basic set get you a lot way towards clear unambiguous acceptance criteria.

Read more about Gherkin here: http://docs.behat.org/en/v2.5/guides/1.gherkin.html