[MUSIC] Welcome to the next lesson of the client needs and software requirements course. In the last lesson, I talked about the scrum product backlog and how it can be used to prioritize and organize expected work.

In this lesson, I'm going to talk about another tool which is used to organize your requirements, the Story Map.

Story Maps are a great way of representing your products' backlog with more visual detail.

When it comes down to it, a Story Map is just a method for taking user stories from your backlog and grouping them into more specific functional categories.

Here's an example of how a Story Map might look.

Say you're developing a simple email program, your client gave you a list of requirements which include user stories like, as an author, I want to compose text-only messages with a recipient, a subject line, and a body so that I can direct and convey the content of my message in a basic way.

As a reader, I want to be able to open emails when they're received so that I can read my most recent messages.

As a reader, I want to be able to store messages in an archive so that I can keep messages for future reference.

As a reader, I want to be able to search for messages in my archive so that I can quickly find relevant messages without manually browsing for them.

As an author, I want to be able to attach files to my messages so that I can add extra information to my messages.

As a reader, I want to be able to open any attached files on my messages so that I can view the extra information on received messages.

You might already be able to see how these stories could be grouped together.

You could use the product's basic functionalities as category headings. The basic functionalities here are composing and sending, reading and receiving, and storage and searching.

So if you dropped each story into its respective category, you can immediately see what fits where and what might be missing. Then, the client could prioritize these stories within the categories as they see fit.

Now all of a sudden, a potentially daunting list of requirements becomes a manageably organized set of features to be implemented.

Now that you've seen how a Story Map is created, think for a moment about what benefits creating a Story Map might bring to your project.

Please select the answers which you think reflect the benefits of a Story Map.

A, saves time in the initial planning stages. B, simplifies prioritization. C, gives you an overall view of how the project will develop. And or D, provides a detailed development plan.

The correct answers are B and C. The Story Map simplifies prioritization and gives you an overall view of how the project will develop. We'll talk about that next.

It doesn't save much in the initial planning stages. But it could save time later on down the road.

And remember, the Story Map is not a development plan.

Those are a few benefits of the Story Map. What other improvements does a Story Map offer over the classic product backlog? The Story Map offers a lot of improvements onto the classic product backlog.

For one, it gives your backlog a more trackable, visual feel.

Instead of trying to keep track of the priorities of one big list, you're forced to break things down into categories.

Another improvement is that it gives you perspective on how individual user stories relate.

Instead of dealing with the pile of prioritized requirements, the Story Map allows you to see how these requirements fit together.

By being able to visualize the links between your requirements, you can really easily see if there's something missing. It's easy to see if there are any holes in your requirements and then fill those holes accordingly.

Another great benefit to the Story Map is that it gives your developers an idea of how the product should be built as a whole.

A lot of products have multiple categories or functionalities which could be considered main functionalities.

In the classic, one-dimensional product backlog, it's easy for user stories from one functionality group to outweigh user stories from another.

However, with the Story Map, all user stories in the top row of the map take on the same level of importance.

Not only does it simplify things when it comes to prioritization, it also gives you an idea of what your product does at each pass.

If you consider each horizontal row to be a release of your product, then you can see how the product would evolve and grow as you move down the map, row by row.

So in the example I gave earlier, your product might go from only supporting text based interactions to supporting the transfer of multimedia files.

You don't build your product by focusing on only one category. The Story Map makes sure that you focus your effort evenly across functionality.

Instead of building the functionality in one category, which may not satisfy your client entirely, the Story Map gives context to your developer's work.

It shows that simple functionality may best be implemented before moving on to more complex work.

You wouldn't build an email system which can send emails using multimedia and text, but have no way of reading them.

The Story Map provides the context which is sometimes required to see those dependencies.

This is a great example of the agile principle of building working software in action.

Instead of building an arbitrary list of requirements, you're actually showing how the whole product would fit together at excessive stages.

If you took our software process and agile practices course before this, you would have seen what a Kanban board looks like.

I want to specifically point out that a Story Map is not an alternative to, or a substitute for the Kanban board.

Kanban is a way of displaying your project's current state and tracking progress on tasks. A Story Map is a way of planning and organizing user stories in a two dimensional structure.

Actually, you can use both a Story Map and a Kanban board together in unison to plan and track your projects, it's certainly not unheard of.

So at the heart of it, a Story Map is just a method for making your requirements better.

It gives context to each individual requirement in your project and brings a greater amount of organizational structure to your project.

Story Maps, of course, still support the inevitable change in a software product. You could say that they support change even better than the classic product, backlog.

They gave your developers and your clients a sense of the products entirety, offering a quick idea of how things fit together.

In the next module, Morgan is going to talk to you about more ways in which you can improve your requirements. You're going to learn a lot, so I hope to see you there.

3.3.5: Story Maps

Client Needs and Software Requirements

Meet the Instructors