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.
