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!