One of the most interesting discussions in the Agile community at the moment is about “MVP”. I recently had a conversation with various community members and I heard someone say that MVP should be thought os as “starting off with a turd and then polish it”… It was another one of those times where I felt like I wanted to borrow someone else’s hand so that I could use it to form a triple face-palm.
Who wants a turd? who wants software that’s comparable to a turd? I think the developer that made this statement had the same misconception that a heck of a lot of people have about the meaning of MVP. Too many people think it means SPEED – he was implying that we don’t have time to build the final high quality product that the customer is looking for, so building the “Minimal Viable Product” means build a lower quality version that’s bare bones and then beef it up and add in the quality.
Someone else cited the well-known image of the product versions from the skateboard up to the car:
If you needed a car to travel from London to Glasgow in the rain (and had next to no sense of balance) and someone gave you a skateboard, wouldn’t you be a wee bit disappointed?
So naturally, I tried to dispel this misconception. MVP shouldn’t hinder quality or value – I’ve found that changing the V to mean “valuable” rather than “viable” helps to put the focus on slicing with the focus being on ‘value’ rather than ‘smallest’ and ‘quickest’.
I’ve also started using Matt Barcomb’s SMURFS mnemonic too. SMURFS stands for Specific Marketable Useable Releasable Feature Sets – every word being very integral to help slice stories up in a way that they are valuable.
Now with the image above, if our client wanted a car to get from London to Glasgow and we gave them a skateboard, then that’s obvious we haven’t thought about context – we haven’t thought about what the customer values regarding what they are asking for – we need to ask questions to discover this information up front: travel speed? ease of use? safety? comfort? how many passengers? etc. A skateboard would not really fit within this context and it certainly wouldn’t fit within any of the SMURFS categories. Perhaps a more suitable initial release would be a motorized go-kart, quad bike, beach buggy, or basically a barebones car that we could expand on iteratively…
A final thing to mention about MVPs (or SMURFS) is that when we test the idea of the story (i.e. we question the story and communicate with the product owner and customers – yes, this is investigative exploratory testing too, conducted by the whole team upfront), then perhaps the customer/users would find a quad bike or a go-kart suitable, or they might supply more information such as the need for 2 seats and a means of keeping dry… Collaboration and communication up front is key with defining our SMURFS / MVP stories. The conversations are the key thing regarding the stories – defining and refining what we are going to build, testing the ideas and then collaborating regarding how to deliver the valuable slices of work.
So how do you deal with MVPs? Have you noticed a problem in your story slicing? For me, it seems like a common problem, which feeds into an estimation problem (but that’s for another blog post 🙂 ).
Feel free to share you’re stories in the comments!
Dan Ashby 
I had a rant about this when I was speaking at TestActually in Brighton this week, using the same car example. It seems like our thoughts are very much in alignment!
To give one further scenario, imagine the requirements were misunderstood in the first place, and your stakeholders actually want a bus. In the crossed-out iterative version, this misunderstanding would become clear within the first couple of iterations (about the time that you started working on the floor of the car). On the other hand, if you’re going scooter > skateboard > bike > etc, the issue is less likely to surface: your stakeholders might just assume you’re going to work up to a bus in MVP #6! (I like to think of this as being analagous to the sticky problems of performance and scalability: there are certain assumptions about how your product is going to behave under load, yet these are often not checked or reviewed until far too late…)
As you said in your opening, it’s important to distinguish between Minimum Viable Product and Minimum Viable Quality. Just because we’re working with a lean feature set, doesn’t necessarily mean that we want to lower the bar of our testing: for instance, if you’re delivering a motorized go-kart in phase 1, you’ll probably still test the brakes, rather than saying “we’ll test them in a later version, this is just a prototype”!
LikeLiked by 1 person
Dan, I appreciate your thought but I want to challenge it a bit.
Try to focus on “why” you are building an MVP.
If people are building an MVP because you don’t have time to do the “full solution” then they don’t understand the reason why MVPs exist and they should stop using the term.
The MVP is not only for the customer, the MVP in my opinion is more important for the company that is building the product. The MVP will generate feedback that will help the company build the right product for their customers.
If you do the MVP, don’t learn anything and keep on building by the plan you are wasting a great opportunity.
LikeLiked by 1 person
Thanks for the comment Gus!
I agree that MVP is about feedback, but in a sense it should be confirmatory feedback based on the conversations and collaboration upfront about slicing stories.
The post is mainly focussing on those conversations upfront, where we should be thinking about context, value and quality and including them in the conversations.
I’ve worked in places that slice “MVP” stories up without thinking of those things and the build something like the skateboard and only after that do they get the feedback from the stakeholders that its not valuable… That is wasteful.
But I agree with you – if done correctly then MVPs are very useful! I find using the word valuable or the SMURFS mnemonic helpful in allowing the teams to do it correctly though, as it gives focus to the conversations around the story slicing.
LikeLike
Dan, take 10 minutes to read this great article on lean startup
View at Medium.com
The first point is what I mean with MVP, in my humble opinion, the SMURFS concept is flawed by the fact that it assumes you know what the customer wants before you release your MVP
LikeLike
View at Medium.com
LikeLike
Medium links don’t seem to be digested by the comment box here, let me try a trick
https:// medium.com / @davidjbland / 7-things-i-ve-learned-about-lean-startup-c6323d9ef19c
LikeLike