The final step is to look at the User Story Map from the perspective of the activities that our user is carrying out.

Look across the top line of the narrative and you'll notice that tasks can be grouped under a title which defines the activity being carried out by our user.

For example, take a look at the following four tasks in the timeline:

They all relate to a specific activity: buying an item. In this case, our user will DECIDE TO PURCHASE STRAIGHT AWAY, so they might click a button which says something like Buy Now. This is just one way that our user could purchase something from our website.

In future, we might implement a shopping cart, so they can purchase multiple items from us in one transaction; we might also implement an Add to cart function. If we name this activity BUYING ITEMS, when we talk about alternative paths for purchasing an item, we can frame the discussion around this activity.

We annotate the User Story Map so that it looks like the following:

The BUYING ITEMS post-it is placed over the timeline above the task which starts that activity. 

We can name the other activities in the same way, placing the activity's name over the first task in the sequence. The timeline would look like the following:

Each activity ends where the next begins. The last activity ends when the timeline completes. Some activities only have one task in the timeline from left to right; others have multiple tasks in the timeline, indicating that they are multi-stepped. 

Naming the activities gives us the flexibility in the future to talk about the things our user does without prescribing the tasks specifically. This means we'll be less likely to prescribe solutions and can keep the team focused on the why instead of the what.

Each activity in our User Story Map will likely translate to a feature in our Product Backlog (features are large User Stories, also commonly referred to as Epics). Tasks and sub-tasks, with refinement, will translate to User Stories.