6-7 minutes<\/p>\n
A user story is a lightweight method for quickly capturing the \u201cwho\u201d, \u201cwhat\u201d and \u201cwhy\u201d of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are \u201cto-do\u201d lists that help you determine the steps along the project\u2019s path. They help ensure that your process, as well as the resulting product, will meet your requirements.<\/p>\n
When getting started with writing user stories, a template can help ensure that you don\u2019t inadvertently start writing technical tasks:<\/p>\n
User stories only capture the essential elements of a requirement:<\/p>\n
Here is a simple format of user story used by 70% of practitioners:<\/p>\n
Action \u2013 The behavior of the system should be written as an action.<\/p>\n
Benefits \u2013 The benefit should be a real-world result that is non-functional or external to the system.<\/p>\n
Ron Jeffries, another of the creators of XP, described what has become our favorite way to think about user stories. A User Story has three primary components, each of which begin with the letter \u2018C\u2019: Card, Conversation, and Confirmation to describe the three elements of a user story. Where:<\/p>\n
A user story is defined incrementally, in three stages:<\/p>\n
And these, although, are known as the 3C\u2019s \u2013 Card, Conversation and Confirmation. We will talk more about this later on in this user story guide.<\/p>\n
Card represents 2-3 sentences used to describe the intent of the story that can be considered as an invitation to conversation. The card serves as a memorable token, which summarizes intent and represents a more detailed requirement, whose details remain to be determined.<\/p>\n
You don\u2019t have to have all of the Product Backlog Items written out perfectly \u201cup front\u201d, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business\/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories. The Card is usually follows the format similar to the one below:<\/p>\n
As a ( role ) of the product, I can (do action ) so that I can obtain (some benefits \/ value)<\/p>\n
Note: The written text, the invitation to a conversation, must address the \u201c who (role) \u201c,\u201c what (action) \u201d and \u201c why (benefits) \u201d of the story.<\/p>\n","protected":false},"excerpt":{"rendered":"