Everyone likes a user story. People nowadays equate user stories with Agile or AMDD. But of course the same thing must be done in every software development project, whether waterfall, agile, or something else.
A user story is one short phrase that says one thing the customer wants to do with the software. Let’s say I’m building an online software product like Amazon. Here is how user stories might be created by a customer working with a team or a requirements guru. The customer writes:
- I want to buy a book.
- I want to get an email when a DVD is available.
- I want to keep a list of items to buy later.
- I want to see what I’ve bought in the past.
- I want to rate items I’ve bought.
User stories typically can be divvied into tasks and tasks into daily/weekly work assignments. Therefore some user stories must be broken into smaller pieces. The requirements guru works with the customer to flesh out larger user stories into several smaller ones. For example the first one, “I want to buy a book,” becomes:
- I want to find the book I want easily and quickly (search engine features, separate books from DVD listings, etc.)
- I want to buy a book with a credit card (store the card, transact without storing the card)
The work here is to flesh out the necessary user stories to lead to thorough usage requirements that lead to programming tasks, while the parenthetical notes feed into technical requirements.
The classic medium for a user story is an index card. One reason for this is that the user story should be written by a customer, or end user, and it’s easy to ask a customer to sit down and write a sentence of “one thing they want to do with the software” on an index card. This will require several sessions.
Each index card should have a space in the bottom corner to designate its priority, and its time-to-program estimate (e.g., # of hours, or # of days, to program this piece). Priority can be numbered 1–10, 1–20, or regular terms like, must-have, really-should-have, should-have, very-nice-to-have, nice-to-have, keep-if-convenient, discard (just be consistent). For time-to-program estimate, some people use a point system, with points equating to # of hours (e.g., 1 point = 3 hours). I think it’s better to just use real time units, hours or days. Hours is best because days leads to too many decimal units (1.2 days, .5 days, etc.).
Each index card should have an identification number, such as 0001, 0002, 0003, etc. When you write requirements, keep the user-story number from the index card with that item in the requirements. When you write a test case, keep that same number with the test case item that tests that requirement, and that story from that index card. Keeping the number connecting the same item from user story, to requirement, to use case, to test case, to testscript (whichever you use), is called maintaining a traceability matrix: trace the item being tested all the way back to the original user story. This makes you more efficient, writing tests for only verifiable required functionality, with test-result visibility into which user stories may be in jeopardy, and many other reasons.
You can use the back of the index card to flesh out the user story further if necessary. You can add notes from the team, complications, comments from the customer, etc.
Group the index cards by category for easier batching into sets of tasks and release iterations. For example, here are a couple of categories for user stories/tasks/programming-assignments/weekly-releases:
- I want to find the book I want easily and quickly
- I want to buy a book with a credit card
- I want to choose between shipping options
- I want a printable receipt after I buy something
A different category of stories:
- I want to store my credit card information so I don’t have to type it in each time I buy something
- I want to be able to change my credit card information easily
- I want to be able to see my account history
As I said earlier, index cards are the classic medium for user stories. But I prefer to transfer index cards into a spreadsheet. In fact, user stories can come in any form, even emails, which can be transferred into a spreadsheet. But you need to ensure all the user-story components are there: the customer usage, the ID #, the Priority, and the Programmer’s Estimate. It’s easy to store those in columns on a spreadsheet; or a workbook with a spreadsheet for each category, for example.
However you decide to process user stories, make sure they are worked until they represent small pieces of coding, are verifiable and testable, and prioritized for pipeline efficiency.