The concept of proving an end-to-end process is fundamental when starting Agile projects. With the teams I coach, I encourage them to get something (anything) in use/live as soon as possible. This engages the customer immediately, creates immediate learning and highlights unexpected bottlenecks in the end-to-end process.
This is very similar to a ‘Hello World’ software development concept that uses the smallest amount of code possible to write the phrase ‘Hello World’ on the screen. It is one of the simplest programs a developer can write and is often used to show that a language is installed correctly, the code compiles successfully and that the release environment is capable of delivering value to an end user.
BALANCING THE MVP
The ratio of the Minimum Viable Product (MVP) to other items on the backlog has a direct relationship with any time constraints you have. As you add more and more items to the MVP it puts more pressure on any deadlines you have, potentially forcing your hand to delay a release rather than negotiating scope that could wait until later. My advice here is to be harsh with your MVP, if you get it all done and have time for some other priority features then that's great, at least then you have the option.
We can use the MoSCoW method to help prioritise and identify our Minimum Viable Product. It works by splitting the backlog into 4 categories:
The items in the ‘Must’ category are critical in order for the product to be usable. This is your MVP. To validate the items, take an item in your backlog and ask yourself this question:
If I had completed everything else on the backlog and this was the only remaining item left to do before getting this product in use, would I go live anyway?
If the answer is yes, the item is not part of the MVP, if the answer is no, then it probably is.
Items in your MVP should be prioritised to optimise for feedback and build speed, not necessarily customer value
The items in the ‘Should’ category are items which add a lot of value but you could initially go live without.
Items outside your MVP should be prioritised by customer value.
Your ‘Could’ items make up your nice-to-haves. These are the go-to place if the scope of a release needs adjusting.
These are the items that after discussion don’t make it into the release or backlog. They are still useful to store and call out explicitly so that the stakeholders are clear what is not going to be done
HOW TO OBTAIN THE DATA
Add MoSCoW tokens to planning poker or delphi estimation to easily identify a consensus view.
Place 1 copy of the token on the table with print outs of the items to be prioritised and ask the team to move the items as necessary into each category. Encourage conversation as necessary!
What problems could you forsee with MoSCoW? How does your organisation determine their MVP?