Abans de començar, definim de manera breu i precisa el concepte de MVP (Producte Mínim Viable).
Un MVP és l’execució d’un experiment dissenyat per validar o refutar una hipòtesi rellevant, amb l’objectiu de reduir una incertesa i obtenir aprenentatge accionable sobre el producte, els usuaris, el mercat o el problema a resoldre. Aquest experiment no ha de ser necessàriament un producte
Aquesta definició pot sorprendre. Una ràpida cerca a Internet mostra moltes interpretacions que presenten MVP com un element integrat dins de Scrum, fins i tot com un possible substitut del Sprint Goal, de la Definition of Done o de l’increment. Aquesta interpretació, tot i ser molt comuna, és una mala pràctica que desvirtua tant el marc de treball Scrum com el concepte de MVP i la seva utilitat real dins d’un projecte o una organització.
Quan llegim “Producte Mínim Viable”, tendim a pensar automàticament en producte, en petites funcionalitats i en valor. Però MVP no tracta principalment d’això. Tracta de posar a prova una hipòtesi que no ha de materialitzar-se en un producte viable ni tan sols usable.
És important tenir clar què NO és un MVP. MVP i Scrum són conceptes completament diferents, tot i que poden complementar-se per facilitar l’entrega iterativa de valor de qualitat.
MVP no forma part de l’estàndard Scrum. Per tant, fer Scrum no significa en cap cas que s’estigui aplicant MVP. Per començar, MVP prové de Lean. Scrum s’ha apropat a Lean en les versions més recents, sobretot en el principi d’evitar el malbaratament al llarg del procés iteratiu de construcció d’un producte.
L’any 2011, Eric Ries, al seu llibre “The Lean Startup”, incorpora el concepte de MVP dins de Lean i el defineix a partir de tres pilars bàsics: aprenentatge, validació d’hipòtesis i presa de decisions. Aquí és clau entendre que MVP no es focalitza explícitament en el producte, sinó en aprenentatge.
Scrum té una forta orientació cap a l’increment de valor i cap al producte. I quan apliquem MVP, el primer impuls sol ser pensar en funcionalitats i en valor tangible. Però MVP no és això. MVP és una eina que ajuda els equips a millorar la seva manera de treballar per obtenir millors resultats. Per aconseguir-ho, cal crear un entorn on l’aprenentatge continu, la prova d’hipòtesis i el possible fracàs —per intentar una altra direcció— siguin possibles, acceptats i, fins i tot, promoguts.
Algunes derivades concretes d’aquest enfocament, que ajuden a clarificar què NO és un MVP, són les següents:
L’ús del concepte de MVP no respon únicament a la voluntat de construir més ràpid o amb menys cost, sinó a la necessitat de prendre millors decisions en entorns d’incertesa. En la construcció d’un producte, el risc principal no és la velocitat ni el nombre de funcionalitats desplegades, sinó construir allò que no aporta valor real a l’organització.
En aquest context, MVP s’ha de considerar una eina de govern del producte. Aquesta eina permet reduir incerteses i orientar l’evolució del producte a partir d’evidències obtingudes del món real —usuaris que utilitzen realment el producte—. Els objectius de MVP es poden resumir en un de central:
Assegurar que avancem en la direcció correcta en la construcció del nostre producte.
Una llista més detallada d’objectius podria ser la següent:
L’ús de MVP per governar la creació de productes aporta una sèrie d’avantatges clau:
Tanmateix, ignorar els tres pilars d’hipòtesi, experiment i aprenentatge condueix a la scrumització de MVP: convertir-lo en un artefacte o ritual més dins del cicle Scrum. Aquesta confusió genera friccions amb pràctiques consolidades com el Sprint Goal o la Definition of Done, i desvirtua tant el propòsit de MVP com el del mateix marc de treball.
MVP no substitueix Scrum ni s’hi superposa: el complementa. Scrum proporciona el marc per construir increments de qualitat; MVP aporta el criteri per decidir quins increments val la pena construir i amb quin objectiu d’aprenentatge.
Molts equips que treballen amb Scrum veuen MVP com un element que es pot incorporar com un artefacte més dins de les dinàmiques habituals. En aquest punt, existeix el risc de tractar MVP com una llista d’elements que aporten valor a cada Sprint. Això simplifica el veritable propòsit de MVP, que és facilitar l’aprenentatge, no lliurar valor de manera cíclica.
MVP no altera el marc de treball Scrum. Conceptes clau com l’increment, el Sprint Goal o la Definition of Done continuen sent fonamentals. El repte consisteix a entendre com hipòtesis, experiments i aprenentatge poden conviure sense introduir biaixos en l’operativa dels equips ni en la comunicació amb els stakeholders.
Scrum té un focus clar i fàcilment comprensible per als equips: proporcionar valor de manera iterativa —no necessàriament a cada Sprint, com recorda el concepte de release— encara que sigui en increments petits. Això es tradueix en artefactes i activitats orientades a seleccionar increments viables que permetin avançar cap a un producte escalable, segur i útil.
MVP se centra en l’aprenentatge i en com aquest pot influir positivament en la reducció d’incerteses que guien el Product Owner en la presa de decisions sobre l’evolució del producte.
Si entenem MVP com una eina per reduir incertesa, podem assumir que reduir incertesa no sempre significa avançar en increments de valor per al negoci. Hi ha decisions que no es poden prendre simplement afegint més valor, sinó aturant-se i qüestionant si allò que s’ha construït genera el valor correcte per continuar evolucionant el producte. Resoldre incerteses té un impacte directe i positiu en definir el camí adequat per a l’evolució del producte i les seves funcionalitats.
MVP es relaciona amb el discovery de la mateixa manera que Scrum es relaciona amb el Sprint. És a dir, MVP busca resoldre incertesa mitjançant la prova d’hipòtesis per descobrir si aquestes són vàlides o simples miratges del mercat. Cal aclarir que MVP no és un marc de discovery —aquest pot integrar-se perfectament dins de Scrum—, sinó una eina enfocada al discovery i no a la producció de valor no validat.
Quan Instagram va decidir provar si mostrar públicament el nombre de likes generava estrès en els usuaris, no pensava a aportar nou valor de producte, sinó a resoldre un dubte que podia marcar la seva evolució futura. És raonable pensar que, juntament amb funcionalitats alineades amb un Sprint Goal, es va desplegar un experiment petit i simple per validar o refutar aquella hipòtesi.
Aquesta manera de pensar, tant a nivell d’equip com d’organització, genera un entorn en què és possible desplegar increments amb valor complementari a altres necessitats, i on hi ha espai per aprendre sobre el producte i el mercat amb l’objectiu d’evolucionar en la millor direcció possible.
Per concloure aquesta secció, l’objectiu últim de l’aprenentatge no és aprendre per aprendre, sinó reduir la incertesa suficient per prendre millors decisions de producte. MVP no substitueix ni relaxa els compromisos de Scrum, sinó que hi conviu amb els increments orientats a valor dins d’un mateix cicle de treball.
Com s’ha comentat anteriorment, MVP es basa en tres pilars fonamentals: hipòtesi, experiment i aprenentatge. En aquesta secció aprofundim en cadascun d’ells.
Una hipòtesi és una suposició que inicialment es creu certa, però que requereix validació, ja sigui per confirmar-la o per refutar-la. Al llarg d’un projecte poden sorgir dubtes sobre si una funcionalitat o una determinada orientació del producte és realment l’adequada.
Amb MVP formulem hipòtesis dissenyades per resoldre aquestes incerteses. La llista d’hipòtesis que van apareixent amb el temps s’ha de prioritzar, ja que algunes són més crítiques per al futur del producte que d’altres. En funció d’aquesta priorització, decidim quines s’incorporen al flux de treball.
El Product Owner és qui governa les hipòtesis. La seva responsabilitat és doble:
L’experiment és l’execució d’una hipòtesi amb l’objectiu de validar-la o refutar-la. Scrum pot actuar com a vehicle d’execució de l’experiment. Un experiment pot encaixar dins d’un Sprint perquè l’equip el construeixi i els usuaris posin a prova la hipòtesi plantejada.
Un experiment no ha d’estar limitat a un únic Sprint; pot estendre’s en el temps. També és important entendre que un experiment pot generar o no un increment de valor de producte. Tanmateix, l’aprenentatge obtingut sempre té valor per a l’equip i per al negoci.
L’objectiu principal d’un experiment és validar o refutar una hipòtesi, tot i que a la pràctica això no sempre s’aconsegueix. Sovint les hipòtesis són incompletes, els experiments revelen noves incerteses o els resultats només validen parcialment la suposició inicial, fet que porta a reformulacions o a la generació de noves hipòtesis.
L’aprenentatge és el resultat de l’execució de l’experiment: la informació obtinguda que permet validar o refutar la hipòtesi. Aquest aprenentatge pot influir en el que es mostra a la Sprint Review, modificar el Product Backlog o fins i tot afectar futurs Sprint Goals.
L’aprenentatge és responsabilitat de tothom. L’equip aprèn construint experiments que poden marcar l’evolució del producte. Els stakeholders aprenen en veure confirmades o refutades suposicions sobre usuaris, negoci o mercat. El Product Owner aprèn en obtenir una comprensió més sòlida del que realment és el producte a cada etapa.
Treballar amb llistes d’hipòtesis prioritzades implica que diferents persones assumeixin responsabilitats diferents en cada moment del procés.
Això inclou accions de priorització, construcció d’experiments, proves en el món real i recollida d’informació que permeti aprendre i prendre decisions, tot mantenint una convivència sana amb el marc de treball Scrum.
Es tracta d’una feina coral que impacta tots els implicats en el projecte, inclòs el negoci. Una manera d’abordar aquest repartiment de responsabilitats sense caure en l’error de diluir MVP dins de Scrum és centrar-se en els seus pilars: hipòtesi, experiment i aprenentatge.
És lògic que la persona més interessada a resoldre incerteses que poden afectar negativament el producte sigui qui el governa. Per això, el Product Owner és el principal responsable de recollir i prioritzar les hipòtesis.
Això no vol dir que el Product Owner actuï en solitari. No pot inventar hipòtesis. Els stakeholders aporten informació clau sobre el context, les restriccions, els objectius de negoci i condicionants legals, polítics o de mercat que generen incertesa.
El Product Owner incorpora activament —no delega— aquest context en la definició de la llista d’hipòtesis. La responsabilitat final de la priorització continua sent seva i es basa en criteris de risc i incertesa, no en l’esforç o la complexitat tècnica.
Un cop el Product Owner decideix que una hipòtesi s’ha de sotmetre a validació, correspon al Scrum Team incorporar les tasques tècniques necessàries dins d’un o diversos Sprints per construir l’experiment. El Scrum Team és responsable de dissenyar i construir l’experiment de la manera tècnicament més adequada, però no de decidir quina hipòtesi és prioritària ni com s’han d’interpretar els resultats.
Un cop desplegat l’experiment, el focus torna als stakeholders o, més concretament, als usuaris o al mercat que en faran un ús real. L’equip tècnic continua implicat proporcionant suport, ajustos o solucions tècniques quan cal. El resultat és informació en forma de mètriques, KPIs —indicadors clau—, estadístiques i altres dades rellevants que permeten validar o refutar la hipòtesi inicial.
Finalment, un cop validada o refutada la hipòtesi, el Product Owner disposa d’informació de valor per interpretar l’aprenentatge i prendre decisions sobre el futur del producte: perseverar en la direcció actual, reorientar-la o continuar investigant si la incertesa no s’ha resolt completament.
Aquestes decisions solen tenir impacte sobre artefactes de Scrum com el Sprint Goal, el Product Backlog i els increments. La validació o refutació d’una hipòtesi pot modificar la priorització i el contingut del Product Backlog, així com els objectius de Sprints futurs.
Per tancar aquest article, cal insistir en una idea clau: MVP no és una tècnica que formi part del marc de treball Scrum, ni una activitat o artefacte que s’hi pugui afegir sense més. Entendre MVP d’aquesta manera és una mala pràctica que desvirtua tant el seu propòsit com el del mateix Scrum.
MVP és una estratègia orientada a reduir incerteses crítiques que poden condicionar greument l’evolució d’un producte. El seu focus no és incrementar funcionalitats, sinó aportar una visió del valor basada en la reducció de riscos mitjançant evidències reals.
A través d’hipòtesis explícites, experiments dissenyats per posar-les a prova i l’aprenentatge que se’n deriva, MVP obliga equips i organitzacions a afrontar una realitat sovint incòmoda: decidir. Quan s’utilitza amb rigor, MVP no substitueix Scrum ni en relaxa els compromisos, sinó que complementa el govern del producte. Però només funciona quan hi ha una voluntat real d’aprendre i d’actuar en conseqüència.
![calaix[À]gil.com](/img/logo.png){kind=logo}
