Several people have been asking me lately, which is the better format to write requirements: Use Cases or User Stories? To answer the question, we need to know what they are. User Story has been in vogue lately due to the increasingly wide adoption of the Scrum methodology. It is typically written like this: “ can do , because of and .” Use Case has been around longer, and Alistair Cockburn (co-burn) made writing use cases a science in his book Writing Effective Use Cases.
People typically have this perception, right or wrong, that Use Case is a more structured, formal way of defining requirements; whereas User Story has a reputation of being more approachable to non-techies, but disliked by engineers because it does not tell them enough about what to build.
Here’s my take of (and in IMHO a more useful way of looking at) the problem: a User Story should be used at the beginning of the conversations between the customer (or the product owner representing the customer) and the engineers; whereas a Use Case is what the requirement looks like after the conversations happen. Notice that I said conversations in plural form, because to get to an agreement or understanding of what to build between the customer and the development team, you need multiple iterations and reviews.
Let’s say we are writing a requirement for the scenario: Withdraw Money from ATM. You can start with a User Story that goes like this: “The account owner can withdraw money from the ATM machine, so that she does not have to wait at the teller line, and the bank branches can avoid paying for more headcounts.” A good engineer would ask: who is an account owner, how do we know that she is the account owner, how does an account owner initiate the transaction, is there a limit on withdrawal: per day, per transaction?, what happens if there is not enough money in the account?, etc., etc. In a Use Case, the answers to those questions would be written in the Triggers, Main Scenario, Alternate Scenarios, Success Goal, and so on. A good developer or test engineer would be ecstatic to have all requirements done the Use Case way, because it is very precise and complete. But it does put a lot of burden on the Product Manager to write all that. I have worked in environments where I started with User Stories, and I meticulously documented the answers, just not in the rigid Use Case format, and they’re fine with that.
Back to the beginning question, which is better: Use Case or User Story? The answer is whatever works for the team and organization. The key is the team should not avoid the hard work of asking the difficult questions, finding the answers, and documenting them. I have seen too many teams use Scrum and falsely tell themselves: great, we don’t have to document as much, and we can start coding. Bad news: no methodology will free you of those, unless you want to release a crappy product. User Story is a great way to start the conversations about the requirement, and Use Case is a great way to organize the information surrounding a requirement in a structured format.
Republished with Permission from Fit To Market