From Requirements to Agile Backlog: A How-to Guide

This is the follow-up to the earlier post about how to generate a backlog for an Agile project from traditional waterfall requirements documentation.

Step 1. From Requirements to Features 

  • Review specifications documentation to identify category groupings
    • Preferably standard functional categories for software projects, ex. reports, administration, data input, data analysis, etc.
    • Focus on identifying distinct processes and grouping them as appropriate
    • Recommendation is to print each requirement on separate piece of paper and stack into categories
  • Identify business value for each feature
    • What is the intended outcome – decision, output, knowledge – of this functionality from the end user perspective?
    • At this stage, this process might involve logical deductions
  • Resulting output – list of functional categories (features) with presumed business value

Step 2. Feature Mapping

  • Create Preliminary Feature Map
    • Map features to indicate sequentiality or other preliminary dependencies such as integration with external applications.
  • Facilitate technical review of feature map (with architect or other tech lead)
    • Identify any new/different technologies that can be used to enchane this project
    • Identify any technical constraints or technological gaps from current infrastructure
    • Create just enough technical architecture documentation as needed
  • Customer review of feature map (facilitated workshop or JAD session format)
    • Walkthrough feature map with product owners (customer/user group or representatives) to ensure that:
      • All essential user activities are reflected in the feature map
      • Any processes that do not add value are acknowledged and removed
      • Roles/personas for each feature are identified
    • Have the product owner prioritize features based on current business value; reassure them priority can be adjusted as project evolves with no risk
    • Capture product owner-identified gaps and dependencies in high-level functional design document. Include any flip chart drawings or other artifacts from the discussion
    • Generate a personas file and review with product owner
  • Resulting output – Reviewed and accepted feature map with high-level technical and functional documentation

Before we go on to step 3, select the first feature to deconstruct

  • Best practice is to choose either the smallest feature for new teams or a feature that has average number of processes based on feature map completed above
  • Recommendation is not to start with most critical component – there is too much risk of not identifying key process gaps or dependencies

Step 3. Feature Process Mapping

  • Generate a step-by-step outline of the process user would take to complete each action, with one step on each index card or sticky note
  • Resulting structure would be something like a skeleton with the essential process along the “spine” and dependent processes dangling like arms and legs
  • Keep in mind that a single feature story can have multiple processes, so you could end up with more than one skeleton for each feature
  • Review with customer or subject matter expect to set shared high-level understanding of scope for the feature

Step 4. Generate high-level user stories 

  • Use results of feature process map to generate high-level user stories
    • Focus on dividing the process into user actions
    • Start with user triggering process on-screen and then determine what needs to happen behind the scenes
    • Finish with how the user is made aware of result and what, if anything, the user needs to do
  • Each element of the process map should be a high-level story
  • Do not need standard user story format at this time; All you need is three or four words for each user story (verb + noun + phrase)

Step 5. User Story mapping

  • For each feature, rearrange user story level index cards or sticky notes into separate processes
  • Complete user story level map for each feature – another “skeleton” output
  • Relatively size user stories – small, medium, large — by using different color stickers on the cards
    • Anything bigger than a large is cue to split into two or more user stories
  • Now you’re ready to start writing user stories for the highest priority items

Rinse & Repeat for each additional feature

  • Keeping true to the Agile value of just enough and just in time, do not deconstruct all features at once.
  • Best practice is to deconstruct one feature all the way through the above process and then deconstruct another feature or two through step 3 and resume with step 4 for those features after first feature has been completed

So, has anyone tried something similar? Would really to hear others’ experiences.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s