Why have we forgotten about requirements analysis in our agile world?

As I coach teams, inevitably the discussion about requirements comes up. Some of the things I've heard from team members:

• We don't write any requirements
• A user story is all we need for requirements
• We don't have time to write requirements, we just talk with our Product Owner
• Since we don't write requirements, we just figure out the features on our own and show the completed work to our product owner
• ... 

When I think of requirements, I think about who consumes them and the value that the consumers get from them. Many teams have lost their way when it comes to agile requirements and requirements related artifacts.

One of the primary differences between old style requirements and new style is that in an agile world we progressively elaborate requirements. That simply means we add detail to our requirements based on priority. The requirements at the top of the backlog have details as needed and the requirements near the end of the backlog tend to have very few details. In this way we provide the requirements  just-in-time for the next development cycle. There are several advantages to this approach, including:

• Increased team collaboration as requirements are developed
• The team saves effort when items at the bottom of the backlog aren't built
• Latency between requirements identification and development is reduced
• Team members can reasonably consume the requirements (as opposed to reading a 200-page requirements document filled with "The system shall..." statements)
• ... and the list goes on...

Regardless of approach, the primary reason we have requirements is to create understanding amongst the team members and other interested parties. We need them to build a system. How we document requirements can vary. The question is: does the team have a solid understanding of the requirements when building new or modified functionality? The answer is sometimes yes and sometimes no. It seems agile teams have forgotten how to use requirements related artifacts as part of development. Many teams write user stories, not always good ones, and they don't cover what is needed for the team. Something's missing. 

I like to use a metaphor when describing requirements. A single requirement starts as a one-liner. The one-liner is typically written in the form of user story: "As a ... I want to ... so that...." That gives you the placeholder for additional conversations. From there we move to a paragraph. The paragraph adds the acceptance criteria to the user story. Many times that's all we need. However, other times we move beyond a paragraph to a single-page. The single-page includes additional details. From there, in some cases still more is needed. That's when we write several-pages. 

Agile teams consistently write one-liners and paragraphs, but many of those teams have forgotten what else can be documented or worse they've never heard of anything else. It's time to revisit what we can do when we need more than a paragraph; that is, what does a single-page or several-pages look like.

The next few posts will cover options for adding details beyond our typical one-liner and paragraph.

Modeling notation can be found at: www.uml.org