I like to think of requirements as being perishable. They have a certain shelf life before they are developed and then they start to smell funny and eventually go bad as they get out of date. Different sorts of requirements have different shelf-lives.
Master Level Story
The high level stories written at the beginning of a project and turned into a master story list can either have a long shelf life or a short one. If the requirements are not beginning to be broken down and worked on within a week or two, they get stale. Longer than a few weeks, into a few months or more, they should probably be thrown out and at the very least reevaluated. Why? Because your business may have changed in that time. It may not make sense to build those features that made sense a month or two ago.
Release Level Story
Release level stories are good for planning and immediately getting started on detailed analysis and development. They have a short shelf life based on their master level story freshness, plus any ongoing work in an application. For instance, if some implementation was decided on in a release level story and some technology change has made a card obsolete because it is building the wrong thing or makes the wrong assumptions, it’s useless.
Iteration Level Story
An iteration level story only has a shelf life of a few days after it’s been analyzed and not developed. More than a week or so and things can change so drastically in a project that they are not accurate anymore.
Shelf-Life After Development
After development, stories have a much longer shelf life. They can be referenced through various parts in the development lifecycle with the exception of stories that have been overwritten by new ones and those should be tracked as they occur.
Domain documents like systems architecture design, major domain concepts in your app, etc. are useful even longer.
Keep in mind that all of these levels of stories interact. Master > Release > Iteration. They flow in that order and if the master level stories are old and no longer good, they need to be reevaluated. Otherwise, spending time to break them down will be a waste of time and even worse, implementing them can cost real money in the marketplace.
Constant prioritizing and re-evaluation will keep stories fresh for use by the development team. Don’t expect to be able to pull bad apples from storage and make some great apple pie.