Agile Estimation Guidance

WRITTEN BY Marty Bradley

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 I 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 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 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 it’s sprints.

Agile Estimation Flow

Agile Estimation Flow Chart

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

3 comments on “Agile Estimation Guidance”

  1. 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.

    Reply
  2. 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.

    Reply
    • 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.

      Reply