All projects and clients are different but from my own experiences of agile development, where requirements and priorities change very often, I’ve come to like the following simple approach the best.

This is not a substitute for the agile development method used in larger and planned projects.

This is an example from the recruitment system. This was written in 2016, and things might have changed since then:
https://docs.google.com/a/lbit.in/document/d/1rFTvz3afOW66aVj1-lAhda7he5diVYKP–3z7Ur4y9c/edit

A specifications document is set up using Google docs. I use three separate sections: 1) High prio/include in work plan 2) Low prio/exclude from prio 3) Completed.

Whenever I get a new idea for a feature, I usually add it to low prio section. If it’s a very low prio feature I add it at the bottom and if it’s more high prio and likely to be included in the next mini-sprint I add it towards the top.

If I feel the need to make a change to a requirement or clarify it a bit, I will add sentences directly into the specification. This works well with Google docs as everyone has the same version of the document and can see changes in real-time.

I won’t have to send a message about it, that the developers need to add themselves to the specification, saving time and ensuring that all parties (including testers) have the same information.

It’s very easy for stakeholders to find exactly what text was changed thanks to the revision history tool.

The developer will mark the feature green once completed (or part of the feature). The developer will move it to the bottom section once the feature is fully complete.

It’s very easy for the client, TL or tester to find and they can approve it by just deleting the green text (there’s a revision history if we need to recover it later).

Non-urgent bugs and small fixes are grouped into one requirement per week to keep work plan and time overviews neat.

What to include in the work plan: Depending on how much changes – how agile the project is – how active the client is; include only XX hours of work in the top section at any time. I keep it around 40 hours if I’m actively involved, but you can of course include 300 hours as well for a passive client.

A quite short mini-sprint with other words. My aim is to not remove/re-prioritize those 40 hours; they are assigned and should be kept assigned to let the developers focus. It requires the client to be a bit restrained about changing the priority order too often.

That being said, a priority change can easily be handled by remarking the priority numbers in the work plan and following it up with a Basecamp message.

Keep all requirements ordered by priority. This way the developers can start analyzing the lower priority features too, and include the top ones in the work plan.

Benefits:

• Everything is kept in one place and one document version.
• It’s a super simple method that all parties including clients can quickly understand and start using.
• It’s easy for a tester to get involved: he can test whatever is marked green and the specification of the feature is the most recent one.
• Instead of requesting changes through messages we add it directly to the document.
• Developers can start thinking about the next requirements before they are assigned.
• All parties – client, developers, team leaders, testers and I – can scrutinize the document easily: is it clear? are we prioritizing High Impact Low Effort tasks and the core process?

A drawback is that time sheet overviews won’t be as clear as for projects where more planning is done in advance.