Streamlining Python Development: A Guide to a Modern Project Setup
Developing an MVP your users will love
1.
2. IBusiness Analyst for 6 years and
IIBA NW&E Branch member
Joined Sigma in July 2012
Working on Agile projects for the
past 4 years
Certified Scrum Product Owner
3. What is an MVP and when should you use them
How you can ensure your product will have
exciting features your customers will love
What are the pros & cons of using them
How do you define an MVP and what tools &
techniques can we use to help us
start learning how to build a sustainable business with the minimum amount of effort.
In Scrum an MVP is just a "basic" version of a product that later becomes more complex. It's something designed to test technical feasibility, it's designed to see if the team can create a solution.
Scrum iterates for featuresYou’ll make some sales and learn some things from users earlyHowever, there are always those users that can’t use your product until it has all the features.
Lean Startup focuses on mximising learning and reducing riskScrum focuses on speed to market and developing a minimum product that is viable for the market
Using an MVP strategy isn’t right in every scenario, but there are some that are well placed for using an MVP.
As with the lean startup mantra, startups have limited resources and need to maximse their learning/return for the smallest amount of expenditure (in either cost or time).Dropbox MVP – Drew Houston Couldn’t get investment as investors were struggling to recognise if there was a demand for the product.Drew recounted, “It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away.”http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
Everyone remembers that the iPhone first generation reveloutionised the mobile market – but it also highlighted the power of the MVP. Unlike other mobiles it appeared to be missing some core features: copy & paste, the ability to send messages to multiple recipients & apps were limited to web only (but as a plus – didn’t need the infastructure for day 1. And yet by focusing on a defined set of important features and executing them well, the iPhone was a massive success.
If someone has beaten you to market with a product, you may be caught out and trying to catch up. You might look at their product and strip it down to a set of bare-essentials that your team need to implement to compete and go head to head.It’s not a long term strategy but it might give you the speed to market benefit you need in this sit
If everything is a priority in your organisation than nothing is a priority as it all has an equal weighting. In this scenario, some of the prioritisation tools that we’ll discuss further in this presentation
Teams and product owners set the vision of their product, its not just the high-level roadmap that they will follow but also tool they'll use to excite people. Excited stakeholders can be: investors, developers, customers, users.As the future is uncertain, the vision should cover the next product version. Even if Steve Jobs’s long-term dream was to domi- nate the mobile phone market, it was certainly not the goal for the first iPhone. Grand ambitions are best realized one step at a time.
As an example of setting vision Think about Kickstarter - it's practically as a warehouse full of MVPs. People put up their ideas for interesting products, before they build them, and other people demonstrate their desire by supporting them.
The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. A typical Scrum backlog comprises the following different types of items:- Features- Bugs- Technical work- Knowledge acquisition- http://www.mountaingoatsoftware.com/agile/scrum/product-backlog
the problem with simply saying that requirements are of High, Medium or Low importance is that the definitions of these priorities are missing. Using MoSCoW means that priorities are specific. The specific use of Must, Should, Could or Won’t Have implies the result of failing to deliver that requirement.
Ask the question, “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, simply that delivery is not guaranteed.
A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.
These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritised Requirements List where they help clarify the scope of the project and to avoid being reintroduced ‘via the back door’ at a later date. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.
A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.AND to the rightOR belowDotted lies are not releases, just the boundaries of features
IdentifyDocumentValidate
MVPs work well when they are well planned and they are followed-up by logical enhancements and additional features. However, some roadmaps can become political with releases being promised to different departments or stakeholders. This can cause your roadmap to become confusing and can impact your customers view of your product.
Agile teams use MVPs to get a product to market quickly, but it needs to be quickly followed up by additional functionality.Agile is all about the ‘sprint’ and not the marathon, but this can leave teams exhausted and wondering if they’ll ever reach ‘the end’ of the project.
Minimum viable does not mean minimum quality.There are decisions that you’ll make to get a product out to market quickly that may need redoing in the future (technical debts) ensure this doesn’t impact your customers experience in a negative way.
When a customer experiences WOW, you are giving them a pleasant surprise. You are exceeding their expectations. You are addressing their needs thoughtfully and in unexpected ways. It is an expression of your authentic interest in the person who seeks your services, not just in the transaction. You have to ensure that your team continue to deliver wow through every release.
