Reports for future planning based on Story points ?

Now, at the end we have a measurement of the story points used in an Epic. Example - An Epic 'Tango'  = 100 story points.

This information then further used to plan the future Epics , like new Epic 'Charlie' should be approximately 80-120 SPs considering what the consumed in Epic 'Tango'.

Why should epics have to be of the same size? Why introduce such a constraint in the first place? Shouldn't epics represent significant and valuable business functionality, of whatever size, and shouldn't teams then estimate the amount of work accordingly?

Why should epics have to be of the same size? Why introduce such a constraint in the first place? Shouldn't epics represent significant and valuable business functionality, of whatever size, and shouldn't teams then estimate the amount of work accordingly?

Actually i found out that old Epics are used as reference for the new Epics just to get an idea on the size for new ones. But i agree how can the size of new Epics are determined from old ones. 

Story Points are estimates based on the information known at the time the estimate is given.  How will the PO know how to estimate Project Z in relation to Project A/B/C?  The Development Team is responsible for providing the estimates based on refinement activities.  I am going to assume that at the time the PO is making these judgement calls there has been no refinement.  This would be similar to a chef saying "it took me 2 hours to make the last batch of 16 cupcakes so it will take me 2 hours to cook a 4 course meal".  Unless that 4 course meal consists of 4 different servings of the same cupcake served to 4 different people there is no way to compare the two. 

In my opinion Story Points are only useful to the Development Team as a means of forecasting how many stories they feel comfortable pulling into a Sprint Backlog. As a future planning tool, they are only a portion of the information needed. Especially since over time the Development Team gets better at estimating based on domain knowledge, learning of the team member's skills and technology used.  So if you try to equate Project A to Project M the entire premise of the the estimates for Project A have changed. 

Hope this helps you with your dilemma.  

I am going to assume that at the time the PO is making these judgement calls there has been no refinement.

Yes exactly !! Which as per me will not help.

In my opinion Story Points are only useful to the Development Team as a means of forecasting how many stories they feel comfortable pulling into a Sprint Backlog. As a future planning tool, they are only a portion of the information needed. Especially since over time the Development Team gets better at estimating based on domain knowledge, learning of the team member's skills and technology used.  So if you try to equate Project A to Project M the entire premise of the the estimates for Project A have changed. 

Thanks Daniel , yeah i think my head is cleared now. I have the same understanding. :-)

Actually, we need this data when we have multiple projects with almost same priority and assumed value. Here we also need the approximate time by which we can finish the project in order to decide which to start first.

Do you have any suggestions for such project planning ? For me it would be better to have the Epics-Stories refined with team and get the estimate and order to decide the approx number of sprints. But i think this will take a bit of time.

Why not ask the Development Team what is their estimation of time required for "project M"? They will have questions, there should be an attempt to answer these, and then they will produce an answer. Will be very rough? Most likely. Will it be better / worse than detailed estimation effort? Hard to tell. They might even actually want to go into details... But why not try to ask them, transparency over company plans should be something to strive for.

They might even actually want to go into details... But why not try to ask them, transparency over company plans should be something to strive for.

Thanks Philip , yeah that's what i thought to have a refinement session with team. But wanted to know if there is any other or better approach than this ? 

But wanted to know if there is any other or better approach than this ? 

There are many other approaches but the only way to know if they are better is to try some because every team at every organization will be different. Even within your own organization different teams might be better at one approach than another. 

You seem to have a pretty good understanding of this concept.  Take some of the suggestions we have offered, add some your practical experience with the teams in question and come up with some suggestions you can offer for them to try.  Try one to get some knowledge, inspect it and adapt as necessary.  As with estimates getting better over time so will your method used for forecasting longer term deliverables improve.

It would be interesting to learn from you experiences.  Please come back and update this with your adventures.  It will help anyone faced with this dilemma.  The more information we all share the better we all become. 

Thanks Daniel for your inputs. Yes, i will definitely share the outcomes from my experience. :-)