# How do you estimate epics?

Let's say we have a brand new project and we want to raughly come up with a bunch of releases and its dates to give the business a vague idea of when we will finish.

Obviously we have all our user stories, so we can just estimate them all, run a couple of sprints, figure the team's velocity and do the math.

This is cool. The point is that we might have quite a few stories that are epic because we don't know yet how to refine them or did not have the time to do so or a conbination of the two.

How do you get the team to estimate them? Epics have normally no acceptance criteria and are quite vague so the team might get a bit puzzled.

What's the general approach to the problem?

• Try this – run a couple of "sprints" whose stated purpose is to "refine the 'epics.'" Focus your initial attention on fleshing-out these gray areas, bearing in mind that any of them could easily wind up affecting those things that you (right now ...) thought that you were ready to do. "Don't be in a hurry to begin." Quite(!) literally in this case: "Haste Makes Waste!" Commented Jul 30, 2020 at 18:55
• Define "epic". There are two common definitions for what "epic" means: (1) a container for other work, such as stories or (2) a story that has yet to be refined and decomposed into something that can be finished in one iteration. Commented Jul 30, 2020 at 19:33
• My impression as a scrum skeptic is that in scrum, you don't reveal when you'll finish. You discuss when you'll release the next increment of value. This is a major reason why I'm a scrum skeptic.
– MCW
Commented Jul 31, 2020 at 12:03
• Commented Aug 1, 2020 at 12:08

When you assign points to an user story, you do so after the team discusses the details, gets answers to their questions, talk how to implementation it, etc. Basically, they know enough details about the story to say "this is a 2", or "this is a 5".

Epics are much larger. They are collections of stories. You don't work on an epic, you split that epic into stories and work on those stories. The epic will then simply have the points of all its stories combined. The way you find out how many story points an epic has is by splitting it into stories, discussing those stories, detailing what needs detailing, estimate the stories, and get back a total of story points for the epic itself. And you do that as you refine your backlog and as you plan your next sprint. You don't do that for all the epics in the backlog.

Your backlog contains fine grained future work at the top, and larger and larger items of work as you move towards the bottom. The top work is estimated, the bottom work not so much. For these reasons many teams don't estimate the epics or stories at the bottom, or instead of using story points, they switch to T-Shirt sizes (Large, Extra Large, etc).

But when you want to forecast a release planning at the beginning of the project, having things in the backlog lacking an estimate or being identified as "Extra Large" isn't very helpful. So you need an estimate somehow.

The standard approach to estimating is to take large work items and split them in finer details that you can estimate with some confidence. This mean taking all the epics and splitting them into stories. You basically end up with Waterfall, not Agile. You try at the beginning to detail everything down the road. This creates a lot of effort and you are planning things when you know the least about your product. Executing the project will then always contradict your estimates and planning. Agile practitioners know this, so they don't want to invest too much effort up front, just enough to get an feeling of things. Then with each sprint you compare your progress with the estimate and adapt your work and your plans.

So how then do you estimate a full backlog of epics without a lot of effort in detailing everything?

When estimating epics, there are two things that hold the same as for estimating stories:

• a discussion that leads to a consensus about the size of an item;
• relative sizing of items.

So, you take your epics and you start discussing them enough to determine their size. You can't say 300 story points (SPs) without going into many details, but you can discuss enough to say that this is "Large". You do this for all the epics and you put them in buckets of relative size: XXS, XS, S, M, L, XL, XXL. You can do this even if you don't have all the details.

So now you know how epics compare to each other. But you still can't make a release planning because you can't match T-Shirt sisez to team velocity. Saying that the team does 20 SP each sprint is not the same as saying that they can finish one XXS item, two S, and one M. So you need to convert from T-Shirt sizes to story points.

You look at your epics and you try to identify one that is "representative" to use it as a baseline. You take this epic and you discuss the sh#t out of it, split it in stories, detail those stories, and estimate those stories in SPs. You then add all the SPs together to get the total number of SPs for the epic. You then size all the epics based on this baseline epic. If the baseline epic was an S and it turned up as 300 SPs, then all S epics will be 300 SPs. You then plot all the other T-shirt sizes using this measure.

Some teams consider an M to be 10 times larger than an S, and L 10 times larger than an M, and so forth. Some try to fit the sequence onto Fibonacci numbers, so if S = 300 SPs, and M is the next measure, then in Fibonacci numbers this means that an M = 500 SPs, because that's the next number in the sequence.

Not that you have the total amount of SPs, and you know the team velocity, and the lengths of each sprint, you can plan some releases and place some dates on them. Keeping of course in mind, the warning that people should not consider this release planning forecast as deadlines. As you find out more about the product and run some sprints, you can collect real data to match your initial forecast and see how you did, or how you will do from then on.

• So do you think it is appropriate to say that coming up with exact dates for the various releases is just an agile antipattern? That it is practically waterfall in disguise? Commented Jul 31, 2020 at 11:58
• It depends on what you do with those dates. The reality is that you can't just start working on a product, deliver every couple of weeks and say to everyone that "it will be ready when it will be ready". People still need to fit that product into everything else happening in the company. They need to know if it takes 6 months or 6 years and then decide what to do. The idea is to not consider the dates as a promise because estimates are just that, an estimate. You might be early or late, no matter what methodology you use, Agile, Waterfall, etc. That's just one reality that Agile acknowledges. Commented Jul 31, 2020 at 12:21
• There's nothing inherently wrong with having fixed release dates - in fact, under methods like Scrum you potentially have a release (or at least a releasable product) at the end of every Sprint. But it's important to acknowledge that you can't predict exactly what features each release will contain, especially the further in the future you look - presumably the release at the end of the next Sprint will include the features being worked on in the Sprint, but the release in 10 Sprints' time will depend on what's learned in the intervening 9 Sprints in terms of velocity and complexity. Commented Aug 5, 2020 at 2:12
• @ConMan: Fixed releases with variable scope => OK. In the context of the question being asked here though, it's usually common for people to put fixed release dates on a bunch of estimated items and then expect those items to all be delivered at the specified date (i.e. as estimated). Fixed releases with fixed scope => BAD. Commented Aug 6, 2020 at 7:08
• Absolutely agree. It's something like (fixed release date, fixed scope, confidence that you'll actually deliver what you said you'll deliver): pick two. Commented Aug 7, 2020 at 0:05