Coming up with an MVP is an art of brainstorming, identifying, splitting, including, excluding features which will result to deliver highest business value to the customer first. Sometimes more than one MVP combined as shippable release and it is known as Minimum Marketable Product (MMP).
Setting the right expectation for MVP and MMP with stakeholders (especially with business) is very important and what can be expect from an MVP. Else business might expect each MVP will hit into market with all functionalities. Also you can experience a lot of love from business to keep all their features in a single MVP and not like to exclude features and its sub features is a common trend.
Each project/product priorities are unique, so identifying and defining MVP will vary from project to project or product to product.
So instead of following an MVP template, teams should more focus on collaboration and communication along with right set of stakeholders to come up with an MVP.
User Story Mapping is one of the popular way to derive MVP. In general, MVP should be a testable and have a left to right workflow or it can be a prototype too.
Product Backlog is the single source of input to the team for development. So MVP will be gradually turned into top prioritized PBI’s in your Product Backlog.
Product Owner is sole responsible person to come up with MVP with the help of other stakeholders.
A MVP can/cannot be shippable to the market and it will be decided by the Product Owner.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Simple to understand
Difficult to master
Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques
Ability to manage changing priorities' is one of the top 3 reasons for adopting Agile
Scrum & Kanban are Lean and Agile. Kanban is not an Agile Method!
With agile methods such as Scrum,customer or the product is on focus and the product is created in a team-oriented manner in iterative incremental cycles. And the switch to Scrum is a disruptive change for many companies in the classical world (from projects to products, no project managers, separation of business and personal responsibility).
At Kanban the optimization of the process is at the forefront. Not the customer. Not a team. And Kanban is an evolutionary approach for continuous improvement.This is why the book by David Anderson, the inventor of (IT-) Kanban, is called "Successful Evolutionary Change for Your Technology Business".
Any comparison between Scrum and Kanban is utterly pointless. It is like comparing a hammer with a screw driver.
Top 5 Agile Adoption challenges Company philosophy odds with core agile values Lack of expereince with agile methods Lack of management support General organization restiance to Change