There’s a common misconception about the term ‘requirements’ especially when applied to Agile projects.
Many believe that User Stories are all you need to describe what the user wants the system to do.
“As a Contact Centre Manager, I want the ability to view my agent’s stats and listen to their calls so that I can manage their performance.”
The above User Story is too high level, and can probably be split into at least 3 individual stories, with more granularity within the Acceptance Criteria, along with technical solution notes to describe the tasks required to implement it.
User Stories alone is not enough to describe requirements in its totality.
They’d be like pieces of a quilt, all scattered in a big heap.
You need threads to stitch them together, to tell a story.
This textual narrative will need to reside in a living team workspace and knowledge repository, such as Atlassian’s Confluence.
You also need process diagrams to describe the requirements, and to illustrate the relationship between actions, actors, and systems for the various functionalities.
These are living documents, which are superior than waterfall tomes of requirement/design documents which are cluncky (but complete), and rapidly goes out of date once sign-off is done, and change requests start flowing in.
Regardless of method of documentation, it is important to understand why you’re doing it, and invest in doing it properly, and maintaining its accuracy as time goes by.
Otherwise, it’s like an appendix – the residue of an evolutionary requirement that doesn’t really have purpose anymore.
Don’t let documentation be an appendix (the biological kind).
#projectmanagement
#salesforce
#consultinglife
#requirementsgathering
#userstories