Da quando Kent Beck ha introdotto il concetto di User Stories in Extreme Programming, la loro struttura si è evoluta e consolidata nel tempo. Oggi è quasi scontato scrivere i requisiti agili sotto forma di storie utente, che sono diventate la tipologia principale di attività che popolano un product backlog agile.

Purtroppo, capita spesso che questa pratica venga seguita in maniera superficiale, usando il pilota automatico e senza dare il giusto peso alle parti che la compongono. A volte, una User Story nasconde addirittura un requisito fisso e indiscutibile che si allontana dal concetto fondamentale di negoziabilità.

In questo talk ripartiremo dalle ragioni che stanno alla base della User Story e proveremo a guardarle da un punto di vista differente: invece di mettere l'utente come elemento centrale, ragioneremo innanzitutto sulla situazione che fa scaturire il bisogno nell'utente, sul "job-to-be-done" che deve essere soddisfatto.

Quali differenze ci sono fra i due approcci? Quali sono i pro e i contro? E se provassimo a unire le caratteristiche di entrambi, cosa cambierebbe?

Se siete curiosi di scoprirlo, non perdetevi questo talk!