How to use (and difference of) Spike vs Proof of Concept vs MVP

While busy working on building your winning product, you will come across times when you either don’t know what to do, or don’t know what is the best thing to do. Spikes, PoCs and MVPs can enable you to test the water with minimum cost. Here is a break down of what they are and how you can use them. Note that these are NOT scrum knowledge – however these supporting concept are widely practiced to produce great products so they’re worth knowing.


Spikes are small (single story) timeboxed effort for team to go and research one aspect of an upcoming piece of work. The outcomes are typically a piece of knowledge (note, NOT actual code or product) that will enable further writing of stories, make a decision on design or selection of technology or approach that will eventually lead to a product feature.

Spikes do not go on in-definitely, and may result in no tangible asset output, maybe except a diagram or chart to show the research results.

Use Spikes to determine how to write up further stories to further the development of (or understanding of) the product.

Input: An assumption, an idea, an unknown piece of work.

Work Expected: Go and do research, either based on other people’s past work, brand new research effort or exploration and testing.

Output: A validated idea, design, approach, resulting in more stories to be written up. Result of spike can be demonstrated by a summary of the outcome, discussion of result + decision or even a diagram that summarizes the result and a recommendation.


A PoC is a set of work efforts (a series of stories) aimed at achieving or validate a system (can consist of a number of components) that’s being designed. It should result in demonstrable assets/code/product being generated such as a mockup website, some rough code, tested connectivity and basic architecture. (convert to whatever applied to your product).

PoCs does not go on in-definitely, there is often a set deadline to prove the system will work, altho the work may span multiple weeks or sprints. The goal should always be a single working system/function.

Typical use of PoCs are to ensure further investment in the design, product or direction is worthwhile, feasible and will result positive values being returned. A business may use a PoC to prove the validity and cost-efficiency of a approach. An architect may use a PoC to prove the selection or design of infrastructure is correct. A tester may use a PoC to demonstrate a system to test the performance of the product before asking for more capital investment.

Input: A design, a solution in concept

Work Expected: To build out rough, functionally equivalent pieces of the system to prove the solution will work. This is where a mockup is roughly modeled and coded up

Output: A basic, functionally appropriate working system that demonstrate the design, idea will be worthwhile to invest further effort into


A MVP is a basic version of the product (multiple stories, typically at the end of multiple sprints) that can be built, functionally operational, of acceptable quality and can get started on returning value back to the business for their investment. It is the ‘first’ version of the product. It typically requires work from multiple people to produce and does not include all the bells and whistles, instead, include just the most important features (and just a couple of them!) a user would find useful.

A seasoned product owner would use a MVP to prove the product is valid, get early return on investment, prove the market of customer exist and they will pay for it. It should also be used to solicit feedback from users in order further improve the next version(s) of the product, allowing the product to continuously improve.

Input: An idea for a product, a bunch of most important features

Work Expected: Efforts to build a basic, but working product

Output: A basic (first) version of the product that can be released into the market