Agile Business Analysis: Requirements Activities

In Part 1 of “Agile Business Analysis in Flow,” I talked about the new skills and attitudes business analysts need to bring to agile development. When your organization adopts this value-centered approach, you need to have, as I wrote, “a tolerance for ambiguity along with a concurrent drive for specificity and closure.”

Now it’s time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let’s take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.

Setting the stage: Requirements planning activities

To set the stage for requirements, the team strives to create a shared understanding of the product by all the stakeholders.

Traditional Analysis Agile Analysis Adaptation
Attend project chartering sessions to define a vision, glossary, requirements risks, and product stakeholders.
  • Design, facilitate, or participate in product vision and roadmapping workshops.
  • Help your customer understand which roles and themes to best deliver in each product release.
  • Help your customer and team identify logical groupings of value-based requirements, and use these groupings to create a product roadmap showing incrementally delivered requirements over time. These requirements often take the form of minimally marketable features, stories, or epics (i.e., large stories that cross releases), use cases (high level only), events, or a combination.
Review and modify a list of tasks, time, and delivery dates in a work breakdown structure plan developed by the project manager.
  • Design and facilitate (or participate in) release and iteration planning workshops.
  • Regularly prune the product backlog by collaborating with team members to generate a relative size estimate for backlog items.
  • Conduct analysis “spikes” (short, timeboxed research stories) to elaborate on backlog items that need more analysis, researching requirements and their priorities.
Generate a SWAG (“S#*&-Wild-Ass-Guess”) estimate of time, effort, or cost for each requirement in the specification or user requirements document.
  • During iteration planning, together with the rest of the team, write down the needed tasks to deliver each user story, and estimate how many hours they will take.
  • Share actual time usage information with your team so that the team can track progress via visual graphs (“information radars”) such as burndown, burn up, or cumulative flow diagrams.

Requirements elicitation activities

During requirements elicitation, the team identifies the sources of requirements and then discovers, derives, evokes, and elicits requirements from those sources.

Traditional Analysis Agile Analysis Adaptation
Plan how to elicit requirements using a variety of techniques.
  • Use face-to-face, collaborative elicitation techniques (workshops, prototypes) as much as possible while avoiding techniques (interviews, surveys, documentation study) that require longer lapse times or interpretation.
Plan, design, and facilitate requirements workshops over weeks (or months).
  • Plan and facilitate short, informal requirements modeling sessions throughout each iteration.
  • Plan and facilitate product vision and roadmapping workshops and release planning workshops.
  • Teach your customer about supplemental analysis models so that they can question, participate, critique, review, and approve them (this should be done in traditional projects as well).
  • Sketch out prototypes and identify user acceptance test data in real time, while a story is being designed, coded, and prepared for testing.