Welcome to EMC Consulting Blogs Sign in | Join | Help

Peter Measures Blog

User stories produce better quality results

As a BA I want to provide requirements that are concise as possible.  If requirements are not concise enough this can lead to costly changes to a solution. I intend to demonstrate this by comparing user stories with requirements and highlighting why user stories provide higher quality results. By doing so I hope to persuade you why user stories deliver better solutions.

Here I define

 User story: As a <actor>, I want <goal/desire> so that <benefit>

Requirement: The system shall provide <goal/desire>

Where items in “<>” are variables. The user story conveys more information than the requirement. That is the actor and the benefit. They are concisely defined in one statement.

With requirements the actor can be determined by the mapping between requirement and use case but additional information (the reference) is required which increases the chance of error.  

The justification column in the requirements catalogue is often not written as concisely as the requirement as it’s separation from the goal/desire can leads to being treated as "for information purposes only". Furthermore when two actors are involved the justification can be muddled or biased.

This is why I believe the user story creates better quality because it is so concise in all respects.This conciseness can lead to developing a more complex but a much more valuable solution.  Say we have a user story and a requirement with the same goal/desire. Two “errors” are possible in the requirement:

- The requirement is mistakenly applied to two different actors.

- The justification reduces the fidelity of what the different benefits each actor may hope to achieve

If either case occurs then a single solution may result for both actors where extra benefit could derived in having different solution for each. As the cost of fixing software based on a requirement misunderstanding increases markedly as it is developed, tested and deployed the cost of separating the single solution into two later will be much more expensive.

The user story has been associated with Agile development, but it’s adoption has become more universal and I hope I have convinced you to use them as well (if you don’t already).

Published Tuesday, January 08, 2013 4:15 PM by peter.measures

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Nadeem Khalid said:

I agree with the point about conciseness, in other words it is "to the point" no more no less (!)  I also think that in comparison to other methods for capturing requirements we have historically used such as use cases or FRS, BRS, HLRs etc, user stories are far easier for business and other stakeholders to relate to, interact with, discuss, elaborate, prioritise, deliver and test.  That is of course assuming the acceptance criteria are effectively stated.

January 9, 2013 9:51 AM
 

peter.measures said:

Thanks for the comment Nadeem. On your acceptance criteria point I wrote the follow blog on Behavioral Driven Development.

http://consultingblogs.emc.com/petermeasures/archive/2011/01/04/behaviour-driven-development.aspx

This approach prescribes a very succinct method for writing acceptance criteria.  

January 9, 2013 10:21 AM
 

Steven Goddard said:

1. Reflections – EMC Executives Report From The Road Information Security Shake Up: What to Expect in

January 10, 2013 12:19 PM

Leave a Comment

(required) 
(optional)
(required) 
Submit
Powered by Community Server (Personal Edition), by Telligent Systems