The who, what, when, why, and how of agile requirements elicitation
Gerald D. Smith, MBA, CSP, PMP
Director, Technical Project Manager, Epsilon
According to Snowden (2013), agile, in the strictest sense, has three roles: the product owner (PO), the ScrumMaster, and the delivery team. In this scenario, there isn't a role for the business analyst. Since requirements are needed for a software development project, the more appropriate role for eliciting those requirements belongs to the business analyst. According to the U.S. Bureau of Labor Statistics, Employment Protections Program and BA Times (2015), jobs for the business analyst will grow to over 876,000 by the year 2020. Experience in agile frameworks is a must since companies are moving full-steam ahead with agile adoption (State of Agile, 2015). In a disciplined iterative project delivery (DiPD™) framework, used in companies that are transforming from a traditional project delivery framework to a leaner, project delivery framework, the ScrumMaster is replaced with the agile project manager (APM), and the role of requirements elicitor is the business analyst (Smith, 2014). Using the DiPD™ framework, all of the requirements are not elicited at once; the business analyst role needs to be transformed to a new role with enhanced responsibilities.
The AA, or agile analyst, owns or shares responsibility for eliciting the epics and user-stories using user-story driven techniques (Smith, 2014). Epics are large user stories that can be broken down into a number of smaller user stories (Cohn, 2006). Epics define the services that the system must provide to solve the customer's problem. 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, of the system. They typically follow a simple template: As a <type of user>, I want to <some goal> so I can <some reason> (Cohn, 2006).
When commencing requirements elicitation, the AA needs to ask: “What does the agile team need to accomplish?” and “Which things am I best able to do?” The AA is the liaison between the PO and the project team. Cottmeyer and Henson (2006) state “the benefits of agile project management are derived in part by placing a tremendous amount of responsibility and accountability on the individual team members” (p. 2). There is an understanding that great teams build great software, and those teams should be trusted and empowered to deliver. A good AA can be an enabler, or servant, of the team. The AA guides the project team to stay focused on solving the larger business needs and assists in the removal of confusion as they relate to their understanding of the requirements so they can deliver value. The focus is on the project team because ultimately they are on the hook for software delivery. This philosophy carries over into the [enhanced] role of the AA and how requirements are collected, distilled, and managed (Cottmeyer & Henson, 2006). The AA leads the iteration planning activities, which does more than just lay out what needs to be accomplished; it sets the tone for the work that is necessary to complete the iteration, release, and project; and it provides an opportunity for the AA and project team to lay out the expectations, identify risks and issues, identify needed resources, and develop a vision (Smith, 2014). In short, the AA is responsible for facilitating the planning sessions with the project team and (shared) service areas. In the absence of a PO, AAs serves as a “proxy user” who works directly with real users and can communicate the wishes of the one-to-many customers (Williams, 2004). AAs can also help translate user needs into more technical language for the agile software developers and testers (Cottmeyer & Henson, 2006).
The AA needs to think about the software development process in new ways. Agile encourages teams to decouple the breadth of the solution from the depth of the solution in order to continuously deliver smaller increments of production-ready code. This can present a challenge for some AAs in making the transition to agile and will create opportunities to learn more about how to write user-story driven requirements. The AA is responsible for building and maintaining the product backlog. The product backlog in agile is a prioritized features list, containing short descriptions, and acceptance criteria, of all the functionality desired in the software product known at that time. Typically, the AA and PO begin by writing down everything they can think of as candidates for prioritization. The epics and user-stories must be enough for the PO to create a scope for the first three iterations of the release and for the project team to evaluate, provide estimates for, and create tasks so they can commence development and testing. The product backlog is then allowed to grow and change dynamically, as more is learned about the product and its usage by the customers (Cohn, 2006) is collected. In other words, it is a living document.
The product backlog process is a process the AA, PO, and project team uses to plan iterations, releases, and projects. It includes the epics and user-stories that are within the scope of the project. New epics and user-stories may be identified as business priorities change over the course of the project or release. When an epic or user-story is added to the product backlog, one of three outcomes is possible: it is approved, deferred, or deemed not necessary (won't fix).
When a new epic is added to the product backlog, the AA works with the PO to identify the user stories and prioritizes them. Once prioritized, the AA collaborates with the project team and answers any questions they may have so they can create tasks and size those tasks. When an epic is prioritized, one of three outcomes is possible, it can be deemed added, deferred, or deemed not necessary (won't fix) (see Exhibit 1). The AA has a weekly standing meeting with the PO to review new epics and approve or defer epics. The weekly meetings also ensure regular communication so reviews of the product backlog are performed, expectations are managed, and transparency is at hand.
Exhibit 1. Prioritization process overview.
If the PO decides to include the epic within the scope of the current release, AA works with the APM to determine which iteration the epic and subsequent user stories can be assigned. The AA will also work with the PO to defer previously planned epics to a future project or release.
Remember, the AA is, at a minimum, three iterations ahead and at maximum, one release ahead of the project team. In some cases, additional time may be needed when working with outside vendors or integrating with external team resources that are not using the disciplined iterative project delivery framework. Once the release is complete, the AA, having accumulated all the approved user stories over the duration of the release, presents to the PO and project team the total actual user stories delivered divided by the planned user stories. If the percentage is between 90–100%, the project team receives a Green status; if the percentage is between 80–89%, the project team receives an Amber status; and if the percentage is less than 79%, the project team receives a Red status. This is the product owner acceptance metric, which is useful in obtaining PO sign off and delivery of business requirements, albeit in user-story form.
Why does software engineering need requirements, or, for that matter, requirements engineering? 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. “Agile practices are based on the belief that neither the customer nor the developers have full knowledge in the beginning and that the important consideration is having practices that will allow for both [the customer and the developer] to learn and evolve as that knowledge is gained…without ongoing recrimination” (Highsmith, 2000, p. 1).
Agile Requirements Elicitation, or ARE™, is an agile requirements elicitation method that expresses requirements as high-level, brief written statements of the best information fairly easily available (Williams, 2004). As depicted in Exhibit 2, ARE™ provides the AA the roadmap to identify, prioritize, and decompose epics to user stories, while empowering the APM and project team to self-assign, work on, and deliver tasks traced back to the user stories (aka requirements).
Exhibit 2. ARE™ process overview.
In summary, the AA enhanced responsibilities provide the Who, What, When, Why, and How of ARE™. As companies transition to an agile project delivery framework, the need for an AA will only grow.
BA Times. (2015). Retrieved from http://www.rgfgroup.com/currently-at-rgf/2015/8/3/american-employers-will-need-876000-business-analysis-relate.html
U.S. Bureau of Labor Statistics (2015). Retrieved from http://www.iiba.org/Careers/Business-Analyst-Career-Road-Map.aspx
Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Prentice Hall Publishing.
Cottmeyer, M., Henson, V. L. (2006). The agile business analyst. Whitepaper,VersionOne.
Highsmith, J. (2000). Adaptive software development. New York, NY: Dorset House Publishing.
Smith, G. D. (2014). Agility…iteratively™. A practitioner's guide for agile transformations for realistic & disciplined agile project management, 1st Ed. MJS Publishing.
Snowden, Rob (2013). The business analyst role in agile products and how to do it. ASPE-SDLC Training Division.
State of Agile Survey. (2015). 9th edition. Retrieved from http://www.versionone.com/pdf/state-of-agile-development-survey-ninth.pdf.
Williams, L. (2004). Agile requirements elicitation. Retrieved from agile.csc.ncsu.edu/SEMaterials/AgileRE.pdf.
© 2015, Gerald D. Smith, MBA, PMP, CSP
Originally published as a part of the 2015 PMI Global Congress Proceedings – Orlando, Florida, USA