When working on requirements, how is your time split between communicating and documenting?
It’s very easy to feel the pressure to get requirements documented so that they can move through the development pipeline, so that designers and developers can start to design and build some working software, to build the next feature.
On agile projects there is potential for some competing forces to arise here. The agile manifesto states:
- Working software over comprehensive documentation
Being an agile project, there is a desire to be fleet of foot, to move quickly, to iterate rapidly. This generates a sense of urgency to produce a minimal set of documentation so that the “working software” can be built.
However, there is a risk that this pressure compromises what is necessary to produce high quality requirements. After all, countless studies have shown that there is a massive correlation between the quality of the “working software” and the quality of the requirements.
At this point it is worth remembering that documentation is not the end in itself but rather a means to an end. Although documentation appears to be a deliverable, it is the quality of the requirements that are ultimately judged. It’s the conversations with stakeholders and the development team that provide the insights upon which the documentation is written. It is the shared understanding gained through conversations that lead to quality requirements.
So when working on requirements, a useful question to ask is, rather than focusing my attention right now on completing documentation, would my time be better spent having further conversations?
There is a time for exploration and there is a time for explanation.