Let's go through them:
This method is popular with Microsoft teams, but it has the problem of not easily mapping to the common 7 numbers when you enter it into a Task tracking Bug database. eg.
1 = XS
2 = S
4 = M
8 = L
16 = XL
32 = XXL
64 = XXXL
Please note: In some teams which only use Small, Medium and Large the following numbering is applyed respectively 2, 4 and 8.
- Figure: Bad example - Estimation using T-Shirt sizes
Fibonacci Extended (1-100)
Planning Poker is a very effective Product Backlog estimation technique and the most common method is using Fibonacci numbers (1,2,3,5,8,13, etc.). This was made popular by Mike Cohn.
- Figure: OK example - Estimation using Planning Poker with large numbers
Mike Cohn introduced changes to the original 7 cards, by changing the 21 to 20 and adding 40 and 100 to indicate very large user stories called Epics.
Ken Schwaber (the father of Scrum) says in his Scrum Certification course, that he is not a fan of the extra cards and says he prefers teams keep to the original 7 cards.
- Figure: OK example - Estimation using Planning Poker with only small numbers
Estimating using doubling numbers makes relative sizing simple. An 8 point PBI should be about twice the size as a 4-point PBI. This method also simplifies PBI swapping where a PBI is replaced with PBIs totaling the same number of points.
It has one other advantage over the Fibonacci sequence, it is easier for non-techies because the numbers aren't whacky and the name isn't bizarre.
Figure: Good example -Doubling simplifies relative sizing
Another method of estimating is the "Thrown method" as described Martin Fowler. http://martinfowler.com/bliki/ThrownEstimate.html
This is particularly useful if you don't have Planning Poker cards. Instead of Fibonacci numbers, estimates are from 1 to 5. It's nice and simple, and you only need the fingers on your hand.
The action is done in the same method as the game 'Rock, Paper, Scissors'. The options the developer can estimate is 1,2,3,4,5
- Figure: User Story estimates using the "Thrown method"
#1 Don't Shout Out
It will just influence other people's votes.
#2 Guidelines for Estimating User Stories (aka Anchoring)
Every team is different, but you can use the following guidelines for sizing User Stories.
Figure: Good example - Example User Story estimates
Example User Story|
|1||A change to a message box|
|3||A timeboxed task for 1 day x 1 guy|
|5||A timeboxed task of 1 day x 2 guys|
|21||More than a month with a couple of guys.|
Tip: Don't include these in a sprint because they are too risky - ask for them to be broken down.
#3 Using a Chat Program
If you are working on a project with a remote team, use Skype chat to size stories using Planning Poker. Everyone should give their points for stories at the same time to avoid influencing each other.
#4 Big Stories Smell
PBIs of greater than 1 day are a smell and PBIs greater than 2 days are a stench. If User Stories are estimated at more than 1 or 2 days of work, consider splitting them into smaller pieces to keep them under 1 or 2 days. See Do You Break Large Tasks into Smaller Tasks?
#5 Use Spikes
If you do find a very large User Story, consider using a Spike (aka. an investigation task) to help work out how much work will be involved.
#6 Small stories
As some stories can be obviously very small, we allow any member of the Team to propose that a Story is 0.5 points and no further discussion is required. If there is no objection (i.e. immediate consensus is reached) then the story is given 0.5 points and the Team move on to the next one. This is the only way a story can have only 0.5 points and always indicates that is was a quick decision and therefore may have some risk attached.