Minimum viable product development
Upcoming SlideShare
Loading in...5

Minimum viable product development



An overview of what makes a successful MVP and how you can apply Microsoft's BizSpark program to create your own.

An overview of what makes a successful MVP and how you can apply Microsoft's BizSpark program to create your own.



Total Views
Views on SlideShare
Embed Views



1 Embed 11 11



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Customer Development for Web Startups
  • Extreme Programming Project
  • An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. Include time for testing.

Minimum viable product development Minimum viable product development Presentation Transcript

  • Why do we build products?  Delight customers with inspiring solutions  Solve a real problem and help people  Realize a big vision and change the world  Get a strong fan base and lots of revenue
  • Product development approach  Build a great product with lots of features  Time wasted in building something nobody wants OR  Build for fast releases and get customer feedback  Time wasted in getting the right customer requirements
  • MVP is  NOT The final version of the product  An experiment to validate the hypothesis  Usually discarded to build the real product  A minimalist user interface  Ok to share and receive feedback
  • Minimal Viable Product  The minimum set of features needed to learn from early adopters  Avoid features no one will use  Maximize the learning per dollar spent
  • Minimal Viable Product  Product needs to solve a real problem  Early adopters can bridge the gap with missing features  Can be developed incrementally  Requires a commitment to iteration
  • Simple landing page screenshots from your Value Prop Call to action graphic designer Web page title “Register/Sign- up” MVP Dissected
  • Lean Startup & Extreme Programming
  • User Stories  Similar to use cases but, not the same  Used to build time estimates  Track what customers need the system to do  Drive the creation of acceptance test cases  Each story will get 1,2 or 3 weeks ideal development time  Focus on user needs and not technology
  • User Stories  The project velocity (or just velocity) is a measure of how much work is getting done on your project.  To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration.
  • Architectural Spike  Figure out answers to tough technical or design problems  A simple program to explore potential solutions  Expect this to be throw-away code  Reduce the risk of the problem
  • Release Planning  Approx. 60 – 100 user stories are sufficient to make a release plan  A release planning meeting is used to create a release plan  The goal of the release planning meeting is to estimate user stories in ideal programming weeks  Customers prioritize stories with developers via user story cards  Planning may be done by time or scope  Project may be quantified by four variables; scope, resources, time, and quality
  • Release Planning
  • Iteration
  • Iteration  Iterative Development adds agility to the development process.  Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length.  One week is the best choice even though it seems very short.  Have an iteration planning meeting at the beginning of each iteration to plan out what will be done.  If it looks like you will not finish all of your tasks then call another iteration planning meeting, re-estimate, and remove some of the tasks.
  • Acceptance Tests  Acceptance tests are created from user stories  Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority  A user story is not considered complete until it has passed its acceptance tests  Quality assurance (QA) is an essential part of the XP process
  • Acceptance Tests  Acceptance tests should be automated so they can be run often  A bug in production requires an acceptance test be written to guard against it.  Given a failed acceptance test, developers then create unit tests to show the defect from a more source code specific point of view.  When the unit tests run at 100% then the failing acceptance test can be run again to validate the bug is fixed.
  • Testing Techniques  Smoke test via landing pages  SEM - $5 a day via Facebook etc.  In product split testing  Paper prototypes  Customer validation  Removing features  Mturk, Adwords
  • Small Releases  The development team needs to release iterative versions of the system to the customers often.  At the end of every iteration you will have tested, working, production ready software to demonstrate to your customers  This is critical to getting valuable feedback in time to have an impact on the system's development
  • User Stories Release Plan Prototype Acceptance tests & Bugs MVP Deliverables
  • Tools & Resources
  • MVP Backend • Cloud • Database Services/ Middle tier Frontend • User interface
  • Resources  User Stories  Download Team Foundation Server  Workflow items and workflow  Visual Studio 2012 Guide  Measuring velocity in VSFS  Power Mockup  Release Planning  Create a project plan in five steps  Planning using Project 2013  Scrum process template  Acceptance Tests  Tracking software quality  Bug Tracking using Visual Studio - Test Manager
  • Resources  Azure Portal  Windows 8 Store App Sample Code  BizSpark Site  List of products available through BizSpark