Story Mapping for Agility, Part 2: Making it Agile with Business Value
?Typical project management measures projects in time, budget, and scope. There is a lot of value placed on following a plan and we are measured against our ability to do that. But Agile was developed precisely because we have learned that this type of manufacturing-based thinking is ineffective for software, and that a design-based thinking approach is more valuable. In the same way a script is the outline for a movie, the plan is the outline for the project. It will change every sprint, which makes following a preset plan problematic. What we want to measure is not the dreaded iron triangle of time, budget, and scope, but whether we are on track to deliver a set amount of business value. The concept of business value is mentioned in scrum, but a way to measure it is never defined.
“Time budget and scope have no bearing on the quality of the software we produce. Why do we keep doing this?”
We are long overdue for a method to run projects based on the actual business value we deliver, including a way to communicate this information to the business and customer in real-time. Through story mapping we can measure and report on business value in a way everybody can understand and use to meet its goals.
The key to this method is to make the transition from a long planning phase with BRDs and other big-design up front artifacts, and have Business, customers, and IT meet at the very initiation of the project to plan it together. By defining the business value of a project, business requirements get replaced by a shared understanding of the problem to be solved. The outcome is a contract where Development agrees to change certain quantified business value parameters by an agreed upon amount. These parameters are tied to the project test framework so that Business can view progress at least every iteration (typically two weeks). The project is “finished” when either the objectives have been achieved quantitatively, or the business has identified a higher-value project.
This happens through Story Mapping, and is much faster, more accurate, more transparent, more predictable, and has higher customer satisfaction than waterfall. It is also much easier, a lot more fun, and completely Agile.
In this article we are going to use the story maps we created in the first article and append a couple of layers to them. Therefore, I am only going to elaborate on the new steps. Please read that article first.
Goals
Artifacts
The goal is to leave the meeting with the following artifacts which will be used to define the business value metrics, inform the design, build out the backlog, and give us a true Agile contract.
Brainstorm Value
Let’s start off with the problem-to-be-solved discussion. We built the muscle before, but we really want to dig into that now. This is where good facilitation comes in. We want to brainstorm the answer. The facilitator asks the attendees, “Why are we building this?” She starts to write the various answers in a mind map on the board for discussion. It’s often necessary to ask the 5 whys/hows here.
For example, years ago, I worked for a major retailer on their CEO’s number-one project. The company offered health and education benefits to their blue-collar workers who worked at least 20 hours a week. A great place to work if you were a single mom and wanted to go to school while not having to worry about health care. But few people used the benefits and the average time they spent with this company before moving on was two months! What was causing people to leave this great company? The problem was, they could not see their schedule more than six days in advance, and they had to go to their store just to see the schedule. That means the employees could not plan transportation, class schedules, doctor appointments, child care, vacations, pick up open shifts, or any of the other things that white-collar workers take for granted. Additionally, supervisors were spending up to 30 hours a week playing scheduling Tetrus! In short, this was a big problem. (This retailer was not alone. Walmart solved this problem a few years ago and promised all employees they would know their schedule 6 month in advance. It was a milestone for blue-collar workers.)
Ther firist step was to determine what Business Value our project was going to bring to the company. When we started the brainstorming, we had a spirited discussion for over an hour before we settled on the core values.
Again, this looks a bit messy, but we want it to be messy. We want to get to the root of the issue and have everybody's input. Do not skip this discussion.
The business values get translated into business capabilities that we need to improve for our project. From this list, we pick a few key capabilities and asked these questions:
领英推荐
We took a straw poll of where we were and where we wanted to be a project end, and listed any “golden stars.” Golden stars are a very important aspect of story mapping, as they are the people who have already solved this problem in their domain. Often, they have come up with a manual work around. They are your subject matter experts, and finding them to investigate their success is something you should definitely do as you move forward.
Next, we have to answer the following questions:
CAVEAT: One of the problems Agility has is interfacing with traditional Project Management. People think they can measure success of all projects in the same way. There is this idea that any project can be judged on “a number” and the farther up the hierarchy you go, the simpler this number needs to be. But we’ve never had a meaningful measurement of Business Value in project management for software projects. “Selling” this idea is probably going to be the biggest impediment to adoption in your company.
What people don’t understand, and this may be the most important thing I say, is that when it comes to business value, there is no one number by which you measure all products/projects. You discover the project metrics in the design stage and build the project around them.
“When your organization’s goal is to differentiate on the experience, you must start every product-development project by defining the experience that you want people to have with your product or service." Jim Nieters and Pabini Gabriel-Petit, Leadership Matters
So, how to interface with those roles who want “a number?” Well, we would like to think that they were in the room during the design, so please make this clarification for them. Because what we want to do is redefine “done” from a burn down of business value proxies (points) to a burn up of actual business value. This concept will be tied in to all of our reporting.
But in case you run into the “just give me a number” argument from people who were not in the room, you can simply normalize whatever business value metrics you are using. You can report your “doneness” as a ratio of:
% Done = Current Measured Business Value/Over Final Desired Business Value
This turns your experience outcomes (OKRs) into KPIs without needing to explain what you are measuring. You can always give a better answer to those who have an interest or are closer to the project.
In this project, we choose three business capabilities that we felt would measure success. Note that we did not necessarily choose capabilities that had the biggest delta between starting and finishing values. One capability we only needed to move from a 1 to a 6. This is because this capability was already surfaced in a report so when we implemented our solutions, it would show up automatically. The MVP does not need to fix all problems, just significantly affect the scenario. For this reason, it’s much better to have a budget than an estimate for Agile projects. “How much can I get for this investment?” is a much better way to talk about finances than a fixed scope and budget.
From here, we need to tie our testing into the capabilities we are measuring. We do this so that we can show progress towards our goals every sprint demo. The first step is baselining where you are. If you can’t do it all, it’s obviously zero. In this case, store managers were already spending days manually inputting schedules, therefore we had a baseline number that we wanted to reduce over the course of the project.
Other capabilities are not so straight forward and you may need to take proxy measurements. In this case, the only way the store had to communicate with employees was a single store email. Every email sent to the store got printed and posted on a bulletin board. Right next to the schedules. In pondering this, we decided that one way we could measure the success of the Managing Schedule capability was to measure how many things got printed and to reduce printing costs, which were already tracked, by 90% over the course of the project.
Conclusion?
The entire process of determing business value and building a back log can be done in just two days to two weeks. A savings of months or years. Moving the identified capabilities from the current score to the new score (experience outcome) is the new contract. It replaces requirements documents and features with a few simple, measurable, agreed upon statements that. You will also note, that it supports, rather than violates, the Agile manifesto.
We no longer focus on the outputs of Scrum to determine “done,” but instead focus on the quantifiable outcomes to show progress. The first time you do this, it will take some facilitation, but once you embrace this method, you can become truly Agile because teams are no longer managed against a plan which they might never have had input on. Instead, we contracted on solving a problem defined by what we enable the user to achieve, and quantified what that solution would look like.
While the first time you do this, it may seem daunting, by the second time, you will wonder why you ever did it any other way.