Priorització MoSCoW: Must Have, Should Have, Could Have i Won’t Have
Explicita les renúncies que hi ha darrere les etiquetes.
En aquesta pàgina
La priorització MoSCoW classifica els requisits en quatre grups: Must Have, Should Have, Could Have i Won’t Have aquesta vegada. Distingeix de manera pràctica el que és imprescindible perquè un lliurament funcioni del que es pot ajornar.
El valor no és en les quatre etiquetes, sinó en l'acord que expressen: què protegirà l'equip, a què pot renunciar i qui pot canviar aquella decisió.
Què és la priorització MoSCoW?
MoSCoW és una tècnica de priorització de l'abast utilitzada en DSDM i altres entorns de projectes. Aplica les categories a un resultat i termini concrets. Un «Must Have» del projecte complet no ho ha de ser necessàriament de la primera versió.
Entén el resultat com un acord condicionat sobre l'abast, no com una llista pendent ordenada ni com a prova que el termini és viable.
Referència visual. Valora les categories segons el propòsit d’aquest lliurament. Compara esforç estimat, no recomptes; exclou el que no s’inclourà de l’esforç inclòs. Un imprescindible no ha de dependre de treball opcional. Les etiquetes no determinen capacitat, calendari ni preparació per publicar.
Versió en text
Per a un resultat i termini definits / les categories delimiten l’abast, no ordenen prioritats ni garanteixen el lliurament
- Imprescindible
- Prova de decisió: Aturar el lliurament si falta; Registrar la conseqüència: Evidència mínima d’acceptació
- S’hauria d’incloure
- Prova de decisió: Important; hi ha una alternativa viable; Registrar la conseqüència: Alternativa, responsable i cost
- Es podria incloure
- Prova de decisió: Útil; ajornar-ho té menys impacte; Registrar la conseqüència: Benefici i impacte de l’ajornament
- No s’inclourà aquesta vegada
- Prova de decisió: Fora de l’abast actual de manera explícita; Registrar la conseqüència: Límit i motiu per revisar-lo
Per què és important?
«Alta prioritat» amaga una pregunta important: per què aturaríem realment el llançament? Un servei de reserves que no evita superar les places i un altre que no ofereix accessos ràpids a classes favorites tenen problemes diferents, encara que totes dues peticions tinguin defensors entusiastes.
Una priorització útil converteix aquelles diferències en decisions abans que perilli una data. També revela quan el mínim proposat supera els recursos disponibles. Canviar etiquetes no crea capacitat.
Les quatre categories i les proves de decisió
| Categoria | Prova de decisió per a aquest termini | Què registrar |
|---|---|---|
| Must Have | Sense ell, el lliurament no és viable o acceptable; aturar-se en lloc de llançar. | La fallada que impedeix llançar i un mínim comprovable. |
| Should Have | Important, però existeix una alternativa temporal operativa. | L'alternativa, el responsable i el cost o inconvenient. |
| Could Have | Útil, amb conseqüències menors si s'omet. | El benefici i què passa si s'ajorna. |
| Won’t Have aquesta vegada | Deliberadament fora de l'abast actual. | El límit i quan o per què reconsiderar-lo. |
Són categories de compromís, no de satisfacció del client. Una funció «bàsica» del model Kano no es converteix automàticament en Must Have per a cada versió. Comprova usuaris previstos, propòsit i termini del lliurament.
Per a un Should Have, «ho farem manualment» no basta. Indica qui ho farà, si disposa de temps i com es gestionaran els errors. Una alternativa que no es pot operar realment no és una opció de reserva creïble.
Comença per un resultat, no per una llista de desitjos
Escriu una breu declaració de l'abast abans d'etiquetar requisits:
En sis setmanes, els socis actuals del gimnàs podran reservar pel seu compte una plaça en una classe programada i el personal podrà confiar en el límit de capacitat de la classe.
Aquest exemple exclou deliberadament cobraments, captació de socis i recompenses de fidelitat. Poden importar al negoci, però no tots són necessaris per al propòsit d'aquesta versió. Un full de ruta de producte aporta la direcció general; MoSCoW explicita el límit d'un lliurament.
Defineix separadament les condicions de qualitat i funcionament. El full següent no avalua seguretat, accessibilitat, legalitat ni preparació per llançar. Els especialistes pertinents han d'identificar els requisits aplicables. Retallar abast opcional no autoritza a rebaixar la qualitat essencial.
Exemple desenvolupat: la versió del gimnàs en sis setmanes
Exemple hipotètic. El gimnàs i l'equip disposen de 30 jornades-persona per a aquesta versió, després de descomptar altres compromisos coneguts. Estimen la feina següent amb la mateixa unitat d'esforç. Cada estimació inclou implantació, proves i traspàs necessaris per a aquella fila; la feina compartida s'assigna una vegada, sense duplicar-se en altres.
Escena il·lustrativa de planificació en un gimnàs de barri per a l’exemple hipotètic d’una versió de reserves; no és un negoci real, un equip de projecte ni una demostració de programari.
| Requisit | Prioritat | Esforç | Prova o alternativa |
|---|---|---|---|
| Veure l'horari i reservar una plaça | Must Have | 8 dies | Un soci pot reservar una classe disponible i veure la confirmació. |
| Evitar reserves per sobre de la capacitat | Must Have | 6 dies | Dues sol·licituds simultànies de l'última plaça no es poden completar totes dues. |
| El personal gestiona horaris i capacitat | Must Have | 4 dies | El personal pot crear les classes que necessita el servei. |
| Enviar un recordatori abans de la classe | Should Have | 6 dies | Recepció envia manualment una llista diària temporal de recordatoris. |
| Desar classes favorites | Could Have | 6 dies | Els socis poden trobar la mateixa classe a l'horari sense accés ràpid. |
| Obtenir insígnies de fidelitat | Won’t Have aquesta vegada | No inclòs | Reconsiderar després d'observar la primera versió; no forma part de l'esforç total. |
Els tres Must Have sumen 18 jornades-persona. L'abast candidat inclòs és 18 + 6 + 6 = 30 jornades-persona. Els Must Have representen, per tant, 18 ÷ 30 = 60% de l'esforç estimat inclòs, no el 60% del nombre de requisits. Els Won’t Have queden fora del denominador.
Les 12 jornades estimades restants són abast opcional valuós, no 12 dies d'inactivitat. Si la incertesa consumeix esforç, l'equip ja ha acordat què pot eliminar. No es promet completar tots els elements.
L'orientació habitual de DSDM per a projectes o increments suggereix limitar els Must Have aproximadament al 60% de l'esforç i conservar entorn del 20% com a Could Have. És una pauta de planificació, no una quota universal ni garantia de lliurament. L'equilibri adequat depèn del risc i la confiança del pla concret.
Trenta jornades-persona no són trenta dies transcorreguts. Especialitats, dependències, absències i aprovacions externes també condicionen si la feina cap en sis setmanes. Igualar totals no demostra un calendari viable.
Què canvia quan el pla es complica?
Suposa que controlar la capacitat requereix 10 dies en lloc de 6. L'abast candidat total passa a 34 dies davant de 30 disponibles. L'esforç Must augmenta a 22 dies, entorn del 64.7% de 34.
Eliminar la funció de favorites de 6 dies deixa 28 dies estimats, incloent-hi els recordatoris. Hi ha 2 dies estimats de marge, però els Must Have són 22 ÷ 28 = 78.6% de l'esforç inclòs restant. La càrrega encaixa aritmèticament, però el pla és menys flexible. És un motiu per revisar el risc, no per celebrar una puntuació verda.
Si el mínim ja no hi cap, les opcions són substantives: acotar el resultat, dividir un requisit en una part més petita realment utilitzable, canviar la data o reavaluar recursos. No reanomenis feina necessària com a «Should Have» només per millorar un percentatge.
Qüestiona les dependències ocultes
En l'exemple, la reserva del soci necessita un horari proporcionat pel personal. Fer opcional la gestió d'horaris deixaria un Must Have dependent de feina que potser no es lliura.
Ressegueix cada requisit essencial fins als prerequisits. Protegeix-los o redissenya la solució amb una alternativa creïble. Comprova també proveïdors, aprovacions, dades i preparació operativa, no només funcions de programari.
Per exemple, els recordatoris per correu poden dependre de l'aprovació d'un proveïdor extern. Si és incerta, registra-la com a risc de lliurament. Una etiqueta no avança aquella aprovació.
El full registra una dependència crítica per element per mantenir reduït l'exercici. Assenyala conflictes evidents entre Must i opcionals i cicles en els vincles registrats. No és un model complet de dependències ni un motor de planificació.
Resol desacords mitjançant conseqüències
Imagina que el propietari considera els recordatoris un Must Have perquè importa l'assistència. La persona de recepció diu que pot gestionar una llista manual les dues primeres setmanes. En lloc de votar l'etiqueta, pregunta:
- Quin resultat concret falla sense recordatoris automàtics?
- Pot recepció operar de manera fiable l'alternativa amb el volum d'aquesta versió?
- Quin temps extra o errors farien inacceptable l'alternativa?
- Qui té autoritat per acceptar el cost temporal?
Si l'alternativa és acceptable, els recordatoris poden continuar sent Should Have, amb responsable i data de revisió. Si no, actualitza conjuntament abast, esforç i decisió de lliurament. Registra el desacord pendent en lloc de fingir que el taller va generar consens.
Controla peticions noves sense congelar l'aprenentatge
Una petició nova no es rebutja automàticament ni s'afegeix de franc. Registra el motiu, l'estimació, els efectes sobre dependències i la renúncia proposada. La persona responsable ha de poder dir:
Afegim X per aquestes proves. Ajornem Y, o canviem data o recursos, i acceptem aquestes conseqüències.
Conserva la decisió anterior al registre del projecte i comunica el límit nou. «Won’t Have aquesta vegada» ha de tenir un desencadenant de reconsideració, no convertir-se en una promesa oblidada de lliurament segur a la versió següent.
MoSCoW, RICE i un full de ruta responen a preguntes diferents
| Enfocament | Pregunta principal | Què no estableix |
|---|---|---|
| MoSCoW | Què és essencial, opcional o queda exclòs en aquest termini? | Un ordre exacte dins d'una categoria o un calendari viable. |
| Priorització RICE | Com es comparen les opcions en abast, impacte, confiança i esforç? | Quines condicions operatives o de llançament són innegociables. |
| Full de ruta de producte | Quins resultats i direccions importen en diferents horitzons? | Una promesa fixa de lliurar totes les funcions enumerades. |
Utilitza proves per comparar alternatives i explicita després el compromís del lliurament actual. Evita assignar puntuacions aparentment precises a obligacions només per fer-les competir amb millores opcionals.
Errors habituals i limitacions
- Comptar elements en lloc d'esforç. Tres Could Have petits no compensen un Must Have enorme.
- Agrupar l'essencial amb extres. «Sistema de reserves» pot amagar un flux bàsic, anàlisis avançades i decoració amb prioritats diferents.
- Anomenar Must Have tot. Si tot és essencial, reconeix l'abast fix i gestiona data, recursos i risc en conseqüència.
- Deixar l'alternativa sense responsable. Un procés manual necessita temps de personal, accés i una manera de detectar errors.
- Confondre «hi cap» amb «s'acabarà». Les estimacions aproximades no demostren dotació, seqüència ni dates d'aprovació.
- Confondre exclusions amb compromisos posteriors. Reconsiderar no garanteix un lliurament futur.
MoSCoW estructura el criteri; no elimina la política, valida demanda ni calcula valor empresarial. Dos equips poden classificar diferent una mateixa funció perquè tenen objectius i restriccions diferents. Fes aquelles suposicions prou visibles per qüestionar-les.
Posa-ho en pràctica: acorda el límit d'un lliurament
Utilitza 25 minuts per a una primera revisió, no per a un pla complet. Tria un resultat, una data i la persona autoritzada per resoldre renúncies. Enumera fins a 12 requisits concrets. Registra categoria, conseqüència d'ometre'l, proves d'acceptació, responsable i una dependència crítica si escau.
Afegeix estimacions comparables d'esforç i capacitat disponible en jornades-persona. Indica la font i la incertesa a les notes de decisió; no substitueixis les proves absents per precisió inventada. Qüestiona els Must Have, prova un retard o sobrecost i acaba amb una decisió o acció de recollida de proves i un moment de revisió.
Imprescindible (0)
S’hauria d’incloure (0)
Es podria incloure (1)
- Requisit sense títol
No s’inclourà aquesta vegada (0)
Afegeix estimacions d’esforç positives i comparables per a tots els requisits inclosos. L’esforç desconegut no és zero.
Abans de descarregar (13 checks)
- Resultat: add the missing context.
- Termini: add the missing context.
- Responsable de la decisió: add the missing context.
- Proves, incertesa i decisió següent: add the missing context.
- Moment de revisió: add the missing context.
- Capacitat: introdueix jornades-persona positives, fins a 100,000, amb un màxim de dos decimals i sense separadors.
- Identifica un lliurament mínim amb almenys un Must Have.
- Element 1: registra requirement.
- Element 1: registra motiu / alternativa / exclusió.
- Element 1: registra proves d’acceptació o límit d’exclusió.
- Element 1: registra owner.
- Element 1: introdueix jornades-persona positives, fins a 100,000, amb un màxim de dos decimals i sense separadors.
- Confirma personalment l’abast, la unitat d’esforç i les dependències registrades; l’exemple no està preaprovat.
Llista de comprovació ràpida
Conclusió final
MoSCoW funciona quan modifica una decisió real. Protegeix el resultat mínim acceptable, identifica alternatives realistes, estima l'esforç i acorda qui pot negociar abast si canvien les condicions.
El resultat útil no és un tauler ple d'etiquetes. És un lliurament mínim que les persones poden explicar, feina opcional que realment estan disposades a ajornar i un límit honest per a aquesta versió.