Almost all the Scrum teams I have worked with use “User Stories.” However, most of them are unaware of the origin of “User Story,” All of them think that user story is a “requirement.” In a sense, it could be correct, but that’s not what a User Story is.
What is a User Story?
In the simplest terms, a User Story is a way to express requirements. When a requirement/ functionality is described from the perspective of the user of the product or system or software, it is termed as a User Story.The Origins
User Story or just Stories originated with Extreme Programming. In his book “Extreme Programming Explained” Kent Beck describes Stories as a primary practice used by the XP team. Within XP, the User Stories are written by the Customers as the functions or features that they want the system/software to do for them. It is often in the format of three sentences written by the Customer. The User Story always focuses on the needs and benefits of the user. Keeps the details like technology or implementation aspects out of it.The Basics Of A User Story
As stated above, a user story is a way to express any requirement from the user's perspective. And it could be as simple as a single sentence: “A student can register for the desired course.” Here, although, the details are not available. It simply says a student, a course, and register. What should we do with it? And this leads to a discussion, a process of creating a common shared understanding about what this requirement is.These conversations typically flesh out the details of the user story and often helps the developers and business to agree upon when we can say the user story is completed. Ron Jeffries describes these three aspects of the User Stories as 3C’s. Card, Conversation, and Confirmation.
Card: In the good old days, user stories were written on a card (index/sticky notes). This did not have all the information describing the requirement but just enough to establish what the requirement is about. It is often used as a token to get started. This card then leads to the second C - Conversation.
Conversation: The business and developers now work together to establish clarity about the requirement through conversation. This happens multiple times till everyone has a common shared understanding about what the requirement is. Although this conversation is often verbal, notes are made, and criteria are established to determine when to call the user story complete. This established bar is the third C - Confirmation.
Confirmation: Despite all the conversation and documentation, there is always a possibility for uncertainties and assumptions. Confirmation refers to the final aspect which determines whether a user story is complete or not; whether the User Story does the intended functionality. This confirmation is also referred to as “Acceptance Criteria”.
The refined template for User Stories:
In most teams that I have worked with, User Stories are not one-liners, as I expressed above. They have a very specific syntax as follows: As a role (who wants to do something) I want to do (the activity that needs to be accomplished) So that value (the goal that will be achieved) Example: As a book lover I want to read book reviews So that I can decide to purchase a book This template was invented at Connextra, an early adopter of XP practices (source: User Stories Applied, Mike Cohn).You might be interested in reading: Definition of Done vs Acceptance Criteria
Writing Good User Stories:
Bill Wake, another XP practitioner, developed the concept of INVEST for User Stories. INVEST is an acronym that stands for:
I => Independent: Avoid dependency on other user stories. Keeping user stories helps us to deliver value faster.
N => Negotiable: User Stories are not contracts that need to be always met. A User Story leads to conversation, which gives the flexibility to add details as needed. Focus on the idea and leave out the details for a later point in time.
V => Valuable: Each user story needs to be valuable for the customer end-user of the product.
E => Estimable: User Stories are often used for planning the work. Thus they need to be estimated. Putting an estimate helps the business to understand when the work can probably be completed.
S => Small: A User Story needs to be small, as small as can be completed within one sprint. The smaller the better; it reduces any complexity, uncertainty and also makes it easier to estimate.
T => Testable: Testing ensures the quality of work. When a User Story is testable, it implicitly determines that it is well understood, and with the tests, it can be easily verified whether the purpose was achieved.
Learn to write good user stories today: Enroll in the Professional Scrum Product Owner (PSPO-I) Certification Training
