Intro:
A couple a weeks ago, I was assigned a task of writing user stories and it was quiet the challenge as I have no Business Analysis Experience and the cause of this task is to improve my skills in that area in specific so I ended up writing a good and effective user stories according to my lead and I have to take his words for sure, he is the guy with the 9+ years of experience so I decided to write a blog about it though it is not very technical but still a thing that I found really helpful despite the lack of code and of course less code equals less fun So let’s get it started shall we.
The Three Cs:
A User Story consists of three parts usually referred to as the three Cs “Card Conversation and Confirmation” and they are pretty simple in matter of what they are let’s take them one by one.
The Card:
The first part of the user story, usually reffered to as the title of the user story it is a simple sentence that contains the main purpose of the user story and it should be in this format.
As a <User> I want to have the ability <Feature> to <Achieve a certain goal>.
Each of the underlining between “<> “ could be replaceable by any party of the same as its parent for instance the user can replaced by anyone who uses the system, maybe the manager, an employee, a system admin or anyone who falls under the user or counted as a user. Also “Feature” and “Achieve a certain goal” they also should follow the same scenario in other words it is the matter of what the customer say in the deferent rules.
The Conversation:
The second C in the user story Cs is the Conversation part and it is the part where you should put every details and the long description of the user story and if say there was points of confusion that needs to be checked back with the customer they should be also highlighted in that section
More info won’t hurt in other words try to have as much details and stuff related to the story, as you never know when they might come in handy to whoever uses these stories.
They should be readable by anyone no matter what are their technical expertise or business as they are being used by both technical and non technical users for reference so they should be a certain level of care, when the more details is very preferable but making them complex to read is not gonna make the user story effective and thus who is ever going to use will just throw it back at your face so put every detail put it simple and user friendly to read.
So if I was to describe the Conversation section I would go like: a lot of details that are easy to read and specific.
Use business language “everyone can understand business language because it is English so dare not to write a piece of code here”
The Confirmation:
The third and final C in the user story the Confirmation, simply it is the way we are going to confirm this feature, How? Simple two words most of the good testers in your company should probably know it is called “Test Cases” and they are simply used to see if everything in this feature is as it suppose to be so if there should someone who will reject this user story it is the tester who confirms, So every user story has a confirmation which is the test cases linked to the user story and written by the testers
That would be it but at last there is some tip or two that should come in handy when writing User Stories
Tips:
· One of the best ways to write user stories is to let the customer write them “if you are familiar with the scrum in this example we can let the project owner do this if you have one” but sometimes that is not very practical so here comes a solution called role-playing, in other words you can put yourself in the customers shoes and make sure you understand the user story without the help of your other side “The developer side”.
· Make the user stories in the moderate size not too small and not too large it is defiantly what you don’t want to do make them simple to be able to explain them quickly to the rest of the team.
· Making the user story testable in other words you have to be able to write test for this user story and you have to be able to extract steps in order to confirm these user stories.
Hi Mohammed,
ReplyDeleteI was pleased to read your blog it is very informative regarding user stories and AGILE.
I had a question to you kindly help me out:
Recently i went through a client interview & this particular question was asked to me -
If Tying a Shoe Lace is a business requirement, then what would be User stories, Features, feature group for this business requirement
waiting for your reply
thanks
Regards
Rohit
Bagalore
INDIA
Kindly share your email and linkedin contact
ReplyDeleteThanks