To the best of my knowledge, user stories follow a format such as
As a [role], I want to [do] such that [benefit] - (This takes 8 days to develop)
Recently in the book Software Engineering by Ian Sommerville, I learned about a different story format such as below
Which is broken down into
What is the difference between the above images and the typical user story I mentioned earlier? many thanks
The classical user-story describes a desired feature from the point of view of a user. It is very synthetic in view of the 3 C: stories are written on a Card, they are the promise for a Conversation (an interactive exchange with users), and they are completed with a Confirmation (criteria for checking that expectations are met).
With this in mind, user stories only tells who needs what feature for which purpose:
As a doctor, I want to prescribe medication so that patients get the right dose
But it's hardly sufficient to produce useful software. It's only a reminder that you have to talk to a doctor about the medication prescription and clarify how the software could best help to achieve this goal. That discussion -- the direct interaction with the user to understand the needs -- is the real key to success with user-stories. The story template is just a mean to this end.
The textual narrative is story telling. It's the outcome of the discussion with the user, if captured/written down. It is very useful, because the doctor can project herself in the future and imagine how it could work with the software, and the team can understand what is to be delivered with the relevant details. It is vital to tell this story with a focus on what should/could be, and not on what was until now.
The task-based presentation is a further decomposition of the narrative into key parts, that provide the more precise description of the feature along with expectations that the software shall meet.
The format As a [role], I want to [do] such that [benefit] for user stories is known as the Connextra format, after the company where it was developed and used.
The original concept of user stories was developed by the team using Extreme Programming while building the Chrysler Comprehensive Compensation System, where they didn't have a strict format. There, stories were represented by cards with just enough written on them for stakeholders to understand the work and scope.
There are also stories that aren't user stories - job stories that focus on the situation and job to be carried out or problem stories that define a problem and proposed solution or improvement stories that capture the current state and desired future state.
It really doesn't matter what the format of a story is. The representation of the story is just a placeholder for conversations between the team and stakeholders, capturing just enough information to support planning, design, development, and testing of the work that must be done to satisfy a stakeholder need.
