Let’s say You have just finished to create the user stories for your product and, a bit proudly, your product backlog now counts two or three hundred of items. How can you estimate them, effectively?
It is not always possibile to have all the items of the backlog estimated using the planning poker game. This estimation is somehow precise, but it is actually time consuming and not practicable in one-shot against the whole backlog.
Having a quick first rough estimation of the whole backlog, however, could be the right answer in order to start planning for the development of the product, dividing the effort in releases and giving some forecasts to the management, in terms of schedule and budget.
Actually, we are assuming that these first estimations won’t be perfect but, at last, what estimate is perfect? And moreover during the initial phase?
A technique that could help here, is the Agile Raw Affininity Estimation. I usually organize a workshop of 3/4 hours, within which the team usually can estimate more than two hundred stories.
Participants, material & preconditions
The participants involved are: the ProductOwner, the ScrumMaster and the core team. One important constraint is a logistic one: the room where you are going to hold the meeting, must have wide walls where to stick the user stories.
This is the material you will need:
- A4/Letter sheets
- Post-it notes
- Paper tape
And these are some pre-conditions:
- well-formed stories (U-INVEST),
- the ProductOwner should have already presented the stories to the team even if at high-level (epics)
- the stories must be all printed each on a A4/Letter sheet (take care of the font size you use: every story must be clearly readable from 2/3 meters away from the wall) ,
- a printed copy of the team’s definition of done.
These are the main steps of the technique:
- Workshop explanation
- Silent estimation
- Story points estimation
- Estimation review
Workshop explanation (Coach/ScrumMaster)
The Coach/ScrumMaster explains the team and the ProductOwner, the scope of the meeting and come into a detailed explanation of the process’s steps.
It’s important that s/he stresses the rules underlying the agile estimation (story points, complexity, relative weight, delphi, etc.) and remembers the team that each story estimation should aim to satisfy the definition of done the team already decided.
The Coach, then, sticks on the very bottom-left side of the wall, a sheet of paper reporting the word “SMALL” on it and on the opposite bottom-right of the wall another sheet with the word “BIG”. Finally, he rolls the tape from left to right, joining the two words.
This because, the team will hang the stories on the wall according to their size, forgetting, for this first step, about the estimation in figures, but reasonging about a gut estimation and positioning them in respect of the scale (SMALL>BIG) and of the other stories already attached (relative estimation).
The ProductOwner, then, gives the team the pile of user stories already prioritized (top of the pile most important stories).
Silent estimation (Team)
Now it’s time for the team to step in. During this phase the team remains silent. Every member has two possibilities: estimate a new story or change the estimation someone already did of a story.
Estimate a new story
In turn every team member, take a story from the pile, a piece of paper tape and stick the story to the wall, according to his/her perception of the story’s complexity (SMALL vs BIG) and in respect of the other user stories already hanging.
Change an existing estimation
The team member do not take any new story from the pile.
S/he detaches the story to re-estimate and sticks it again in a new position, according to her/his complexity perception and the other stories already hanging.
The process above described, continues until all the stories have been estimated.
Every team member can ask clarification about the user stories to the ProductOwner.
Story points estimation (Team)
Now it’s time to transform a position on the wall, in the corresponding estimation in story points. My suggestion here is to use the Fibonacci series.
The team writes each number of the series on a single post-it (1,2,3,5,8,13,etc) and attaches them near the line of the scale.
Estimation review (ProductOwner)
Well, the team now deserves a break and a coffee and leaves the room.
The ProductOwner, which remained silent during the whole estimation process, could necessitate some clarifications.
Thus, she takes small orange/red post-its and attach them on each story that needs a clarification about the estimation done.
When the team comes back, it gives the clarifications the ProductOwner needs about the estimations. Sometimes it happens that after the discussion, the team has new elements and decides to change the estimation, moving the stories down the scale.
Consolidation (Team + ProductOwner)
This is the last step of the workshop.
The team and the ProductOwner write on each user story, the right estimation according to the position and the corresponding number.
The ProductOwner, finally, gathers the stories and inserts the figures into hte product backlog and that’s it!