A User Story in Waterfall and Iterative Methodologies
User stories have proven their value for expressing what the business community needs from IT applications. A child of the Agile revolution, they are proving to be a prodigy. Well-structured, relevant user stories are a business analyst’s best friend whether your organization uses an Agile, Iterative/Spiral, or Waterfall software development approach. I go so far as to recommend them as a mold for the majority of stakeholder requirements on a project where stakeholder interaction is a significant component.
When I use the term “User Story”, I am not simply referring to the generally accepted construct “As a {role}, I can {have or do something} {within specific parameters} to {achieve a business value}”. I do fully buy into that construct (as you can see in my KnowledgeKnugget™ Business Analysis Using User Stories), but that is not the entire user story. IMHO, a well-structured user story actually consists of four parts (and old Omna Gallia only had three parts – does that make user stories more important than Julius Caesar?):
User Story Components
- The title is a two- or three-word handle that succinctly identifies the user story for the entire audience and hints at its purpose (e.g., “Compare Premiums”).
- The construct itself is the defining feature of the User Story (e.g., “As a website visitor, I can compare premiums for automobile coverage types for my driver profile to select the most cost-effective option.)”
- The elaboration notes clarify the user story and may lead to breaking one user story into multiple stories (e.g., “coverage types are liability, collision, and comprehensive; liability depends on the driving record, age, residence, gender; collision depends on vehicle value, …” It sound like this user story may need to be decomposed into several)
- The validation or automated tests that will prove that the user story is correctly implemented (e.g., “test liability, collision, and comprehension premium calculations for a representative of each variable” – the number and complexity of tests further supports the idea that this user story is too big and will be decomposed).
What Does This Mean to You?
If I look at those four elements, I see beauty (which Google defines as “a combination of qualities that pleases the intellect or moral sense”). I love the symmetry, the cohesiveness, and completeness of these four elements as they coalesce to create a harmonious construct defining the user’s needs concisely. OK, now, I am just waxing enthusiastically, but you get my drift and perhaps my enthusiasm infects you, too.
My main point is that we should use this elegant structure anytime we are defining a stakeholder need. It is arguably the simplest collection of critical attributes that business analysts, product owners, or whoever writes user stories need to communicate to those who deliver the solution (i.e., the IT department or its outsourced counterpart). It is also the ideal form in which to conduct reviews with the business community because it ties the need to the reason and clearly expresses acceptance steps. I clearly see the dawn of a new era in communication for application development evolving – whether you are an Agile enthusiast or a died-in-the-wool business analyst of the old school.
