Finding the MMF and the MVP

I was talking with a colleague about project planning and I thought she was asking about projecting an end date for an upcoming development effort. I said, “That’s easy, backlog story points divided by capacity equals days to complete.”

I made a couple of additional comments about dependency management and PTO, then she interrupted my monologue, “the question is not, when will we be done, it’s how do we meet a fixed delivery date.”

“Well, since we’re doing development in sprints, we are always working towards a fixed date.”

She gave me a pained smile, “Okay, wise guy. I guess I really want to know how do we plan to a hard deadline when the release backlog has more story points than the team has capacity. ”

“Well… your backlog is in value order so the pieces with the best return will be at the top of the list. Burn through it and when the delivery date arrives you deliver the most value for the time allowed.”

“That’s still not good enough; we don’t have the capacity to get all the must have stories done. There’s got to be some stuff that’s not so critical. Hopefully we can shave enough points to save the release. But how do we find the extra ones and get them out?”

We took the problem to our resident expert and got this advice: “You need to slice and dice your backlog.”

It’s a given that your backlog has well-groomed features and they have well-groomed stories. But which stories are absolutely critical to the upcoming release? Assigning business value is a necessary starting point, but you need the least amount of capability that makes your product useful. What you’re looking for is the set of Minimally Marketable Features (MMF) and the Minimum Viable Product (MVP). Story mapping is a technique to “experiment” with your backlog and find the MMF and MVP for your product.

Here’s an overview of the process. Find a wall with lots of space for sticky notes. Make a sticky-note for each feature. Leaving space on the left for a column of notes, post the features in a row toward the top of the wall. Now make a sticky for each story and line them up in columns under their respective feature. Finally, select the personas that will use this release of your product. Make a sticky for each and put them in a column to the left of your feature and story grid.

Now it’s time to “connect the dots”. Make a sticky that describes one of the actions and related outcome that a persona takes to engage with your system. Put it to the left of that persona’s sticky and then trace the path through the stories that accomplishes the goal. Have the team in the room to validate the paths and make sure all the steps necessary to complete the action are identified. You’re done for an action when a verified path exists. If you identify a hole in your backlog then write a story, get it into the backlog and onto the board. And remember that some stories may provide more capability than necessary to complete the users’ action. Split that story. Leverage this new understanding; take a moment to try and slice the story even finer. Remind folks of the goal, MMF, MVP.

Repeat the process for each persona and action. Count up the story points that deliver the required actions. Are you still over capacity? If no, you’re done mapping. But if yes, then you have to visit every action again and ask some questions. Do we really have to have this for the release? Can we simplify the approach; do we need all the fields, does the user need a given option on day one? Does completing the actions touch on one or two stories of a given feature; can we leave that one for next time? The plan may include stories to implement an architectural feature. Is this a nice to have platform enhancement that’s lurking in the backlog as a must have?

While the technique can not guarantee you can trim your backlog to fit a fixed release date, the map can let you focus your resources on the few specific stories necessary to delivery the MMF and MVP.