What strategy to use to rebuild a specification from the existing development stories of an Agile project? Last to first, first to last, another way?

Ahh the lovely Working software over comprehensive documentation rearing its ugly head again. It's over, not instead of. And unfortunately it's too late now. But when a team is about to leave they should have left additional documentation and should have prepared for someone having to take over the system they built.

User stories aren't specifications, unfortunately, but if the team had practiced other agile techniques, like automated testing or specification by example, you'd how have a complete list of specifications in the form of automation, but I suspect the team didn't do that either...

It's unfortunate how many teams embrace the "this will be less work" part of the agile manifesto, but ignore the "this will require a lot of discipline" part.

Now as for an approach. Given that these 600 stories were written over a period of time, and given that User Stories are allowed to add, subtract and contradict each other, you'll need to go through them, either in chronological or reverse chronological order to build your understanding of the current "correct" specification of the system. Personally, I'd go through them from oldest to newest, but both should work.

Expect that newer stories will "override" older stories. That features added in the past, may have been removed later. Etc.

AI can be a great help with this effort. It understands the natural language of the User Stories, it understands the version control history of the product and it can read code to find discrepancies between the User stories, the code and your specification.

And you may also be able to take an agile approach to the specification writing... As new requests, bug reports or other changes come in, rebuild the documentation for the part of the system you need to inspect or change, document as you go along. You'll get a better understanding of the core system choices over time and you'll probably find out you won't need to formally document every part of the system.

Final remark... There will be ambiguities between the delivered User Stories, whatever documentation exists and the code. It will be difficult to pick the "correct" interpretation in that case. People may have had undocumented discussions, formal feedback, informal feedback, made decisions at development or design time due to specific constraints. When finding discrepancies, be careful assuming either the User stories or the implemented product are correct. Ask the users, stakeholders, former developers whenever possible.

The answer by jessehouwing is solid, but I don't fully agree with everything.

This is a good example of teams reading "over" as "instead of". Good practitioners will totally abandon documentation. In fact, there are good agile practices for maintaining system documentation and models. There are right ways to determine what documentation should be maintained and how to maintain it. Understanding what the system does, as a whole, is useful information that should be maintained.

By default, stories aren't specifications. By definition, a specification "provides a definitive description of a system for the purposes of developing or validating the system" (ISO/IEC 2382:2015 Information technology -- Vocabulary), which means that specifications could describe what to build (for developing) or what was built (for validating). Most people don't manage stories with the kind of control needed for a specification. A story represents a point-in-time change in the state of a system.

One of the most agile techniques would be the use of executable specifications. There are other techniques to maintain requirements in other formats, such as use cases. Alistair Cockburn has done extensive work on use cases, including recent efforts to unify use cases, user stories, and story maps.

Ideally, these practices would be used when building the system. However, it's not an option since many things have already been implemented.

Given that you have 600 stories implemented, I wouldn't advise trying to simply read them to get an understanding. Regardless of how you read them, 600 is a lot of items to keep in your head. Trying to organize this information in a way that makes the state clear will take a lot of time. If you read a story that is modified by

Instead, I'd start with the built system and create executable specifications or use cases that describe what the system does. This is essentially backfilling the documentation that you should have been producing from the start, but using the system as the basis rather than stories which may be incomplete, out-of-order, or difficult to consume.

Export all the stories, including their data and dates, and feed them to an LLM. Request the LLM to generate product documentation. Instead of arranging the stories in chronological order (from last to first or first to last), ensure that each story includes its “last action date,” such as the “updated” date. The AI will handle the remaining tasks.