CATALOG: Estimations and Sprint Tracking

Proposals DRAFT
Toni Navarro, 10/06/2016

What and when we estimate

How we track in Jira

What and when we estimate

Portfolio planning
The Product Backlog, the list of the Product Backlog Items (PBI) to be performed (Epics,
Stories), is created after the result of the previous activities done during the Portfolio, Product
and Release (Quarter in our case) Planning. During these activities, Business and Product
Owner clarify the scope of the next release and with the help of the Development Team (or
some chosen team members) estimate the size of the PBIs.
The Product Backlog contains the prioritized list of planned items to be developed.
The Product Backlog Items, most likely Epics or big Stories, that are scheduled for later than
the immediate next sprints have not accurate estimations, just relative sizes (or Sprints to be
completed the current practice in Privalia)

Grooming Sessions
During the current Sprint, in the Grooming Sessions, the team analyzes the Product Backlog
with the help of the Product Owner and takes the stories that are going to be most likely
prioritized to be included in the next two sprints and analyzes and estimates them.

This process includes:

Clarifications with the Product Owner about the requirements.

Dependencies analysis.
Technical analysis. I might include a previous analysis done by different assigned
developers.
Split the Story in others if it is so big.
Estimate in Story Points and prioritize the Story. The estimation is done following the
Scrum adapted Fibonacci sequence with Planning poker cards or tools.
o 0, 0.5, 1, 2, 3, 5, 8, 13, 20
Sprint Planning

At the beginning of the Sprint, during the Sprint Planning the Stories that will be part of the
Sprint Commitment are estimated more in deep by creating the Story tasks. These story tasks
usually are a list similar to:
Analysis.
Implementation.
Testing.
Final check (code review, documentation, etc.), UAT review and Merging and
Integration.

The Story tasks are estimated in hours.

This new estimation validates or refines the estimation done during the Grooming.
The discussions inside the team to create the list of tasks and to estimate them provide a great
value since they help all developers to understand the scope of the story and to create by
working together an agreed plan to achieve the story done.

That way we end with the Story estimated in Story Points and its linked tasks in hours.

The tasks constitute the Plan to complete this Story, and allow us detect during the sprint
performance if everything is on track, detect risks and deviations and react accordingly.

Therefore we have different levels of detail in the items estimation, that basically for the
Development team consist on Story Points during the Grooming sessions and Story Points and
hours for the Stories and its tasks respectively during the Sprint Planning.
How we track in Jira
Creating Tasks linked to Stories (Jira Sub Tasks)
We add the Stories in the Sprint Backlog as they are committed by the team and they appear
in the To Do column.
Estimations in Story Points for the Stories appear in the corresponding field.

Then, we create the tasks for every Story with the estimation in hours. Story tasks are called in
Jira SubTasks.
We select the Story and in the right column we press the Create Sub-Task button.
Another way to create the Sub-Task is from the More menu.

We fill the Summary and Description fields.

We add the Estimation in hours of the task in the Story Points of the Jira Sub tasks to make it
visible in the Kanban. (We use this field because the Estimated Effort field is not activated).

Estimated
Hours !

Now we can see the Story estimated in Story Points and the linked Sub-Task with the
estimation (in hours for us) in the Story Points field.
Now we need to do a little trick to deal with the remaining effort in hours for the sub tasks.
We will do it by using the QA Story Points fields as Remaining effort.
At the beginning of the Sprint, Estimated (in Story Points field) and Remaining (in QA Story
Points field) have the same value.

Remaining
20 Hours !

Every time that we spend time working in this task we will adjunst the remaining effort in
hours (remember using the QA Story points field) to our estimation of how much effort is still
pending to finish the task. The Estimated (remember using the Story points field) never changts
since was our committed estimation.
If we have worked 2h in this task the first we should set the remaining to: 18h

Remember: We only log and track invested and remaining time in the Sub Tasks.
 Remaining
18 Hours !

Could be possible that after working 10h in a sub task estimated in 20h we realize that due to
several reasons the real remaining is 30h and not 10h. In this case the estimated will be the
same but we reestimate the remaining.

Remaining
30 Hours !
Moving Stories and Sub Tasks in Kanban
Story cards move between all Kanban Columns as defined.

To Do: When the Story is added to the Sprint Backlog.

In Progress: When any of the Sub tasks starts and therefore is moved to In Progress
column also.
Cross Testing: When all Sub tasks that precede to the one (Definition of Done or Final
Check, etc) that includes the Code Review is in progress. All previous sub tasks to
implement and test the feature have been completed and moved to the Done column.
UAT Testing: When all Sub tasks have been completed and moved to the Done
column.
Done: When all Sub tasks have been completed and moved to the Done column and
the UAT Testing has passed succesfully.

Sub Task cards move between all Kanban Columns as defined.

To Do: When the Story is added to the Sprint Backlog and the linked Sub Tasks have
been created.
In Progress: When a Sub task starts. Every time the invested time is logged the
remaining effort is adjusted.
Done: When the Sub task is completed.
Example of finished Story with all sub tasks completed: CAT-523