I realize the size of a product backlog will vary with each project. But assuming a project that is large enough to require a significant length time, is there any research or statistics on diminishing returns in terms of refining stories and epics?
In Zsolt's answer: https://pm.stackexchange.com/a/6715/2730 It mentioned that the last 2/3 of the backlog is going to change in the future.
This seems to be inline with the idea of Agile and Scrum. I'm wondering if there's a point where it is better to consolidate those stories into just epics, until such time as they may be in near future sprints.
What is a good size for a backlog, relative to the teams velocity?
Does it make sense to consolidate existing stories into epics, if they aren't to be worked on for a significant period of time? (Assuming that the epic will hold the same knowledge of the original stories)
This question stems from our specific case. We have nearly 400 stories, and complete an average of 5 per sprint, in 2 week sprints. This is mostly because the initial push into scrum was to get every possible story into the backlog, rather than to form epics and divide as true needs were discovered through iteration.
It obviously affects our ability to manage the upcoming stories, creating duplicates, wading through hundreds of possibly irrelevant or just wrong stories in the process. We are unable to update stories as new knowledge is gained, causing us to spend more time second guessing meaning and purpose of stories rather than iterating.
We do suffer from a lack of prioritization. However, I'm thinking the sheer number of stories is causing our product owner and stakeholders to not want to invest the time into prioritizing. It feels very chicken and egg.
I'm hoping to find some information I can use to suggest consolidating large numbers of stories into epics, to be broken down later, when the actual need for the epics is in the near future (4-8 sprints).