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, 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 business analyst. The BA owns, or shares, responsibility for user story driven development, whole team approach, team change management, sprint risks/issues, and sprint communication.
The What is creating the user stories. User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. 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 business analyst 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 BA is continuously working with the Product Owner 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 BA is also grooming the backlog, adding, removing, or revising requirements based on the additional knowledge obtained from the product owner, his/her 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 Business Analyst 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 or iterations.
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) the product 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 dual 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 proof that you have delivered the necessary functionality to your customer and/or product owner.
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 product owner and the BA creates an enhancement or an epic. The BA, or PM, or Scum Master, can then prioritize the new item qualitatively (high, medium, low). The BA adds the requested enhancement of an epic to the backlog and works with the product owner to groom the backlog. As part of the grooming activity, the new enhancement or epic is either deemed not fixed, which means it won’t fix a defect, deferred, which means moved to a lower priority in the backlog, or needed and is then updated. The BA works with the product owner to refine the enhancement or an epic while the BA create stories for the enhancement or an epic. Once the user stories are created, the BA presents them to the project manager, Scrum Master, and Dev/Test/Design team leads to obtain their feedback. If wireframes are needed, the BA begins to create them; the product owner approves them; and the user stories transition to the manage sprint stage.
In sprint 0, the BA works with the PM, or Scrum Master, to coordinate sprint planning. This is typically 2 weeks, but can be more. The BA creates a release or sprint requirements package, which is the product backlog which contains a list of the user stories planned for the release and/or sprint approved by the product owner. 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 product owner and if approved, the team moves the working code to the transition and/or hardening sprint(s) that is the predecessor to deployment.
In the prioritized stage, new enhancements or epics are discussed amongst the product owner, project manager, Scrum Master, and Dev/QA/Design team leads for better understanding and are categorized in the product backlog as ‘Won’t Fix’, ‘Deferred’, or needed and then given a priority. An estimate is given by the Whole TeamSM using planning poker, or some other estimation game. 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 project manager, Scrum Master, and business analyst.
As you can see, the BA’s role is more collaborative and as important in agile software development and agile project management as it is in the traditional software development word. 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?
Look to this blog for more agile topics, tips, and ideas. Gsmithcsp.wordpress.com.