In traditional software development methodology, members who are in charge of a feature will estimate it alone based on his own experience; and if the estimation is incorrect (which is very usual), the developer will hear the same old “You yourself estimated it, you have to complete it in the estimated time”.
In Agile Development, team agreement values more than individual idea. In other to accomplish the estimation, the whole team will do estimation for a US and how to complete it before any code is written. Here at IMT, one of the methods we use is Poker Planning.
Equipment for Poker Planning:
A set of cards in Fibonacci-like Sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? and Big. Each team member will hold in their hand a set of above cards.
The numbered cards present how big a US is, the bigger the number, the bigger the US.
The “?” card presents “I don’t know, something unclear.” and the “Big” card presents “This US is too big to be estimated, it needs broken down.”
The poker cards set
How Poker Planning works:
Step 0: The Product Owner selects a simple and small, but not very small, User Story. The PO will then clarify it to the team, after all the team agrees with the US’s specification, we say the US worth 8 points. We call this US the “Anchor US”.
Step 1: The Product Owner explains another User Story, and the team will then ask questions for clarification.
Step 2: Each team member puts out a card facing down presenting their estimation points comparing to the “Anchor US”.
Step 3: Everyone reveals their cards, and Scrum Master will go round and ask everyone to explain their number. Here the team can have a team collective estimation without influence from an individual.
Step 4: Repeat from step 2 until the team reach to consensus estimation. After that, we move to another User Story.
Members discussing about the estimation
Note: in order to avoid wasting time, the team must always compare the estimating US to the Anchor US which everyone understands clearly.
The team will estimate first, and then assign US to members.
Why Poker Planning works:
Poker Planning works because it prevents the influences of other members, by having their card face down, everyone needs to think about the feature and estimate with their own knowledge; no one can follow another member’s estimation.
By comparing the difference in the cards, the team can collect hidden knowledge or views from each member, as QA has different idea than DEV or DBA. It also helps everyone to understand about other members’ task to support later.
By doing estimation first then assigning, it also removes the disinterest in others member estimation.
Last but not least, Poker Planning creates a team spirit and makes the team a self-managing team.