Six Tips to make Story Mapping more effective

Story Mapping is a practice that helps you experience a customer or user journey. You would first capture the end-to-end customer experience by asking what would a user do? This includes establish a backbone, steps, and options.  

The story mapping process promotes the team to think through elements of what the customer finds as valuable from a process perspective. It moves away thinking of functionality first and instead advocates thinking about the customer experience first.  Then you would use an incremental approach of building, inspecting, and adapting for the next increment. What might be some tips to help you more effective work through a story mapping session? 

Tip #1 – Craft your Persona (aka, customer)

Draft the persona that will be taking the customer or user journey.  Place the persona at the top or head of the story map. This provides empathy for the user and inspiration for those that are attempting to craft the journey through the eyes of the user (via the story mapping practice).  Learn more about personas at Personas - Getting to really know your Customer.  

Tip #2 – Everyone stands up around the story map

As simple as it sounds, have everyone working on the story map session stand-up and around the story map as they are creating it. This keeps everyone engaged on crafting the story map.  

Tip #3 – Everyone writes options

When it comes time to imagine options for each step along the customer journey, provide everyone with a post-it pack and marker.  Ensure everyone knows that they should put up the option ideas as they think of them.  This gets lots of options up quickly. This also reduces any single threaded thinking where only one person is doing the writing.  

Tip #4 – Promote lots of chatter during Affinity of options

After a number of options are written by a number of people, it is time to determine if there are affinities.  This is a good opportunity to promote conversation for understanding the customer journey together as each option is discussed.

Tip #5 – Ask owners of options if they are similar

If two options are similar, ask the owner of each to determine if they form an affinity.  Often times when there are similar options on post-its, those that didn’t write them speak up to discuss if they are indeed related. Instead, those that wrote them should determine the affinity (or not) as they would know better.  

Tip #6 – Use verb/noun

Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). This helps with understanding the expected action for each step of the user journey. 

You can learn details of executing a story mapping session at Story Telling with Story Mapping.

Worth Reading: The Agile Enterprise: Building and Running your Agile Enterprise - for better business results

Imagine an enterprise where everyone focuses on the highest customer value.  Where strategy to tasks are visible so everyone knows if their work is aligned with the highest value work. Imagine an enterprise where a discovery mindset wins over certainty thinking. Where experimentation with increments and feedback help define the way toward customer value.

Imagine a company where employees use 100% of their brain power to self organize around the work and be trusted to think of better ways to work. Where leaders encourage employees to put customer value first.  Imagine an enterprise where customers embrace the products and services being built because they are engaged in the building of the work all along the way.

If you can imagine it, it can be yours!  In this unique and cutting edge Agile book, veteran Enterprise Agile Coach Mario Moreira, will guide you to build and run an Agile enterprise at every level and at every point from idea to delivery. Learn how Agile-mature organizations adapt nimbly to micro changes in market conditions and customer needs and continuously deliver optimal value to customers.  Learn cutting-edge practices and concepts as you extend your implementation of Agile pervasively and harmoniously through the whole enterprise for greater customer value and business success.

Readers of The Agile Enterprise will learn how to:

• Establish a Customer Value Driven engine with an enterprise idea pipeline to process an enterprise’s portfolio of ideas more quickly and productively toward customer value and through all levels of the enterprise
• Incorporate the Discovery Mindset; experimental, incremental, design, and divergent thinking; and fast feedback loops to increase the odds that what you build aligns more closely to what customer wants.
• Leverage Lean Canvas, Personas, Story Mapping, Cost of Delay, Discovery Mindset, Servant leadership, Self-organization, and more to deliver optimum value to customers
• Use continuous Agile Budgeting and enterprise idea pipeline at the senior levels of the enterprise to enable you to adapt to the speed of the market.
• Reinvent Human Resources, Portfolio Management, Finance, and many areas of leadership toward new roles in the enablement of customer value. 
• Establish a holistic view of the state of your Agile Galaxy from top-to-bottom and end-to-end allowing you to understand where you are today and where you’d like to go in your Agile future.
• Be truly Agile throughout the enterprise, focusing on customer value and employees over all else.

This book is geared for: Sponsors of Agile Transformations; Executives and Senior Management; Agile Coaches, Consultants, and Champions; Portfolio Management; Project Management Offices (PMOs); Business and Finance; Human Resources (HR); Investors and Entrepreneurs; Scrum Masters, Agile Project Managers, and Product Owners. 

This book concludes with an adventuring through an Agile Enterprise story that shows you how an enterprise may transform to Agile in an incremental manner with materials in this book.  Let the material in The Agile Enterprise help you achieve your successful customer value driven enterprise.

Thank you to the contributors JP Beaudry (on Story Mapping) and David Grabel (on Cost of Delay)!  A special Thank you to the Apress editing team!

User Story Writing Starter Kit

Prior to Agile coming into existence, I was fortunate to learn how to write requirements by Elemer Magaziner (i.e., business requirements) and Alistair Cockburn (i.e., use cases).   They provided various alternatives to writing clear requirements that were irrespective of methodology.

 

From this I learned that there is a strong benefit to establish what I term as the “requirements language construct”.  This construct helps you consistently document your requirements focusing on key requirements elements. One common requirements language construct in the Agile world is the canonical form. It is important to realize that elements of the canonical form have been around for years.   With that being said, the three basic elements of the canonical form provide a good framework for establishing requirements. 

First I will discuss the user story that is typically expressed within the three-part canonical form.   Then I will introduce the enhancement of a requirements language construct that can adapt the canonical form.  The language construct for a user story in canonical form looks like this:

The persona is the user type who will receive the value.  The action is what the user type desires.  The business value is the benefit to that user type.  Note: you can learn more about personas in the article Personas – Do you really know your Users?   The following are examples of user stories in canonical form:

• As a learner (persona), I want to set up my profile to include my photo (action), so that my distributed team members know what I look like (business value).
• As a prospective buyer (persona), I want to search on homes (action) so that I know what properties are available in my price range (business value).

As enhancements to this construct, you may consider adding the system that will be used or interacted with and the receiving entity which identified the expected output from the requirements.  If applying these, the requirements language construct would look something like this:

As a (persona)

I want (action) from (system) to the (receiving entity) 

so that (business value)

The following are examples of user stories with these enhancements.  The first example below takes the second example from above and enhances it with the system and receiving entity.

• As a prospective buyer (persona), I want to search on homes (action) from MLS (system) to a separate window (receiving entity) so that I know what properties are available in my price range (business value).
• As a quant analyst (persona), I want a derivatives report (action) from the asset management application (system) in the form of a pdf (receiving entity), so that I can distribute it to my fund managers (business value).

There is no “right” requirements language construct.  It is important to craft one and then experiment with it.  I would suggest starting with the canonical form and work from there. 

Finally, the Product Owner, Business Analyst, Product Manager, and anyone who writes requirements should be trained in writing user stories in whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. You may also want to train stakeholders and customers on how to provide their needs in your requirements language construct for consistency and clarity. 

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 18 of Being Agile. 

Personas – Getting to really know your Customers

When you are building your product, how well do you know your customers?  Can you visualize who they are?  Do you understand their motivations?  How do you know you have requirements or user stories for all of the various customer types that you have?   By knowing who your personas are for the product or solution you are building, can help you answer these questions.   

Personas represent specific users and act as examples of the types of users who would interact with it. Most products have several personas that use the product in different ways. Examples of three personas for a product are the regular user, power user, and administrator.

• The regular user uses only the basic user interface functionality.
• The power user needs more detailed interface functionality to handle more sophisticated work.
• The administrator needs back-end installation and maintenance functionality.

All three use the product differently, and different features are built for their respective needs. Personas are a powerful way to guide your decisions about functionality and ensure that you are, in fact, building functionality for each persona. Personas are a key ingredient in the way that user stories can be presented. Including the persona in a story description provides you the point of view (POV) of a user story and defines who that user story is for.

I recommend that you establish a description for each persona. This description is typically illustrated as a fictitious person that represents a real role. It will include the knowledge, experience, and activities of that role. By writing a persona as a fictitious person with a name, this makes the persona easier to imagine and relate to, as in the following examples.

Consider establishing personas for your products so that the functionality can be better understood and help you build a product that better aligns with your customer needs.  Finally, personas offer four distinct advantages. 

• The team understands the users better, which helps guide decisions about the functionality they need. 
• User stories can be written to include the persona to ensure the personas have requirements suited to them. 
• Testers can create acceptance tests and use cases that support personas. 
• Based on their personas, the Product Owner knows who can give the best feedback and therefore whom to invite to the reviews or demos.  

You can read more about Personas in the book entitled Being Agile in Chapter 17 in relation to customer reviews and demos and Chapter 18 in relation to writing effective user stories.