About me

Sono Andrea Regoli ho 31 anni e lavoro in ambito IT da oltre 10 anni.

Ho iniziato come programmatore e successivamente mi sono poi specializzato come Business Analyst: ottimizzazione/automazione dei flussi aziendali.

Ho sempre lavorato a contatto con i clienti in quanto consulente, di conseguenza ho maturato una buona capacità di relazione e comprensione delle loro richieste.

Attualmente svolgo il ruolo di Project Manager IT coordinando un team interno e alcuni fornitori esterni.

Mi occupo del monitoraggio dell’intero lifecycle dei progetti, delle possibili problematiche e delle evoluzioni future.

Inoltre seguo la gestione dei clienti/stakeholders dalla definizione di offerta alla raccolta feedback post deploy al fine di raccogliere possibili nuove features da realizzare per il miglioramento del servizio offerto (Continual Service Improvement).

Sono appassionato di tecnologia, quindi cerco sempre di rimanere aggiornato e nel tempo libero mi diletto a sviluppare app per mobile

Contact Me

User's feedback

Here some user's feedback about my Windows Phone apps

Blog

Story Point vs Estimated Time and how to config Jira to help us

What are story point? what is this shit?! Fibonacci series? naaaaa IO estimate my work in days or hours… I don’t want to bother with this useless stupid system.
How many of you have you thought at least one time this sentence?
I’ve thoughted it for some months when finally I found a great article that allow me to understand why I was wrong!

There are lots of topic that talk about it and I don’t want to write about it in this topic.

Story point is the right metric for our user story estimation.
Could it be the only metric in our scrum project?
No, you can estimate both with story point and time but each of them has a target.

Use storypoint to estimate User story. User story are what our team have to work.

This could be enought to work on a IT project.
If you or your team prefer you could use subtask.

Starting from a user story split it in subtasks that are necessary to realize the user story.

Now your team have two options

  1. Estimate subtasks
  2. Do not estimate subtasks

There is no role, I prefer that subtasks are estimated but it’s not required.
If your team like to estimate it, now the right estimation metric is the time.

To sum up:

  • User Story are estimated in story point (and business point to understand the business priority)
  • subtasks are estimated with time

Starting from this concept, here how to achieve it in jira:

I use story point to evaluate user story, new feature and improvement. I don’t use storypoint to evaluate task, bug and obviously subtask.
In my mind a task is something that I use to ask developers to change but it’s not a bug. Therefore I use task to say something like “the button is not aligned to the table”. Any Change Request is a story not a task, even though the PO change the request IMHO.

Considering that, It means that the effort of doing bugs and tasks are not considered and It’s true. This means also, that probably the story point burned in this sprint will be less and I like this effect bacause this consider if the work done was good or not.

In order to track storypoint and time in the same SCRUM board you have to set this configuration:
Your board –> Config –> Estimation
estimation-dev-board

Pubblicato in Agile, Jira, SCRUM | Contrassegnato , , , , | Lascia un commento