Agile requirements analysis

We have a Lean Startup and agile approach to discovery and requirement analysis that focuses on delivering a minimum viable product (MVP) first, then seeking user feedback and iterating when justified by demand. We seek to constantly prioritize and reprioritize so we are always working on the most important, mission-critical features and user stories at any given time.  We understand the three basic premises of agile:

  1. We rarely have all the details of all the requirements in the beginning of a project
  2. Whatever requirements we gather up front are likely to change and evolve over time
  3. We will never have enough time or money to do everything we want

Therefore, by focusing only on the most important, high-priority tasks at hand, we will assure ourselves that when time and money eventually runs out, we will have developed, tested, and released the most important, value-added features at any given time.

As part of our discovery process, we seek to answer the following questions:

  • Who is the intended audience of the enhancement?
  • What is the intended outcome of the enhancement request?
  • What metrics should be used to benchmark success for the enhancement?
  • What metrics inform the features we should consider developing?
  • What features or changes should be developed to improve the benchmarks identified?

At the beginning of the project and each major enhancement, we would perform a project kick-off or Scrum planning session to produce an Inception Deck, intended to align all stakeholders. The elements covered in the inception deck would be our guide throughout the project and include topics such as:

  • Why are we here? What is the raison d’ê·tre? What is driving this effort?
  • What are we not going to do? What is outside of the scope of this project?
  • Who are our neighbors? What systems will we need to integrate?
  • What does the solution look like? What other systems have similar features?
  • What are the biggest most frequent problems that are causing us problems?
  • How big is this thing? How many people affected by it? How much work?

This inception deck will help us prioritize epics and user stories down the road as we decide what goes into an MVP; what is absolutely required versus nice to have. As requirements evolve, there needs to be regular and periodic updates and enhancements.

To ensure that we build functionality for the intended target audience, we perform user research to maximize the user experience, promote usability, and ensure that the website produces the desired result. Some of our common methods include:

  • Stakeholder interviews – build consensus about the problems and issues
  • Journey mapping – visualization of interactions shaping a user’s experience
  • Personas – User profile that seeks to generalize behavior, goals, and challenges
  • Storyboarding – visual sequence of a specific use case coupled with a narrative
  • Task flow analysis – process model of a user striving to accomplish a task
  • User scenarios – conceptual story about a user’s interaction (what, how, why)
  • Wire framing – simple visualization of a user interface or user experience
  • Card sorting – categorization exercise to divide concepts into different groups

We choose the right method for the challenge. Because we work in an agile manner, we will revisit these methods iteratively throughout the project.

User stories are written from the user’s perspective, which helps developers practice empathy and build for the target audience. Good user stories also have a definition of done (DoD) to enable us to test against the acceptance criteria prior to user acceptance testing (UAT). A typical user story format would be, As a [type of user] I want to [do something] so that I can [get something of value]. When we focus on the user, we develop more valuable, intuitive, meaningful, and value-added user experiences.