Story Mapping the Job Board
Now that the detour is over, we can focus on creating a story map for the job board. Story mapping has been around for years, but I am still surprised by the number of people I work with who have never heard of it. So let’s recap.
What is a Story Map
A story map is a collaborative planning tool that allows you to break down user stories in a two dimensional format. Jeff Patton came up with the technique to help those living in backlog hell. It’s an easy concept to grasp, you place stories in a line from left to right to capture linear flow through your application (or system). Big stories that are too big to get done in a sprint go at the top and are the User Activities. Below this line of big stories are smaller stories that break down the User Activities into User Tasks. Then underneath the User Tasks are Sub-Tasks. The sub-tasks become the stories that you implement and are estimated by the team.
Why do a Story Map?
It gives you visibility into the work that needs to be done. It allows you to “fire a tracer bullet” through the work you are planning. That tracer bullet lets you figure out what would provide the most value in the shortest amount of time. Drawing horizontal lines through the map you can group the sub-tasks into planned releases or sprints.
This stuff works: In April of 2018 my team was given a new project. The requirements were based on new laws being enacted by the State’s Legislature and the laws mandated that the citizenry would be able fulfill legal obligations on-line starting January 1, 2019. So we had a hard deadline and a new business domain the team knew nothing about. I introduced the idea of building a story map and we walked through the requirements with the analysts and the client. We peppered a wall with different colored sticky notes and after a lot of work had a nearly complete story map covering two walls of a conference room. After doing this, we realized there was no way we would be done on time. Working together with blue masking tape, we divided and grouped the sub-tasks until we identified what absolutely had to be there on day 1 (our MVP) and what could follow in subsequent releases. Working together created a shared understanding, got buy-in from all the stakeholders, and we successfully released the application at the end of December 2018.
Building the Story Map
So to build out the map let’s review the user journeys and try to find some common themes or groupings.
Now if we take those groupings we can revise the user journeys:
Notice how they both have a Join activity they will need to perform, but it’s happening at different times. There is nothing to constrain Ken from joining the job board when he is ready to apply, but Sarah needs to join before she does anything. To make things easier let’s change Ken’s Journey to align with Sarah’s.
That’s better! The blue sticky notes of the journey represent the User Activities of our story map. The items that were grouped together are a good starting point for the User Tasks. Let’s see how it looks:
This is looking good so far. We have a reasonable linear flow through the application and we’ve identified who is doing what and when. Is this perfect? No. Ken could login and register after he has already found a job to apply to, but it is reasonable. You will find that when story mapping there are times when some activities can be performed by different users at different times or other issues. That’s when the team needs to have conversations and discuss the stories and come to a shared understanding. Under each of the User Tasks we can define the User Sub-Tasks. The sub-tasks are those things the user can do to complete the User Task.
Now the sub-tasks are added under their respective user tasks. I should note that the sub-tasks, in fact tasks and activities as well, can be written more formally as stories using As a [type of user], I want [an action] so that [a value]. It’s pretty simple and I really like writing stories in this notation. So why didn’t I? First, trying to show formal user stories on all the sticky notes in my diagram would make it hard to read. Second, in real life my team found out the same thing. We did start out trying to put all that information on a sticky note before sticking it to the wall. It slowed us down and we had to stand closer to the wall in order to read it. It was better to quickly get the activities, tasks, and sub-tasks down and organized by the user so we could talk about the stories. If something didn’t make sense, we just threw it away and wrote a new one. Pretty simple. Now that we have our story map taking shape how do we decide what to work on first?
Firing a Tracer Bullet
I find the best way to get started is to “fire a tracer bullet” through the system. It is a technique to identify the end-to-end path that quickly provides value. It’s not the same as an MVP or even a release. It allows the team to build the skeleton of the application and then start hanging things from it. This approach helps mitigate risk. If a problem is encountered with the architecture it’s discovered early making it easier to pivot. Implementing the tracer bullet path may take multiple sprints, but I’ve found it is the quickest way to early success.
Ok no surprise that the tracer bullet covers the top line of the sub-tasks, but I did pull down some sub-tasks that I think are not essential in finding the skeleton of our app. I also moved the “Open Resume” sub-task up beside “Review applicant work experience”. I think it’s important to figure out early on how to upload and open files. I actually thought just leaving “Open Resume” because the resume should have all the details that the Hiring Manager needs to make a decision.
Tip from the Trench: I’m not kidding about providing value as fast as possible. About a year ago I was asked to give my opinion on another state agency’s modernization project. They were thinking of hiring a large consulting firm to do the work. This firm was all about moving the project to the cloud. I sat in a presentation going over the planned work. It was all about the tooling the cloud provider uh.. provided. There was weeks of work just to get the developers working in the cloud. Nowhere was there mention of what business value existed at the end of 3 months of work. A colleague of mine pointed that out and the firm was not hired. Even when trying new technology you must always provide value that the business can see.
Next Steps
Usually at this point, the team would look at the tracer bullet stories and start estimating them and begin sprint planning. Since I’m a team of one I’m going to move forward with event storming and maybe some event modeling.