An issue has come up lately as we break down stories.. The scenario is as follows: During product increment planning we outline X amount of stories for the PI. This is recorded in Jira with story points associated to each story. As we go into sprint planning we often find the the original stories may be to broad, or may not not fill a business requirement.

So two question:

Granted its a tooling problem, but is it the norm to link the new stories back to the original? If the original story had say 20 story points and the sub story has 10, would you reduce 10 from the original story to avoid double counting?

2 Answers 2


By deciding that you need to break out stories from the original, you'd gained a better understanding of the story and you should no longer assume your estimate of the first story was accurate. In the specific case you give, I would re-estimate the original story now that you've broken it apart.

To take this a step further, it's important to know that what you did is very natural and the rest of the team will probably think the same. To get around this, often times instead of breaking out effort from a story, we break up the story into new stories. Then, you ask the product owner if the set of new stories will deliver what they were looking for in the original story. This allows the team to have good conversations about the effort and story points for each story without holding a bias toward their previous assumptions.

The original story may be deleted or kept around for reference depending on what works best for you, but would never be worked. (it would be treated like any other epic)


If you are on a Scrum team, there is only one type of story...which is an actionable, value-delivering story. There should not be a hierarchy that involves story points.

You may have an epic or feature or some other form of higher level, less defined concept, that links stories, but these generally will not be estimated using story points.

So is it the norm to link stories back to the original...I'd say no. Since the original story sounds like it is not actionable it should be re-written or split up into real user stories that follow INVEST principles. Once the original story is split, remove the original SP estimates and only have the team estimate the actionable stories. Convert the original into an Epic if need be.

You may still retain the higher level entity for other purposes like portfolio planning/roadmapping, or if your customer is referencing the higher level entity as one of their business requirements. I hate saying these things as they move away from basic Scrum, but many organizations used mixed scrum/waterfall practices at the program/portfolio level to fill their medium and long-term planning needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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