Agile Estimation is an easy concept to understand, but where the rubber meets the road and legacy artifacts such as LOE (level of effort), utilization reports, and other artifacts come into play and confuse is the issue. Questions like, “should we estimate in hours?” and “how do I convert t-shirt sizes to points?” arise. It’s important for an organization to come to a common way to estimate, especially as we move up the governance model from team to program to portfolio.
There are many studies that show estimations are valid in the short-term and they are undependable in the long-term. Additionally, when reviewing any value stream like a software delivery lifecycle, utilization takes a back seat to throughput.
I’m not going to get into the many types of Agile estimation. I will, however, provide guidance and a standard used among my colleagues and me at LeadingAgile.
Epics are coarse-grained items that we want to build into our product or process. I prefer Epics fit in a release but they can span releases. Epics should be in the one-month to three-month time frame. T-shirt sizing of Epics would be:
S – 1 Sprint 
M – 2 to 4 Sprints
L – 5 to 6 Sprints
Larger that 6 sprints and the Epic should be broken down
 Sprint or iteration lasting 2 weeks
Features fit inside a release. We need to plan out a release. To do adequate release planning we feature map. The features are sized and prioritized to determine how they lay out over our sprints. Features should be estimated in weeks, so I suggest a one-week to five-week time frame.
Avoid using points on features. Once user stories are broken down, and story points applied, roll up the story points to the feature level. As a result, this will give you the truest “Feature complete percentage” as the team completes user stories in the feature.
If you have a team that is very experienced and has a lot of referential stories, then using story points at the feature level can be acceptable. If this is the case, I suggest you update the points as the user stories are flushed out.
User Story Estimation
User stories should be broken down until they are one to three days in size. New teams may have a difficult time with this, but it should be the goal of the product owner team and the delivery team to work towards this goal.
Consequently, story points should be used to estimate stories.
New Agile Teams
As a part of sprint planning, new teams should perform a task breakdown. During sprint planning, each story is broken into tasks to be performed; database update, java interface needs to be updated, update unit level tests, etc. These tasks are assigned in hours.
Each task should be kept under eight hours so we can see a smoother sprint burndown each day. Anything larger doesn’t provide visibility to the team. Teams that are doing task hour breakdown will use an hours sprint burndown. Teams that don’t break their tasks into hours would use a story point sprint burndown. Some tool vendors may only support one version of the burndown per instance of the tool. Therefore this should be investigated prior to determining how the team will manage its sprints.