One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.
However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.
For instance:
- What part of business process, team is working on in the current iteration? The whole business flow may contain multiple user-stories and epics. By just looking at the card-wall, business flow itself may not be clear.
- How much solutioning is done for a business flow and how much is remaining?
How about having a pictorial view of whole business flow as a process-map, identifying the user-stories (work to be done) in it? Take a look at a process flow below and you find some numbers mentioned on it. They are user-story ids.
If you take a closer look, you will find that some of the user-stories like story 2 are common to multiple business flows.
By looking at process map you find some immediate answers:
- What all user stories need to be implemented for a particular business flow.
- What all business flows are impacted by a user-story? For instance in above process map, user-story 2 impacts two different business flows.
- Where are we in the implementation of a particular business flow? In above process-map some user-stories are colored with Green which indicates they are DONE.
- Along with above mentioned benefits, process flows provide a shared and common place to have conversation on business flow within team and with Product Owner and stakeholders.
While looking at process maps, I realized that Story Mapping concept coined by Jeff Petton deals with similar issues.
Let me provide a brief overview of story-mapping.
The idea of story-mapping is to groom Product Backlog in such a way that you have “big stories” (termed as “user activities”, epics or features also) at the top of map. These big stories are divided further into user tasks (something that someone does to reach a goal).
For example for an email system I might have an activity such as “managing email” which then can further broken down in user-tasks or smaller user-stories like “send message,” “read message”, “delete message” etc.
Big stories are captured on the top in horizontal fashion and smaller stories are captured underneath of each big stories.
Story maps are great information radiators. However they may require big space to capture stories of entire release. Also story-mapping doesn’t necessarily provide information on the linkage between stories or how those epics/user-stories are orchestrated together to reach a business goal. For instance at what place of the process, a particular epic is applicable and why. It’s obvious from email example as everybody knows about it anyway. However it may be difficult to decipher for domain specific user-stories.
Process maps help in solving these issues. Instead of having all stories on board, you instead put a big poster of process map embedding the user-story identifiers in it. Process-map in itself is also a narrative and helps people to come on the same page.
Though based on above discussion, it may look like that process maps and story maps are completely different concepts to solve the same problem but they are not. They are tools to bring more clarity on the board. Depending on the context, they can be used to complement each other. I personally have used process maps to come up with story maps. Eventually the combination of both looks like following which is great as you have narrative of business process and at the same time you know the functional chunks/features/epics and user-stories of the solution with story maps.
Please note that above picture is just a representation of how process-map and story-map looks together. You don’t need to go to the details of which process-map step maps to which story as that’s not the intention of this image.
Hi Avienaash. I was just thinking recently how little is discussed in the Agile community about how to manage requirements. Although there are many aspects to requirements management, the visualisation, especially in a structured way, is very important to understanding what’s happening on the project as you’ve explained here. Nice post!
@Collin. Thanks for your response. One small correction. It’s written by me (ShriKant Vashishtha). I recently started writing on agilebuddha.com along with Avienaash.
Nice post Shrikant. I haven’t heard if story maps before and it seems like a good way to help with getting cards “ready to play”. One of the areas that I have seen we have struggle with is on breaking done the requirements and planning it for you’re releases. Going to pick your brain at work.
Hi Shrikant,
in my current project we implement a business process as well – and we described our requirements as a Story Map. Each BPM activity is related to an Epic – in this way we visualized the entire big picture. To create and share this picture with the team over different sites we used the JIRA plug in ‘Agile Story Map’ here you can find a simple demo: http://bauer-information-technology.com/storymap/demo/
cheers,
Florian
Great post, Shrikant. It’s very descriptive and down-to-earth. I especially like the illustrations. One way our team has married user stories to the business flow is providing a little more info on the story cards themselves. For instance, for each iteration, we combine user stories into categories and then put the category ID on each card. We also put the high-level components (like the “activities” in your email client example) on each card. I really like your business process map, though. I may just use it for our next iteration.
Very Nice Post! And it came in a great moment for me. Thank you for the insight.
I like the story map concept particularly for pre-v1 releases, where you’re trying to describe the entire capabilities of something that doesn’t yet exist. It also helps to visualize where the cutoff is between releases.
I may have to try the business process map next time I’m building a new product, it seems useful at least as a way to generate user stories.
Nice post!
Thanks for great post! Makes a lot of sense!
One other dimension you could add to your story map are dependencies. One way they are displayed using recommendations from the Scaled Agile Framework is with red note cards and red string to show dependencies and to show which direction the dependency flows.
Great article!
Totally agree with using the combination of Process Maps & Story Maps.
However would like to point out the following:-
1. I don’t think Story Maps requiring ‘big space’ is an issue. Most places have sufficient wall space and this should not take away from doing them. You did also point out using a ‘big poster’ for Process Maps. I am an advocate for big views giving the big picture personally.
2.The Linkages between Stories in Story Mapping can be deduced by reading from left to right in a lot of cases. e.g. In Manage Contacts: updating contacts is dependent on creating contact in the first place. What people have done is to stick pieces of string between Stories to show the links in Story Mapping. Admittedly this can become a bit of a mess; so Process maps wins here for clarity.
3. Process Maps don’t point out the different releases, in your example. I guess you could draw lines around the Story Numbers; that could be a mess too. So Story Maps win on this point.
Bottom line, both types of Maps used together offer great value!
Thanks for moving the ball forward.
Kamal
Reply to 3>> Story maps and process maps do not compete with each other but complement each other.
So no need to draw lines around story numbers to get releases.
Shrikant,
Great job mapping Process with user stories. Is there a way to integrated these processes and user stories in tool such as Rally?
I was thinking of using similar concept for “Use Cases to User Stories” to address different processes for each of business groups that have the same process but different some differences (requirements).
I appreciate any thoughts you and others in the group may have regarding this.
Quite good perspective. But struggling to use it for bigger and complex systems. Will use it and give the feedback.
Nice post and a practise that we support! We use ARIS to model BPMN processes and then associate user stories to the activities. This is then published to Confluence and the user stories to JIRA where stories are tracked. We also generate the solution use case diagram from the BPMN models to estimate the development effort using use case point estimation method.
I completely agree with this concept. I’ve always said that, regardless of the software development methodology, the basis of a user story or requirements statement is the business process itself. If you don’t thoroughly, completely, and accurately understand the end-to-end business process, you can’t identify ALL of the user stories that collectively represent all the features and functions the software system should be designed to support.
User stories MUST trace to the needs of the business process. Since a user is only one participant in a business process, the user’s needs are myopic and self-serving. It’s the process that actually has the need. The user only has the need in order to fulfill his/her work responsibilities.
Once the process has been effectively defined, then either a waterfall-like requirement statement or an agile user story can be derived. And prove credibility.