An Approach to Requirements Elaboration in an Agile Environment
Requirements gathering is the cornerstone to the success of any Agile project. There is no denying the fact that stakeholders often struggle in providing the functions and features that they expect from a system but rather provide the details and system behaviour. The key to achieving clarity is progressive elaboration. Interviews and workshops with stakeholders conducted by the business analyst can achieve this progressive elaboration.
Agile projects often use user stories, which act as the starting point for further refinement in terms of requirements elaboration, design, risks, and costs. User stories are usually captured using informal techniques and as such are not available to all the team members until it is segregated and scaled to fit in traceable stories. The use of informal techniques suggests the need for an elicitation process and a supporting tool that helps to share the artefacts as and when they are created, reviewed and approved.
Most organizations would need to invest in tools to support the Agile way of working. To be effective, the tools should be used to create a virtual platform to connect teams to each other. They can then use the tools to share information, keep it up-to-date, track and review information packets, and to keep the momentum of the project without losing focus and pace of deliverables. Utilizing this tool leads to real-time sharing of information and better transparency and visibility of workloads and ultimately, of the schedule.
If teams adopt the above-mentioned way of working then a few potential issues get addressed early in the project lifecycle. These include issues like blocked information flow, use of old and redundant information, the blurred view of work items, and low traceability. Addressing these issues mitigates a lot of problems with which a business analyst (and other team members) may struggle. However, to address this completely from the business requirements point of view, the base has to be laid out properly and completely. This need puts requirements elicitation and elaboration in the spotlight.
As mentioned, requirements elicitation often starts in the form of user stories. At this level, it is comparable to an outline of the expectations from the system in terms of functions and features. Once the outline of expectations is created and agreed with stakeholders, the focus should quickly move to the elaboration activity. The extent to which detailing is required varies depending on the team’s needs, however, this elaboration activity must achieve complete and correct documentation of business requirements, design, its rationale, and traceability (since if a task does not trace back to a user story, then it is not required).
However, the requirements elaboration activity is easier said than done. Depending on the stakeholders involved, different tools and techniques may have to be applied. Unlike in a traditional project where the requirements elaboration phase consists of detailed analysis and complete specification document, in Agile, this is done differently. The requirements elaboration phase of an Agile project focuses on identifying the user stories first, then detailing them as the project moves ahead. Essentially, the elaboration activity initially concentrates on high priority features and then progressively incorporates details. Storyboards and prototypes are powerful ways to gather feedback and quickly incorporate it. Allowing users to see details early on reduces rework costs since integration with other systems has not yet been done.
Since further iterations of elaboration build on user stories, the business analyst should ensure that certain key information points are captured upfront while creating the user story, avoiding the need to re-visit these stories later. Key information includes actors, pre-conditions, triggers, benefit, acceptance criteria and if possible, non-functional requirements. Ensuring the capture of these data points early in the phase helps build the understanding of the requirements and avoids the pitfalls that transform simple oversights into multiple issues at a later point in time. This data capture also allows the business analyst to start documenting the requirements using formal techniques and begin creating a document for review, sign-off and trace.
Another buzzword that comes up is “collaboration”. To understand this, think of scenarios where the business owner will probably provide his expectations on the system behaviour but leave the system design considerations to the technical teams. Collaboration is the essential thread connecting these teams. Any one team working in a silo is a recipe for disaster; we need open communication channels leading to high levels of trust. The need for collaboration needs to be factored in by the business analyst. Note that requirements documentation may take any form – spreadsheets, documents, presentations, diagrams, use cases. The driving force here is not the format, but the content (what), context (when, where), and collaboration amongst different teams say, IT & Business Analyst and Business Analyst & Development team.
It may also help to elicit, elaborate, and segregate the “must have” requirements from “good to have” requirements early on. This information can be used for prioritizing in sprints considering business user needs and value, and from change management point of view. Readily available information translates to quicker turnaround times for next actions or decisions.
Being Agile during the requirements process allows projects to develop more efficiently by having work tracks running in parallel rather than waiting for fully developed requirements that may have little interaction with business and little opportunities for mid-course corrections. There are heaps of benefits compared to the traditional Waterfall way of requirement elicitation and elaboration. This definitely marks a big change in the way solutions are designed and delivered in shorter time frames by various organizations.