Agile Estimation Guidance
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.
Epic Estimation
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 [1]
M – 2 to 4 Sprints
L – 5 to 6 Sprints
Larger that 6 sprints and the Epic should be broken down
[1] Sprint or iteration lasting 2 weeks
Feature Estimation
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.
Comments (8)
Amir
you may find sizing feature based on sprints, rather than weeks, useful as well. Specially, if your sprint are no more than 2 weeks and you are using visual boards for features.
Alex Kanaan
Nice breakdown. Very often teams estimate at the user-story level and below but don’t pay enough attention estimating upwards – interesting to also see T-Shirt sizing applying at the Epic level. Let’s remember the ultimate objective is to deliver value or tested-working software to end-customers – so I would also advise having a clear definition of done that reflects that commitment – I have often seen teams too focused on estimating development efforts but failing to include other work as part of the estimates such as any research or conversations that add clarity to the backlog, various testing activities (including PO acceptance testing), integration, deployment, etc.
Marty Bradley
I agree about a clear definition of done. This goes to the whole concept of shared understanding which is key to building the right solution and helping with predictability. The t-shirt sizing at the epic level is a great way to know if you have real epics or if they are actually initiatives. It’s best if the epics are broken down to the point that the business can provide real value. If you can attach real value; cost of delay, IRR, etc and the epics are small enough it’s easier to get to bi-monthly or quarterly budget review/ roadmap adjustment to always focus on highest value to the business.
deepa
Hi Marty,
This looks great!! How does this affect the sprint burn down chart? Can you provide a mapping showing how the hours add up to T-shirt size
Regards,
Deepa
Cori Neslin
This is an interesting guide, thank you for sharing. Can you tell me how the t-shirt size compared to # of sprints was estimated?
Marty Bradley
Hi Cori,
An Epic describes some value that the business would like delivered. We want to deliver value as early and often as possible so we like to keep Epics under 3 months or 12 weeks. We make the assumption that a sprint is 2 weeks in length. So a large Epic would be up to 12 weeks (or 6 sprints). We then just tier it down from there.
Marty
Nikolaos Kasvikis
I noticed that for Epics and Features, you don’t estimate the size; but the lead time. Is it the case? How does it help with long-term planning? How can you evaluate how realistic is the estimation of lead-time?
Bhavin Shukla
In my head I am thinking estimation is a combination of effort, cost & complexity. If I am boxing epics estimation into time frame, I am probably ignoring others. What would I be missing?