How do you go about generating the requirements on your agile project?
Does your Business Analyst go around interviewing each of the business stakeholders? Do you hold one or more workshops where stories are written in a group? If you have more than one workshop, how do you then de-duplicate stories? Or do you not do that at all? And when you have, how do you know that you haven’t missed something important?
It is important that, during the process of requirements elicitation, you capture stories at a high-level that describe the full breadth of the project (or product) scope. It is perfectly reasonable to expect detailed stories to emerge during the project, but they should not be new requirements, they should not add to the scope. Any newly-written stories should arise from breaking down large stories captured during Feasibility or Foundations stages. Ones that describe a new business need not already covered by existing Feature or Epic stories should be very rare, because new business needs will impact on your ability to deliver on time as you have not planned for the work involved in meeting them. So how do we ensure that we capture the breadth of the scope early on?
The answer is two-fold:
· Define the Vision and critical success factors of the project
· Requirements Modelling
Having an overriding vision – an objective – for a project can help focus the team on what is important and help clarify many lower-level priority decisions later.
Modelling is one of the key agile practices in DSDM Atern. DSDM does not dictate any specific modelling techniques, and I am not going to, either. However, what I am strongly advising is that you do some up-front modelling in order to build some context from which to create your user stories. Scott Ambler has written about the need for this and spoken about it at least once that I know of. The larger the project, the more the need for modelling, for envisioning, for high-level design. This is not Big Design Up Front (BDUF). This is Enough Design Up Front. Being Agile does not mean being infinitely flexible. It means delivering a solution that demonstrably meets the business need quickly and with the requisite level of quality. In fact, quality is usually more important than speed.
Your requirements models can be anything from a simple context diagram, through customer journey maps, process flows, use case diagrams, domain models…. the list goes on. As a rule of thumb, start with the high-level and then drill down into successively lower levels of detail as and when you need it.
From this context, you can then write user stories that define the features modelled.