Agile Requirements
I’ve written long requirements documents. Really long. Coupled with vision documents as well.
They suck up a lot of time, and usually, the argument is that they are needed in order to keep people on track.
Well, recently, I’ve been experimenting with agile requirements writing and let me say this: it’s one heck of a lot easier.
I’ve combined a basic requirements table / roadmap along with product definition to create my own PRD-style document. The TOC looks like this:
- Document Overview
- Problem Statement
- Vision
- Market Segments / Target Market
- User Goals
- Requirements
The overview section is pretty boilerplate. I’ll include information regarding the document as well as any overarching requirements themes that I have in it. For example, within a user-based Web application, one requirements theme coul be “user management.”
Aside from that, the other sections that are included are pretty self-explanatory.
The requirements portion though - that’s the difference.
I have all requirements laid out in tables. One table per version currently planned, and the one table at the end of the document for the backlog of functionality that’s important, but not yet assigned to a release.
The table I’m referring to consists of 6 columns:
- ID
- Name
- Description
- Estimate
- Risk
- Notes
Each of these columns play an important role when they are applicable. I say that “when they are applicable,” because not all of them always are. For example, small internal projects need documented requirements, but doing a risk assessment is probably over the top there.
Each row in this table is a “story” by proper definition. And, as most of us should recognize, stories are (in effect) just a more “modern” version of saying requirement. But to be clear, they are not use cases.
Oh, I should stay away from this - I’m verging on religious discussions. Eek!
Now, there is another person in our company working on defining requirements for the first time. When discussing methods to do this, she had a hard time, and felt very overwhelmed with the death-march style of waterfall project management.
And no, the pros / cons of waterfall did not lend well to this project. A more agile approach was highly applicable.
But, the benefit here was, by following this simple structure, she was able to get a great handle on the project / product she’s working to ship quickly and had a much easier time explaining it to others in this format.
I have the same feelings.
Some so straightforward lends itself quite well when needing to get these types of things in front of developers, project managers, QA folks, and writers - all working on the same product.
I’ll post more about this structure / format in the future. Just wanted to get some thoughts down on it this evening.
