I'm still not happy with Agile user stories. The User Story should set a goal for the team. Most perspectives of story writing I see follow the LeBron James school of thought. The typical user story I read finds value in winning for the individual player and then the projects follow those rules running into conflicts. I think it's time to do some coaching examples from stories I found on the internet.
The easy expected format
The traditional user story format:As a (role) I want (something) so that (benefit)is supposed to benefit the person/business paying for the work. Or at least that's what I want if I'm in charge. You don't want to watch the project goals slip away and then everybody and their dog starts wanting something different. Without a guiding set of project value propositions, the user story will look like
As a <stakeholder> I want <something for me> so that <several excuses>.Just making an excuse for a personal need does not make a user story a requirement nor makes it easy for a developer to code it. When it's in any kind of formatted statement, the analyst can put it neatly into a document and make it passable as a project document. It's now user stories. Nobody questions it because there are no well understood rules about a good user story.
So stop already. Here's my rules (I get to make the rules if I'm paying for it):
- The role/stakeholder triggers the activity. It's like a security group description instead of a real type of person at this point. Make it broad.
- The something is for the business. Make it the focus.
- The benefit is for the business. Make it have value. No excuses.
- Use testable functional requirement writing. Any kind of limitation of data or process is a rule.
The hard part
Let's apply this several different ways to sets of requirements I found. In my style of writing requirements, the business rules are extracted out and placed under the requirement (they are given an ID if reusable and placed in another document). The information about the data entities are extracted out and placed in a data dictionary with the business details. The design elements are noted. And any project information is noted as well for inclusion in the project plans. Only the rules stay with the requirements while the rest get sorted and filed away in their own documents.
Desktop backup app
Here's an example of an epic with two smaller user stories:
- As a user, I can backup my entire hard drive.
- As a power user, I can specify files or folders to backup based on file size, date created and date modified.
- As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.
It's interesting to me that this first choice extracted from my Google search didn't bother with the benefit part. So here's my take on them collapsed into one story:
- As a user, I want to backup my hard drive so I can restore files.
- RULE - select files by size, date created, data modified, user choice.
- RULE - select folders by size, date created, data modified
- DATA - File: name, size in Kb, date created, date modified
- DESIGN - option to select an entire disk backup is the default?
The distinction between the two roles fades away as the trigger is the same for the same result. The ability to use rule-based choices for file selection is what the user story author thinks is important. But the importance might come if there is a functional difference. The distinction between the user and power user will appear as design personas for testing.
Most of the meat of these requirements is in the rules which corresponds to my experience of seeing a document fluff up by including the rules as variations of requirements. It's just bologna.
Most of the meat of these requirements is in the rules which corresponds to my experience of seeing a document fluff up by including the rules as variations of requirements. It's just bologna.
Agile project management app
Here's another example of four related user stories with other information included from the three other stories that were deemed too broad (vague) or too detailed (mostly data info):
- A team member can view the iteration's stories and their status with main fields.
- A team member can view the current burndown chart on the status page, and can click it for a larger view.
- A team member can view or hide the tasks under the stories.
- A team member can edit a task from the iteration status page.
This one was interesting to me because the template for writing a user story looked very promising and included the goal of expressing business value. I just didn't see it in the stories. Here's my version:
- As a team member, I want to view project user stories to be aware of project scope.
- RULE - select stories by iteration
- DATA - User Story: status, tasks, main fields(?), rank, name, size, package, owner
- DESIGN - tasks are able to be hidden and shown under story
- As a team member, I want to view project status to be aware of project management metrics.
- DATA - User Story: is in scope, hours estimated, hours worked
- DESIGN - project status is best viewed as a burndown chart
- DESIGN - the burndown chart should be able to be viewed larger
- As an analyst, I want to manage user story tasks so that user stories have details.
- DESIGN - CRUD should start from the iteration status page
Credit card payment
Another story with additional details from the same Google search result above really did use some value so here's what it looks like before:
- As a purchaser on the website, I want the ability to pay with a credit card so that I may immediately confirm my purchase.
- Acceptance criteria
- accept Discover, Visa, MC
- Validate CC# when entered
- Validate expiration data and CVV
- Validate billing address
- Generate success and failure messages after processing
- Definition of Done
- passes all regression tests
- passes testing per acceptance items
- approved by UI team
- able to show feature in company demo
- mockup.png
and after using real world documentation:
- As a customer, I want to purchase a product with a credit card so that transactions are convenient.
- RULE - credit cards must pass basic local validation before submitting to credit card processor
- credit card type - Discover, Visa and MC
- number - passes Luhn algorithm
- expiration date - after or equal to date of transaction
- RULE - credit cards submitted to credit card processor must validate with the following information (or create separate DD item)
- credit card number
- expiration date
- card security code
- billing address
- RULE - credit card validation should be done within 2 seconds
- DATA - Credit card: type, number, card security code (not stored), expiration date
- DATA - Message: body, time/date, ID
- PROJECT - Testing, exit criteria: All regression tests must pass.
- PROJECT - Testing, exit criteria: Entire UI team approves screen forms.
- PROJECT - Testing, user acceptance: prepare mock data for company demo
- PROJECT - Project plan, stakeholders: Credit card processor, customer
- DESIGN - suggested screen layout of entry form - mockup.png
- DESIGN - self-service customer purchases are best made on a web site
I really don't know why I need to confirm my own transaction since I can't confirm with anything. The confirmations are the validations which should be made quickly. The validations are really in two phases since it's a system dependent on a credit card processor.
Summary of value driven analysis
I believe that people don't do requirements well. It's why user stories were advanced as a replacement for bad requirements. In some ways I agree with Cowan+'s throwing the baby out with the bathwater statement, "User stories are not requirements. They were meant to replace requirements, which suck." But I think that they just help do a better job at user needs elicitation. And then the rest of the analysis should be about writing the business value user stories/use cases.
By following a format of zeroing in on the functional requirement and extracting out all the distracting and fluffing-up text into their own documents, I believe it's much easier to create usable requirements. The thing that drives the requirements the best is value. But it's value to the business, not value to the individual stakeholder. Do it for the team. Don't be LeBron.
Past related blogs
- Re-inventing usable requirements: Value-driven projects & the failure of the Agile user story
- As an Agile user story writer, I want a kitten. - Rewriting user stories for business value
