Are there any methods to fairly estimate story points for a project before deep diving into the planning poker part. I am asking this because sometimes at project initiation it helps to know the tentative amount of work in terms of story points.

Are there any techniques that could be used to roughly come up with some figures at the start?



A common approach is to do a rough initial estimate of the Product Backlog using a sorting method like the bucket system, with variations described by ThoughtWorks or Mountain Goat Software. A few other techniques are also listed for reference at the very bottom of this answer.

The general idea of the bucket system is that you identify a baseline story, assign it 1-2 story points, and then guesstimate relative sizes of the rest in relation to the baseline. It's similar to Planning Poker in some ways, but intended to provide quicker results at the expense of granularity and accuracy because you aren't doing the level of decomposition that you would normally do during Sprint Planning or Backlog Refinement.

This type of sorting can be very quick when compared to Planning Poker, especially if you remember that the point of the initial estimate is to do high-level release planning, rather than plan out all your sprints in advance. In other words, you are really just doing a rough estimate of the first couple of sprints, while the rest of the Product Backlog is full of themes and epics that you may or may not ever get to under the YAGNI principle.

You can use bucket-sorting, or other similar techniques, to create inputs for the remainder of the project. You will still need to replan and re-estimate each Sprint, and determine how (or even if) you want to form a release plan for the overall project. I discuss each of these topics in more detail below.

Replan and Re-Estimate Every Sprint

Remember that initial backlog estimation is the start of a series of processes, not the end-state. You will re-estimate the likely stories for each upcoming Sprint again during Backlog Refinement, and do another fine-grained estimate during Sprint Planning at the start of each Sprint.

In other words, your initial estimates will change over time:

  1. As the Cone of Uncertainty narrows as the team and stakeholders gain additional domain knowledge and feedback from previous iterations.
  2. As changes are made to the Product Backlog or user stories, since the Product Backlog is a living document that is expected to change throughout the project lifecycle.
  3. As the team gets better at estimating, and as the team's capacity over time stabilizes.
  4. As just-in-time planning for each Sprint is always going to provide a more accurate forecast than guesstimates from project initiation.

Your release plan contains high-level estimates of the "broad brush-stroke" variety, while your Sprint Backlog really ought to contain a more granular forecast of the work immediately ahead of the team in the current Sprint. Some teams use bucket-sorting for Sprint Planning too, but I'm a big fan of Planning Poker to estimate in Story Points during the first half of Sprint Planning, and sanity-checking the Sprint Backlog tasks against the team's estimated capacity in ideal hours or calendar days during the second half to avoid overcommitting.

Your mileage may vary by technique, but the rule of increasing granularity as you move from Release Planning to Sprint Planning should still apply.

Plan Just Enough for Agile Release Planning

The main goal of initial planning is generally to make an educated guess about velocity, and to provide an initial baseline for agile release planning. It can be tempting to estimate the entire Product Backlog, but in my own practice I've found that estimating just enough of the backlog to forecast the first few sprints is enough to make educated guesses for the overall project release schedule. Most of the remainder of the backlog won't survive the continuous cycle of Backlog Refinement, Sprint Planning, and modifications from Sprint Reviews and Sprint Retrospectives anyway.

A decent Jedi mind-trick here is to do the bucket sorting, guesstimate the initial velocity, and then see if the stories that would be picked for the first Sprint feel like they would fit. Sometimes, you'll find that something just feels wrong about the estimates of Product Backlog Items or team capacity, while other times you'll feel like you have at least an 80% chance of meeting your first Sprint Goal using the velocity and story-point estimates you're guesstimating as your baseline.

In agile release planning, the traditional triple-constraint still applies, but the dimension that most often shifts is scope. So, you can still form a release plan based around key milestones in the project using epics/themes, but you will have to adjust your Sprint Goals and refine the scope of each Sprint to fit the release plan. This approach doesn't require a full estimation of the entire backlog.

Alternatively, you can base your release schedule on how long you expect it to take to complete all work in the initial Product Backlog. If you do this, you will need to periodically re-estimate the entire remaining backlog, and track a release burn-down in addition to ensuring you have a potentially-shippable product at the end of each Sprint.

Obviously, I strongly recommend the former approach. Still, if project scope is fixed but schedule is an adjustable dimension for your project, then the latter approach can work, too. It's just more work, and in many cases less accurate during early-stage planning.

See Also

These links aren't particularly canonical, but they address some well-known alternatives to either planning poker or the bucket system. There are certainly others, but these are among the most common:

Relative Mass Valuation has a lot of mindshare in the agile community, but despite the name I think that TFB/NFC/1 is a surprisingly useful technique that deserves more attention. YMMV.

  • Nice post. I think it bears repeating: re-plan and re-estimate. Initial estimates are always off. There is no way to do them accurately - diligence, effort, desire, and clever strategies don't help. But it only takes a few iterations of feeding actual observations back into your estimates to turn them into something useful. – jwepurchase Jun 3 '16 at 19:05

There are several techniques used that help with story point estimation.

One approach is to pick out a baseline story and use this as a reference for the other stories. In a BI team I worked for their baseline story was to add a single measure to a report. They would judge all other stories against that one. Having a baseline made it quite simple for the team to say 'smaller than the baseline' or 'bigger than the baseline'.

Another approach is to write your stories on cards and sort them in to size order. So that the biggest story is at the top and the smallest story is at the bottom. Then you decide where the boundary points are in the list between the various story point sizes. For example, say you had 20 cards sorted in order and you decide the bottom three cards are 1 point, the two cards above that are 2 points and so on.

Mike Cohn has blogged about this.


I have had great success with Swimlane Sizing to estimate a big list of possible changes, its is similar as the bucket system CodeGnome describes.

Divide the deck of stories amongst your team and ask members to spend a maximum of 5 minutes silently placing their stories in the swim lanes – with stories of increasing size from left to right. E.g. smallest stories in the left-most lane.

Read the whole process in this blog post: Swimlane Sizing – Complete & Fast Backlog Estimation


I do not see any way around doing a rough first estimate on the backlog.

On top of this you need need to factor in expected bugs as well as room for refactoring, misunderstandings, improvements. One good technique to visualize the risk and to get a understanding of the landing zone of the project is Monte Carlo simulation e.g.https://agilemontecarlo.com or via downloading a Monte Carlo simulation excel sheet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.