Breaking the day’s work into manageable sprints, having a sprint board, hourly standups, retros, and a clear investment in backlog grooming — all help. In fact, this year I introduced a new concept to our Operation Overnight team: the Minimum Viable Product (MVP). What’s an MVP? Kenneth S. Rubin, noted Scrum theorist and author, introduces it this way:
[…] We focus each release on a small set of minimum releasable features (MRFs) around which the stakeholder community shares a strong group consensus. MRFs represent the smallest set of “must-have” features–the features that simply have to be in the release if we are to meet customer value and quality expectations. Some people refer to this set of features as the minimum viable product (MVP) (Rubin, Essential Scrum, 295.)
Though MVP not a new construct in the Scrum framework (or in Lean), for many on our team it at first had the feel of the strange and unfamiliar. Over the course of the event, however, it wound up being a tremendous benefit. Here’s why…
MVPs focus conversations on what we need to do, not what we could do
In order to minimize risk and avoid building things that aren’t strictly necessary, it’s important that the question, “What’s the absolute minimum set of features that we need to deliver in order to delight the client?” is revisited throughout the event. Every feature, every idea, and every bit of work needs to be framed against this simple question.
Since we were fortunate enough to have the client embedded in our team, we didn’t have to wait for answers. This helped us quickly split stories into their must-have components and collect them in the MVP #1 space of our backlog.
Having a clearly defined MVP #1 area of the backlog was helpful in its own right, as it served as a visual aid for the concept of “the smallest set of ‘must-have’ features.”
How stories flowed across the scrum board
Like most Scrum boards, we still had a product backlog. We just added areas to capture a couple MVPs (MVP #1 and MVP #2). Stories that were not part of MVP #1 were placed in either MVP #2 or the backlog. MVPs and the larger backlog were prioritized as you would expect, and stories further out had less definition than those nearer.
The diagram below helps illustrate the organization of our Scrum board and how stories flowed through it:
Conceptual layout of MVP Scrum board. See it in action!
During sprint planning, the team committed to stories pulled almost exclusively from MVP #1. Very rarely did someone try to pull a card from MVP #2, or from the backlog. If they did, it was a natural and obvious prompt for a conversation.
MVPs help avoid the development death-march approach
One of the temptations of a project like this is to just create one massive product backlog, prioritize it, and run a development death-march until the clock runs out. Even if the work is broken out into sprints, this approach can invite more risk than I’m comfortable with. In addition, it can make the work feel more like a siege than a dance.
Furthermore, this approach leaves more room for people to pull cards based on preference, regardless of priority. By contrast, an MVP approach lets us quickly decide “Is this in the release or not?” If the answer is “It is not,” the natural follow-up is, “Why are we working on it?”
The MVP saved us
At the end of the day, using MVPs turned out to be more than a mere curious exercise in Scrum methodology. In fact, the approach ended up saving our keister. Here’s why…
It turns out that once we pushed our first MVP (MVP #1) to the live website, the site’s hosting provider kindly blocked all access from our location’s IP address. This meant we had just gone live with a new website that was visible to everyone in the world…
Except for us.
Since this “security feature” at the hosting provider blocked our team from accessing our site, our first push ended up being our last.
Because it was an MVP and the scope was continually negotiated and defined with the client throughout the event, she not only knew precisely what she was getting, but she had a website that delighted and contained precisely the features she wanted.
“I can’t stop looking at our site,” she said. “It is beautiful.”
Science Center website as Minimum Viable Product (MVP)
