Product Backlog Grooming

What’s exactly the product backlog grooming in Scrum

When reading most of the suggested books about scrum, the grooming technique is often cited, but it is not officially normed as a scrum meeting or technique.

This lack of officialization, in my opinion, is an important cause of uneffectiveness in product backlog management and adjustment and, thus, impacts on the team’s performance.

I searched for the word ‘grooming‘ in the official scrum guide and these are the only two statements found:

“Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised.

However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion. Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.”

The technique allows the ProductOwner (PO) to effectively implement what, in the traditional project management discipline, is called as rolling wave planning techique: decomposing and adjusting the scope of the product.

It has been thought in Scrum, to help the ProductOwner in:

• decomposing the product backlog features and epics, in more manageable new user stories
• preparing the stories for the next sprint
• have the team estimating any new story (comprising the ones resulting from the decomposition just mentioned)
• have the team re-estimating any existing user stories
• taking under-control the product backlog and its compexity to effectively plan for the releases

According to what above reported, the grooming is a key meeting that I don’t want the team forget and, hence, I suggest to insert it right in the middle of each sprint and the team can dedicate 1/4 hours.

One of the usual thing that will happen during the grooming, is that the ProductOwner asks the team to decompose an epic into new user stories that must be estimated using the planning poker game.

Let’s say for example that we have a story like the one below and its estimation is 21 story points:

As a student of the college portal
I want to register my account, search for and enroll to an exam
so that I can save time

The ProductOwner knows that such story will not fit a sprint. During the grooming the PO asks the team to help her to decompose it.

The story, for example, is decomposed in three different stories:

As a student of the college portal I
want to register my account
so that the system remember my credentials

As a student of the college portal
I want to search for an exam
so that I can plan the  necessary time to study and prepare the exam

As a student of the college portal
I want to enroll to an exam
so that I can save time

Each story, finally, must be estimated and the team proceed playing the planning poker game.

Risk Management Checklist

Riprendiamo un argomento fondamentale per favorire il successo del progetto: la gestione dei rischi. In un precedente post ho descritto un possibile approccio alla definzione dei rischi, in questo post cercherò di evidenziare aclune aree da indagare per abbatterli.

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Il coltellino sWBSizzero (2^ parte)

Questa seconda parte del post sulla WBS si prefigge di affrontare la tematica della stima dei tempi e costi di un progetto.
Parleremo di scomposizione dei work package in attività, di scomposizione dell’attività in sotto attività e finalmente dell’utilizzo delle tre tecniche di stima più usate: analogous estimating, parametric estimating e three points estimation. 

Questo post è disponibile ai soli utenti registrati. La registrazione è libera.
Per procedere alla registrazione cliccare sulla voce “Amministrazione/Registrati” nella side-bar di destra.
This post is available only to the registered users (free). Please register using the voice “Administration/Register” on the right side-bar.

Il coltellino sWBSizzero

Nel precedente post ho parlato della WBS e delle sue molte applicazioni in ambito di project management.

Mi piace paragonare la WBS al famoso coltellino svizzero; quel coltellino, che nella sua versione originale è dotato di un classico manico rosso, con croce bianca ben in vista, composto da diverse lame e utensili richiudibili.
Spesso sono disponibili, lame a parte, delle piccole forbici, un cacciavite, una limetta, un cavatappi, una penna, un piccolo pettine.

Ecco quindi che potremmo presentare l’equazione: la WBS sta al project manager come il coltellino svizzero sta a MacGyver (ricordate il fantastico telefilm?).

Ecco gli utensili che la WBS ci mette a disposizione:

1. Assegnazione delle responsabilità
2. Utilizzo delle attività scomposte per favorire le stime tempi/costi
3. Totalizzazione dei costi per attività, work package, deliverable
4. Contabilizzazione dei costi per centri di costo (appunto)
5. Analisi degli stakeholders e loro influenza rispetto alla WBS
6. Risk analysis
7. Issue log communication
8. Definizione di un roll-out plan per deliverable

Il processo di ottenimento della WBS è un processo, tutto sommato, abbastanza naturale.

Avendo come base di partenza la risoluzione di un problema, questo viene prima scomposto in parti più piccole, successivamente per ogni sotto-problema si passa alla definizione delle ipotetiche/possibili soluzioni o approcci (brainstorming), tali spunti vengono poi categorizzati e valutati in una visione di pura fattibilità.

Questo processo, spesso iterativo, porta alla realizzazione di un elenco, molte volte strutturato su più livelli, che possiamo definire WBS.

Partendo da quanto ottenuto sopra, si passerà poi alla ulteriore scomposizione dei singoli work package (rami foglia della WBS) in singole attività.

Volendo fare un esempio, nell’ambito della definizione dell’interfaccia amministrativa di un’applicazione software, i work package potrebbero essere i seguenti:

• Gestione delle tabelle anagrafiche
• Gestione dei parametri di sistema
• Gestione degli utenti

Prendendo l’ultimo work package (Gestione degli utenti), l’ottenimento delle attività si ottiene con una successiva iteazione di  scomposizione:

• Ricerca utenti
• Inserimento utente
• Modifica utente
• Cancellazione utente
• Definizione dei permessi e visibilità

Partendo da qui, possiamo finalmente cominciare ad utilizzare i vari utensili anticipati sopra.
In questo post presento il primo: assegnazione delle responsabilità.

Assegnazione delle responsabilità

Spesso la responsabilità di esecuzione del lavoro, si assegna ad ogni singolo work package.

Qualora, però, il carico di lavoro fosse troppo oneroso è ovviamente possibile assegnarlo a più persone, ponendo il focus sulle singole attività.
Ogni persona deve sapere, con certezza e senza alcun dubbio, quale lavoro deve portare a termine, con quali caratteristiche e livello di qualità e in quali tempi.
In questo ci aiuta molto il classico gatt in cui ogni attività è descritta graficamente su un asse temporale e per ognuna viene eseguita l’assegnazione della/e risorsa/e, assegnando in alcuni casi anche il grado di coinvolgimento in percentuale di tempo.

In campo di assegnazione delle responsabilità, l’uso della WBS, è la base per la definizione della matrice delle responsabilità (RACI Matrix). Questa particolare matrice permette di assegnare per ogni singola voce della WBS, una responsabilità di tipo:

• R – Responsible, chi deve svolgere il lavoro e portarlo a termine.
• A – Accountable, chi è in ultima analisi effettivamente responsabile del raggiungimento dell’obiettivo di quella attività. Chi deve validare in ultima istanza, il lavoro svolto dal responsabile sopra descritto.
• C – Consulted, persona che deve essere consultata e con la quale ci deve essere uno scambio di opinioni rispetto a quel task, in quanto particolarmente interessata o qualificata in quell’area.
• I – Informed, coloro i quali devono essere informati sull’esecuzione delle attività correlate (spesso lo sponsor, il line manager o il management)

Nei prossimi post approfondiremo l’uso del pettine e del cavatappi….emmmhh scusate, dell’uso della WBS a fini di stima e totalizzazione dei costi.