Many teams struggle with estimation – if they estimate at all. It’s no great surprise why, there are often unknowns about what’s going to be built and the estimation process itself is time consuming. All the discussion, all the questions – would you prefer your team talk about new features, or actually build them?

Have you ever been discussing a new feature with your team and leave the conversation with more questions than when you started? This is the point of estimation in agile teams: build a shared understanding of the problem you’re trying to solve, and how you’re going to do it.

“How long?” is still a big factor. The amount of effort the team expects to invest in a particular solution could have implications for how you might prioritize it. Also, you’ll probably need an idea of when you’ll be ready for release to coordinate with your marketing teams and other stakeholders.

So, how can we achieve a shared understanding of what we’re building and size it with our teams, if there’s still a lot we don’t know? How can we bring together our near and far term plans into a single roadmap, and what are the practices we should establish with our team to make estimation less painful?

Rolling wave planning

The concept of “rolling wave” planning is fairly simple. The farther away the work is, the less is known about it. The closer the work is (or, higher up the priority list) the more it’s understood by your team and can be broken down into reasonably granular, actionable user stories. The same level of detail would apply to how you approach estimation – the farther away the work is, a more high-level estimate is suitable. But the work that’s starting in the next few weeks, that should be estimated in line with the detail of the stories.

For example (if you look at the screenshot below), we can create a work item for something we’ll work on in the future – in this case “Optimise Trip Booking Flow.” We know we’ll work on it after we’ve completed the “Trip Booking MVP.” For this timing, it’s good enough for us to create an Initiative and give it a ballpark estimate. We’ll see the issue on our future roadmap, but we don’t need to start breaking it down yet.

Compare this to our “Trip Booking MVP” work item, which has already been broken down into epics and stories, and is ready for the team to start work soon:

An ideal end state is to have the next three sprints or six weeks worth of work well articulated, estimated, and ready to go for the team. You can still react to change, but you’re also really organised!

Pro tip
It’s not realistic that every single item in your backlog will be estimated perfectly. In this case, you can use Portfolio’s default estimation values (find it in your plan’s scheduling configuration) and you can set default values for each level in your hierarchy.

This means that every issue that doesn’t have an estimate will inherit this default value, allowing you to have this issue included in your data-driven roadmap. The ‘default’ value is over-ridden as soon as you add your own estimate, or the team starts to break down the work. This default value also won’t appear in Jira Software when you commit.

Best practices on building a process for estimation

Depending on how your team decides to estimate, you can apply the same planning unit – but at a more abstract level.
A lot of teams will ‘shirt size’, so will apply the same estimation process (such as planning poker) but the available options are much more high level. For example, your team could choose from a small, medium, large, extra-large – and know how this translates to a band of time or story points in the background.

For example:

Small – 1 sprint / 2 weeks
Medium – 3 sprints / 6 weeks
Large – 6 sprints / 3 months
Extra-Large – 12 sprints / 6 months

Set up this process together with your team by looking back at big chunks of work that you have completed in the past and choose which should be an example of each ‘size’. Having these examples will make it easier to make a fast decision – you can compare how much effort you believe at the time you would need to invest to get this new feature done, based on the information you have to hand. Given you don’t have all the information, and requirements may change, there’s no need to agnonise over the estimate – ballpark is all that’s needed at this point in time.

Remember to note any assumptions, risks and questions that come out during early stage estimation. You’ll need to consider these as you continue to refine the feature you want to build and more importantly, your team needs to feel safe that the caveats that may have come with the estimation provided haven’t been lost or forgotten.

Pro tip
Translate your shirt sizes to either a story point or time representation and add this number as your estimate into your new initiative or epic inside Portfolio.

You can continue to evolve your estimate as work gets broken down further, but having a representation of effort from the start will allow you to make more informed decisions regarding your roadmap.

Improve your estimation over time

Getting into a regular estimation practice can be key for having this level of backlog-readiness – it’s means you break your work down over time, instead of having to take a big bang approach just before the sprint starts, or the work is due to begin. There aren’t many teams out there who seem to enjoy lengthy estimation sessions.

Try scheduling a few short sessions over the week to build up your backlog over time and go into each estimation / refinement meeting with a clear focus of the item you’d like to discuss with your team. You may leave the meeting with more questions than answers, but you’re better off thinking through those questions ahead of time than when you’re in the middle of developing the feature.

To help with your team’s estimation, in your retrospectives prepare some data on how you had first estimated a particular piece of work and compare this to your final estimate further down the line. Were you much over or under? What did you learn from this piece of work that you can share with the entire team to feed into your future estimation practices?

Doing this regularly will help your team build more confidence in their ability to estimate within a reasonable ballpark and most importantly, the team will be learning together.

Pro tip
Use the Original Estimates column inside the Portfolio Scope Table which will allow you to compare your very first estimate to what your estimate looked like, once it has been broken down by the teams.


Learn more about Portfolio for Jira

Estimation best practices with Portfolio for Jira