The challenge awaits our project: How to deal with the many expectations from our customers that are far beyond the project budget? The answer in my current project – the sports event management system – is based on user story mapping. 

This third article (see part 1, and  part 2) starts with user story mapping and introduces the story shop, a place where stakeholders shop for the user stories.These two powerful tools make staying within budget while developing the things that really matters for stakeholders somewhat easier.

Recap of the first two articles

Some background info about the sports event management system we’re building:

• Our users are experts driven by the one common goal to deliver the perfect show to the spectators on-site, in front of the TV, and over the internet.
• Each sports event is different and just following a detailed process will not result in the perfect show. Tracking more than 2000 activities, being well prepared and able to react to whatever happens is what our users need to do.
• To organize an event with perfection, the organisation, over time, developed skills, e.g. awarding the athletes, market an event and more. We documented such capabilities, at least the most relevant ones for us.
• The better our software supports the experts in their day to day work, the more successful our project is.
• The base for project planning is a feature portfolio. Each feature is described with more details in something we called a one-pager.
• We estimated the portfolio with t-shirt sizes, compared it with the budget, realized that we had to descope a few things and now have a overall scope that seems realistic.

How to cut the elephant

The budget allows for about 60 person years of effort. To be frank, we have no idea how to manage this kind of budget other than by applying good old divide and conquer. Thus we looked for ways of splitting the big project up in parts and found one that so far seems to be appropriate: We split the project by business capability. This way of splitting up seems to work nicely because:

• Our process maps show the capabilities and we have the needed information to actually go that way.
• Capabilities represent business building blocks with their very own feature set – well, mostly. There are basic things to be build, like user management, common data cleaning functions, generic features like running a survey, sending emails, and more. We simply added them strategically to the capability oriented features. Still, it allows focusing on just one chunk and ignoring the rest.
• Each capability has a quite specific set of stakeholders. Thus per chunk, we have significantly fewer stakeholders to involve than for the whole project.
• Capabilities are even distinct enough so that we can  have a release per capability.
• We distributed the available money accordingly. Thus we have a couple of smaller projects with a fixed budget each.

In combination, cutting by capability, in our case, allows for small and agile teams with a fix budget, fix time and a variable scope for each release and helps us not to spend too much money in the first stages of development.

We only have to find out how we provide the best value given the team, the budget and the time frame to our stakeholders per chunk.

Build up the new system

We manage this with user story mapping. Really, if you haven’t, you must read Jeff Patton’s post about this. In our project, we take the rough steps of the end-to-end process behind the capabilities as the backbone for the user story map. Then we populate the map based on the features selected for the capability.

The user story map pictured below is build with sticky notes. The orange ones on top are the steps of the end-to-end business process. The green ones are stories. In this stage, we had the wireframes of the user interface aligned with the process and they separate the bare necessities from the stories to be shopped later.

A good start is to develop the absolute bare necessities to actually run the end-to-end process with the new system. Thus we break up the initial stories so that the bare necessities are just above the waterline for the first few iterations.

The bare necessities are however not good enough. Usually security, performance, user convenience and other such topics really need additional stories. But having the bare necessities allows for shopping for more.

Stakeholders go shopping

Thus we invited key stakeholders to go shopping in our story shop.

Preparation: Have (1) a tested and running increment of the product that supports the intended process steps with a minimal functionality; and (2) have the remaining user stories ready on shopping cards with headline, brief(!) explanations, a wire-frame of the UI and the story point estimation.

Step 1: We let the invited stakeholder – some of them future users – try out the system and complete the process from start to end. This allows the stakeholders to get a good impression of what the system can do by now and experience the needs for enhancements. Especially giving them the opportunity to perform almost real world tasks by themselves is really helpful for this.

Step 2: From the stories on the shopping cards, the “shoppers” can now select the next important stories. It’s quite easy for most people to cluster the cards according to their importance, they however tend to assign a large number of items in the top priority cluster. It is usually enough to kindly ask them to divide the top cluster in sub-clusters. Story points are quite important in this step. Stakeholders usually consider the costs for their priorities.

The top functions are the ones for the next iterations. So after the session, we up-dated the storymap to reflect the priorities of the stakeholders. The next iteration planning now starts with these priorities.

The minimal accepted product

We continue this process until the chunk is done and everybody happy enough. Criterias to stop the process can be:

• stakeholders don’t want anything more. This never happened in any project I’ve been involved. So doesn’t work.
• Budget is used up so the team stops adding features and simply removes the few bugs remaining. Somewhat works and is the most likely criteria to be applied. However, there is always something very important that is going to be missing so overshooting the budget is the usual case. A typical countermeasure is to take some percentage off the budget. This can be working, however teams then tend to rush.
• The team and the stakeholders agree that though there are many more great things to do, we spend the remaining budget for the next chunk of our elephant and stop working on this chunk. Very desirable situation. It will only exist if the team delivers product increments ready to deploy after the iterations and has a strong position towards the stakeholders. Difficult to achieve as it needs a very good team and very strong leadership.

It’s a kind of magic

A brief summary: user story mapping allows us to let key stakeholder and key users shop for the most important functions while keeping the whole end-to-end process in mind. We do this by first building the bare necessities to support the process, then open the story shop. It needs however strong leadership of the project team so that they can defend budget and software quality against the pressure to add more functions to the system.

The procedure is by itself quite easy. Still there are a few things to be careful about, it seems.

• The more experience the users have with the new system, the better they know what to order from the shop. In my opinion: no shopping without at least a minimal hands-on experience to ground the decisions in the shop.
• It is important that the stakeholders accept the fixed budget and the consequences this has, i.e. there is not enough money to build all the cool stuff we are able to imagine. Thus the message towards the stakeholders must be: we have this money to spend and need to get the most value out for you. Help us doing so! And sometimes, one really needs some manager to get this message across and to stop everyone from adding more features!
• Don’t neglect the team. A strong team delivering quality increments is really helping here.

Well, happy shopping!