Reports for future planning based on Story points ?

Last post 09:38 am July 15, 2019
by Harshal Rathee
8 replies
Author
Messages
10:59 am July 3, 2019

I have some doubts on below - 

So, we have a structure for our PBIs - Feature->Epic->Stories 

Currently my PO is maintaining a report where all story points linked to all stories are realized into a chart/graph.

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'.

Now , i had a discussion with my PO on how these reports are helping in planning. How & why the SPs under Epics are compared together even if they are part of the same Feature?

Is it necessary that the first epic was really 100 SPs at the end ? Will the new epic will take similar efforts or lesser knowing more is known? will the team skills and technical expertise increase or decrease in upcoming sprints which might effect ? 

The only real value for me under the epic is amount of the sub features delivered. Rest SPs is non real value and highly volatile and building a report based on this non real value will lead to the non real outcome. 

What do you think about this ? Does anyone see the benefit here ? May be i am missing the real outcome/benefit on this.

How does the future planning works in your organization ? Will be helpful to get some insights ;)

My PO had this question - How is she supposed to answer the question from management that how many Sprints it will take to finish an Epic. 

My answer was to refine the stories under an epic and get the approx points ( which might change again) and take the avg velocity and find out the count of Sprints.

 

02:36 pm July 3, 2019

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?

03:22 pm July 3, 2019

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. 

05:16 pm July 3, 2019

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.  

07:26 am July 4, 2019

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.

 

 

08:58 am July 4, 2019

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.

02:16 pm July 4, 2019

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 ? 

05:05 pm July 5, 2019

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. 

09:38 am July 15, 2019

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