We’ve all heard the statement, “Agile doesn’t need requirements;” well, that is not true in the health care, insurance, financial and other industries. At the heart of software development are the requirements; if there are no requirements, how are the developers creating the new product? When is Done, Done! Typically, a business analyst (BA) elicits the business and non-functional requirements. According to the International Institute of Business Analysis, a “business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.” According to the Bureau of Labor Statistics, 876,000 business analysis related professionals will be needed by 2020. This is seen as a vital role and based on current trends, is not going anywhere. With the growth in agile project and software development methods, the role of the BA is more important than ever. However, how the BA fits in the agile framework is still a mystery? Agile Requirements Elicitation (ARE™) is a framework that identifies the Who, What, When, Why, and How of requirements elicitation.
The Who is the agile business analyst, or agile analyst (AA). The AA owns, or shares, responsibility for user story driven development, whole team approach, team change management, sprint risks/issues, and sprint communication. Changing the title from BA to AA introduces the opportunity for learning a new way to perform a new task. The AA is not focused on BUFR (big upfront requirements), but rather is focused on talking about the requirements and not writing the requirements.
The What is creating the user stories. User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer. They typically follow a simple template:
‘As a <type of user>, I want to <some goal> so I can <some reason>.’
Within the description of the user story, the AA may choose to write bullet points describing functionality or may include process flows if the functionality is complicated or requires validation. According to Cohn (2011), user stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
The When is typically before Sprint 0. This is when the AA is continuously working with the Product Owner (PO) to identify the new requirements and creating the basic skeleton and plumbing for the project so that future sprints can truly add incremental value in an efficient way. It may involve some research spikes. The AA is also grooming the backlog, adding, removing, or revising requirements based on the additional knowledge obtained from the PO; the PO’s wants becoming clearer. In ARE™ this work can also be performed in sprint -2 or sprint -1. These are sprints that occur while the development and test teams are working on the current sprint and as we know, changing the scope of the current sprint is not recommended.
The AA is responsible for leading the project team and service areas through release planning session activities up to the 1st release only to keep the team focused, which will be broken down into one – to – many sprints.
The Where is the Product Backlog. According to Cohn (2004), the agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers. According to Prakash (2013) theproduct backlog is a living document. Stories are added, modified, and split into small ones all the time. The backlog can be created during project initiation. From then it grows and is refined as needed. There should be a few stories in the product backlog at the time of Sprint Zero’s start, enough to help the project team demo at least one working feature.
The Why is requirements engineering. According to Sommerville (2004), requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements engineering and its deliverable, requirements, are inevitable and serve a triple function (1), may be the basis for a bid for a contract – therefore must be open to interpretation; (2), may be the basis for the contract itself – therefore must be defined in detail; and (3), both these statements may be called requirements. So for contract work, requirements are needed to prove that you, the contractor, have delivered the necessary functionality to your customer and/or PO.
The How is ARE™. ARE™ is an agile process that is specifically geared to eliciting requirements for disciplined iterative project delivery (DiPD™).
A feature is requested by the PO and the AA records the request as a user story and classifies it as an enhancement or an epic. The AA, or agile project management (APM), can then prioritize the new item qualitatively (high, medium, and low). The AA adds the requested enhancement or epic to the product backlog and continues to work with the PO to groom the product backlog. As part of the grooming activity, the new enhancement or epic is either deemed not needed, which means it won’t fix a defect, deferred, which means it is moved to a lower priority in the backlog, or needed and is then updated. The AA continues to work with the PO to refine the enhancement or epic while the AA creates user stories for the higher priority enhancements or an epics. Once the user stories are created, the AA presents them to the APM and project scrum team (which consists of the development, test, design team members) to obtain their feedback. If wireframes are needed, the AA begins to create them; then the PO approves them.
In the prioritized stage, new enhancements or epics are discussed amongst the PO, APM,development, test, and design team members for better understanding and are categorized in the product backlog as ‘Won’t Fix’, ‘Deferred’, or Needed and then given a priority (Must Have, Should Have, Nice To Have). An estimate is given by the Whole TeamSM using planning poker, or some other estimation activity. The estimate is added to the enhancement or epic, or is deemed unestimatable. Once approved, the estimate is added to the upcoming release/sprint scope by the APM.
In sprint 0, the AA works with the APM, to coordinate sprint planning. This is typically 2 weeks, but can be more. The AA creates a release or sprint requirements package, which is the product backlog that contains a list of the user stories planned for the release and/or sprint approved by the PO. The user stories are reviewed and discussed with the Whole TeamSM and decomposed into tasks, sized, estimated, and owned by the Whole TeamSM. A sprint duration can last between 1 – 4 weeks; but at the end of the sprint, a demo is presented to the PO and if approved, the project scrum team moves the working code to the transition and/or hardening sprint(s) that is the predecessor to deployment.
As you can see, the AA’s role is more collaborative and as more important in agile software development and agile project management as it is in the traditional software development world. Requirements are needed and can be used in agile; the format is not a word document, they are just-in-time requirements. The requirements are features (either enhancements or epics) and can be tracked using Microsoft Excel or an enterprise agile software tool. Now you know the Who, What, When, Why, and How of agile requirements; what are your thoughts?