Stories of all sorts

Stories of all sorts

Almost all projects are some combination of functional requirement (needs of the user), technical/architectural requirements (needs of the systems environment) and non-functional requirements (e.g. branding, maintainability and usability needs). In order to successfully deliver any project the team needs to meet all of these requirements. Classic Story Maps focus only on user stories.  However, projects that incorporated all of the different units of work to into their Story Map find that it is a more effective method for prioritization and release planning.  Using an Agile Story Map, projects fare better using a single, visualizable backlog. This increases the focus on delivering the project as a whole, rather than as separate streams of work.

This is the basic process: (See this post for an in-depth discussion of the process to generate needs and user stories.)

  1. Gather a cross disciplinary team of 3-7 people.
  2. Have the team identify the marketable features of the project/application (on sticky notes).
  3. Have the team group/rearrange the sticky notes.
  4. Name each group.
  5. Arrange the groups left to right in the order that they would naturally occur.
  6. Review/walk the skeleton.
  7. Break each Epic or user task down into more detailed user stories or activities.

You need to add several steps to incorporate technical or non-functional requirement to the process. After constructing the initial Agile Story Map, which is generally comprised of just functional user stories, we need to add the technical and non-functional stories. The steps we add are:

  1. Refocus the cross disciplinary teams.  Walk through the definitions of architecture, technical and no-nonfunctional requirements.  Remind the team that goal is not to design or generate solutions, but rather to identify known needs or constraints.
  2. Review/walk the current, functional skeleton established in the first seven steps. (optional)
  3. Identify the high-level technical or non-functional requirements (similar to step 2 above).
  4. If any new Epics have been identified, break each Epic or user tasks down into more detailed user stories or activities.

Special note on non-functional items:  Non-functional requirements are not generally separate units of work, but rather attributes that describe technical or functional support. Non-functional requirements include the “ilities” (e.g. usability, maintainability and others) and can be easily incorporated in to the definition of done and/or story-level acceptance criteria.

The controversy with this implementation of Agile Story Maps is not that there are units of work that are technically and architecturally focused, I think that if you have ever run a project that this is evident.  Rather the controversy is when these types of needs are identified in the process and whether they should be incorporated into the Agile Story Map. Story maps are a tool to prioritize and plan.  Agile Story Maps are tools that you and your team can use if you find it useful to include more than users stories.