How to build your MVP?
STARTUP TECHNOLOGIST – MICROSOFT
FOUNDER INSTITUTE – PRODUCT DEVELOPMENT SESSION
Why do we build products?
Delight customers with inspiring
Solve a real problem and help people
Realize a big vision and change the
Get a strong fan base and lots of
Product development approach
Build a great product with lots of features
Time wasted in building something nobody wants
Build for fast releases and get customer feedback
Time wasted in getting the right customer requirements
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
Avoid features no one will
Maximize the learning per
Minimal Viable Product
Product needs to solve a real
Early adopters can bridge the
gap with missing features
Can be developed
Requires a commitment to
Simple landing page screenshots from your Value Prop Call to action
Web page title
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
Focus on user needs and not technology
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.
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
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
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 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
Quality assurance (QA) is an essential part of the XP process
Acceptance tests should be
automated so they can be run often
A bug in production requires an
acceptance test be written to guard
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.
Smoke test via landing pages
SEM - $5 a day via Facebook etc.
In product split testing
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
tests & Bugs
Download Team Foundation Server
Workflow items and workflow
Visual Studio 2012 Guide
Measuring velocity in VSFS
Create a project plan in five steps
Planning using Project 2013
Scrum process template
Tracking software quality
Bug Tracking using Visual Studio - Test Manager
Windows 8 Store App Sample Code
List of products available through BizSpark