In our current project, a software for managing sports events, user stories play an important role when it comes to development. Interestingly the focus of the requirements conversation changed completely from one level of maturity to the next. And there is a pattern behind it, as it seems. It leads to user story mapping.

Lets just start with the essence first. Explanation and examples follow.

Grok – negotiate – build-up

The first thing we did in our project was trying to understand our customers and their needs. We did two things to do that: One, we talked about what the users do, how they do it and how they would want the future to be different. We went to their workplace, collected and analyzed the artifacts they use. This knowledge we captured in process maps. Two, we drafted possible solutions. We visualized the solutions mainly in sketches of user interfaces and used this to talk about work in the future. The two things together basically started the feedback loop with our stakeholders where we were able to spot what is really valuable! And yes, this is the key for user stories on this level: Grok the value.

Sadly, the user stories we created contained a lot of great ideas. Well this isn’t the sad part of course. Tears we wept once it became clear that the available budget would not allow to build all the wonderful things we imagined. Not really surprising actually. That leads into the next stage of maturing. The negotiation between the things that can be easily built and the things that bring a lot of value.

Just to give an example: Our customers love excel. Actually they hate it. Well they love Excel’s flexibility to arrange and filter data and the powerful editing tools but they hate that data once in Excel is not synchronized with all the other excel sheets and the database and that they have to manually update all data sources and that they need to update them even more often when an event is closing in and when they are loaded with last minute errands. In fact it almost kills them. They love Excel.

Well how great would it be to have an excel front-end to our system? It would offer all the great things our customers wanted with easy synchronization! Well we have a prototype running that achieves it by exporting to excel and re-importing afterwards. Alas, importing needs to be implemented for each usage case. This is just beyond budget. In addition, we wouldn’t be able to deal with images. We do manage images of e.g. the athletes in the database but excel just doesn’t seem to cope well with images. To be frank, in most cases, images are irrelevant. So drop images and it’s still a very fine thing. What if instead of re-importing we would update the data in our system and then users could reload the data in their Excel sheets? The process of negotiation just started and we’ll need a bit more thought to come up with a solution that fits the budget and offers great value.

The stories that passed this stage of maturity face their next challenge. Because we do not burn our money down. We build our product up. We build it up first per business scenario – e.g. the registration process to vote for officials or to organize a specific type of sport events and others. When we start implementing the scenario, the stories that offer a good value are stripped down to their bare essentials. And in the first iterations, we build just the bare essentials. The next iterations will then focus on adding those functions that provide the most additional value to our customers. This process stops when our customers are happy enough. And that will, we’re still optimistic, happen already before the budget is used up.

The first stage is run mainly by people that are near the product owner role in Scrum with some involvement from the development side. In the second stage, at least senior developers join fully in the negotiation. In the third stage, the development team is involved as a whole, well obviously.

User story mapping to support the process

The tool to support this process is user story mapping. The image below shows one of these. The orange stickies are the activities, the green ones the user stories. The stickies above the wireframes are the bare necessities, quite detailed already as we are already implementing. From the eight iterations, we want to spend maybe four on these stories. Below the wireframes are a mixture of stories that we need to add for the minimal viable solution and stories that are more like gold-plating.

Ignoring grok – negotiate – build up leads to defects

Quite a few defects in projects today can be explained with the pattern grok – negotiate – build-up. Here are three of them:

• Some project team completely ignore the first stage and build software nobody really wants to use. Some needed features may be there, but they’re made the wrong way. Projects driven by technologists are quite likely to suffer from this mistake.
• Projects generally fail with building up. Everything requested gets build and a lot of money is spend on things not worth it. This is especially likely to happen when price, budget and scoped are too tightly fixed. The outcome is a project at the end of time and budget where crucial functionality has not been built while the team worked on gold-plating some features. As it is, there is no way but to add more time and budget into the project.
• A very common defect can be found in project teams, where business analysis and development are separated. The business team then delivers a detailed specification (which is actually on cloud level) and the development teams waits forever for clear requirements (i.e. on tree level). These teams miss persons that do the negotiation bit and bring the specification from clouds down to tree. Phrases like “the requirements where not clear” or “they don’t know what they want” or “the lazy programmers just don’t want to work” and more usually point just to this defect.

Something like a summary

So, stories pass three stages: from stars to clouds, we try to grasp what is really valuable to our customers. From clouds to trees we negotiate a solution that provides great value but is within our budget. From trees to road we build up the solution from the bare necessity so that we can stop as soon as it is desirable enough for our customers. All that just to spend the money in a way it provides the best value.