En el curs d’un projecte àgil, fem un fort èmfasi en la necessitat que l’equip pugui enfocar-se en un objectiu de valor petit (o millor dit, assumible per l’equip). Això permet a l’equip aïllar-se de la complexitat sovint inabastable del producte complet, i centrar-se a proporcionar un MVP veritablement útil per a l’organització. Per assolir aquest objectiu de treball primari en agilitat, existeix el concepte de història d’usuari. La història d’usuari proporciona una eina poderosa alhora que extremadament senzilla per a negociar una necessitat concreta amb els stakeholders.

CCC. Card. Conversation. Confirmation

Les històries d’usuari segueixen un principi molt senzill propossat per Ron Jeffries l’any 2001. I que, cal dir-ho, és una bona pràctica inicialment pensada per a un altre marc de treball àgil molt conegut: XP

Ron Jeffries estableix el principi on les històries d’usuari han de ser CCC:

• Card: La història s’ha de poder definir en una targeta de mida reduïda. Això permet a totes les parts fomentar la sempre desitjable capacitat de síntesi, alhora que ens permet centrar-nos en el que realment és important. La necessitat hauria de poder explicar-se de forma senzilla en unes poques línies. Si això no és possible, potser estem intentant explicar una necessitat massa complexa que caldria dividir.
• Conversation: Allò escrit a la història no és el producte de la feina solitària d’un tècnic, un Product Owner o d’un usuari. Ha de ser el producte d’una conversa de valor entre totes les parts interessades. Una conversa de valor significa, entre d’altres coses, comptar amb la participació activa de les persones adequades per tal d’intentar garantir la correcta comprensió de la necessitat i la seva viabilitat. Això implica tant a tècnics com a stakeholders. I recordem que els stakeholders no són únicament usuaris.
• Confirmation: Usualment, conèixer en detall la necessitat no es garantia que aquesta serà finalment construïda amb la qualitat esperada. Hem d’incloure una descripció de com considerem que allò finalment construït proporciona el valor que cerquem. És el que es coneix com a criteris d’acceptació. I aquesta labor és responsabilitat del negoci (no dels tècnics).

Definition of Ready

De l’últim aspecte d’aquest senzill principi (confirmation) probablement serem conscients d’una gran veritat en projectes complexos:

No és suficient comprendre la necessitat per construir una solució

Probablement, per a ser realment eficients i proporcionar un increment de valor amb qualitat, necessitem tenir cobertura d’altres aspectes necessaris. I aquí apareix el concepte de DoR - Definition of Ready La Definition of Ready es pot entendre com un acord en el si del Scrum Team, en què l’equip defineix els elements informatius o les condicions que una història d’usuari ha de contenir per a que l’equip consideri construir-la. I està clar que no és suficient amb una descripció de la necessitat.

<img src="/docs/agils/dor/dor.png"/ width=300>

Aquests elements probablement són depenents del tipus de projecte o la complexitat de la pròpia organització. Però sovint podem determinar algunes condicions comunes a la majoria de projectes. Alguns exemples:

1. La necessitat ha d’estar descrita de forma entenedora i suficient
2. L’equip tècnic ha d’haver estudiat aquesta necessitat. Complementat informativament aquesta descripció de la necessitat i, si fos necessari, hauria tingut una Refinement amb l’usuari o el Prduct Owner per assegurar l’entesa.
3. El Product Owner, al seu torn, l’ha d’haver prioritzada (la història d’usuari) per a que l’equip la pugui considerar una prioritat de construcció per al següent Sprint
4. L’usuari, o en el seu defecte el Product Owner, ha d’haver-hi inclòs a la història d’usuari els criteris d’acceptació, que són els elements que conformen el principi de confirmation

Si la història està “ready” pel que fa a la presència de tots aquests elements i altres que pugui considerar necessaris, resta una acció importantíssima per al funcionament òptim i eficient de l’equip, que és la estimació en esforç de les històries d’usuari. Amb aquesta activitat l’equip tècnic determina el pes de la història en la variable de la complexitat. I això ajuda a l’hora de determinar la capacitat o la càrrega de treball de l’equip a cada Sprint.