In this post, I will focus on how should we do estimates in an Agile project.
Just to set the proper context, it is important to keep in mind the main tenets of Agile:
In any Agile project, the primary measure of progress is working software, which means that any other kind of deliverable is basically of low value.
Another main tenet is simplification: Maximize the amount of work not done!
During development, we need to be able to control the process, and we all know that we can’t control what we do not measure, so we do need some estimates.
But we should choose any software sizing estimation technique that is good enough for us to deliver working software: the focus should be on good enough!
When it comes to Agile estimation techniques, there’s a lot written about it.
On most books and articles on Agile Estimation techniques, the lion’s share goes to a technique popularly known as Planning Poker.
I agree with the idea that Planning Poker is fun to do, but I also agree with the well established fact that any team using Planning Poker will require a lot of time to complete this activity for a set of user stories. A lot of time spent on anything different from delivering working software is the wrong thing to do when you are using Agile.
Spending a lot of time on estimates is not consistent with the idea of maximizing the amount of work not done (more on this at the end of this post!).
There are alternative techniques, some of them are better versions of Planning Poker. Among the few techniques that have succeeded where Planning Poker has not is a technique known as Silent Grouping.
Even though Silent Grouping shares some elements with Planning Poker, it has avoided to include the elements that in PP contribute the most to the long duration of the sessions.
What is the basic “operation” of Silent Grouping?
The “game plan” for Silent Grouping has a Setup stage, two rounds of estimations and a Reflection stage.
The main elements are a card for each user story to estimate, a PP Board and a Parking Lot.
The most important aspect in the entire “game plan” of Silent Grouping is that the participants do not talk to each other during the two rounds of estimations (thus the “Silent” reference).
It is meant to eliminate, as much as it is possible, any kind of discussions among participants during the rounds.
At the Setup stage, the moderator will lay the ground rules of the session to the participants, and set expectations.
During the first round, the team members that participate in the session stand in a queue, so that each member has to wait for her/his turn. When it is the turn of a given team member, she/he will pick up the next card from the stack of cards to estimate, and put the card at the board within the “swim lane” that belongs to the number of points that the member considers to be the closest estimate for that given user story.
During the first round, each participant will give feedback on just one single card for each given turn at the board.
If the list of participants is small and the set of user stories is large, participants will have to iterate as many times as necessary so that each user story card is assigned an initial estimate.
Even though any given participant may give feedback on more than one card during the first round, any given card with have feedback from one and only one participant during the first round.
The board with “swim lanes” shows at the top the number of user story points for that group (thus the “Grouping” reference). Typically, the board will have 8 “swim lanes” or groups.
The first “swim lane” at the left side of the board has the number 1 at the top, and the number increases for each following “swim lane” to the right according to the sequence of Fibonacci numbers, typically until the number 34 (that 8th number in the Fibonacci sequence):
1, 2, 3, 5, 8, 13, 21, 34
(Did you ever wonder WHY is it that the Planning Poker Board NEVER has a number bigger than 34?)
During the first round, participants give feedback on card estimates in complete silence.
During the second round, the participants stand in a queue.
When it is the turn of a given team member, the participant is free to change the estimate of all the cards, by moving each card and placing it at the board within the “swim lane” that belongs to the number of points that the member considers
to be the closest estimate for that given user story.
It is possible that during the second round, some of the cards suffer a lot of moves. It is the responsibility of the moderator of the session to take note of these “controversial” cards (the cards that get shuffled at lot).
This second round is also done in complete silence: Participants give their feedback just by moving cards, one participant at a time.
During the second round, each and every participant is free to give feedback on the estimates of each and every card, but this time, each participant will have one and only one turn at the board.
Once the second round finishes, the moderator will place all the “controversial” cards in the Parking Lot (any kind of place holder for these “outlier” cards: a box, a basket, etc.).
At the reflection stage, if there are any “controversial” or “outlier” cards, participants will resolve any disputes of estimates for these cards only, but this part should we run without any kind of discussions or arguments. The goal is to either agree on a fast estimate for each card or else.
The Product Owners should not participate in the rounds of estimations, but could give feedback to participants during the reflection stage, if and only if any participant has questions regarding any given “outlier” user story: just short answers to simple questions.
Regarding this “outlier” cards, two possible outcomes could happen during the Reflection stage: the participants are able to easily resolve the dispute on the estimate of a given “outlier” card, or they don’t.
If they easily resolve the estimation dispute for a given “outlier” user story, everything’s fine with that user story.
If they are not able to resolve the estimation dispute for a certain user story, I can tell you that the estimate is not the ONLY hard question that the participants are not able to answer regarding that user story!.
In a sense, Agile is an adventure of exploration and discovery around a given set of user stories.
When the team members cannot agree on the estimation for a given user story, it could be a clear indicator that the team has not explored that user story enough at that point in time, so, the user story is not ripe enough for development.
If your team faces this kind of problem with any given “stubborn” user story at the end of the Reflection stage of a Silent Grouping session, the moderator should set aside each and every “stubborn” user story for further exploration and discovery.
As any Agile team is free to organize itself to solve any issue, the team should decide on how to deal with this situation: which of the team members should work on the exploration and discovery of the “missing” details of the “stubborn” user stories?
After the necessary stage of exploration and discovery is done for all user stories, they should be all ripe for rapid estimation and development.
On any given project, a team may need to run a few estimation sessions to cover all user stories, mainly because on any given project not necessarily all user stories are known from the get-go.
As a parting thought, we have come to the conclusion that any estimation session in Agile should always be a fast affair.
We should use techniques like Silent Grouping instead of Planning Poker, and most importantly, the team should never waste time feuding on estimates.
The proper way to deal with “stubborn” user stories is to set aside a group of team members to do some further exploration and discovery of the details of such user stories.
Kind regards, GEN