Skip to main content

Writing Effective User stories Agile Scrum!!


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 CsCard 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


·         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.


  1. Hi Mohammed,
    I 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


  2. Kindly share your email and linkedin contact



Post a Comment

Popular posts from this blog

(AsyncWebClient) Async Webclient for windows phone 8

Using windows phone web client is pretty common but the thing is you can not use it using Async -> Await mechanism so i used threading to create an async functionality for The Download string and upload string methods here is the code below // Comment public class AsyncWebClient { public Task DownloadString(Uri uri) { var task = new TaskCompletionSource(); try { var client = new WebClient(); client.DownloadStringCompleted += (s, e) => { task.SetResult(e.Result); }; client.DownloadStringAsync(uri); } catch (Exception ex) { task.SetException(ex); } return task.Task; } public Task UploadString(Uri uri, string content) { var task = new TaskCompletionSource(); try { var client…

RuntimeBinderException cannot resolver property in Unit Test in case of dynamic return.. Solved

Xamarin UI Tests – Deep dive Part 1

IntroAs the title may describe this is the first of the series of articles that will cover the UI Test of Xamarin in a deep dive, we will start simple and then dig deeper as we go. Since this is very well the first of the series, it will mostly cover up the architecture and the testing technique that Xamarin UI Tests uses.

The Technology
Xamarin UI Test is an automation testing framework similar to selenium, Watir, Watin (.net), Robot and Sikuli, if you have used BDD (Behavioral Driven Development) or a more advanced TDD (Test Driven Development) approach at least you must have come across one of these frameworks, and in that perspective comes Xamarin UI Testing as an automation framework designed specifically for Xamarin Automation testing, For starter Xamarin UI Tests was not build from scratch, instead it was built on top of another UI Automation testing framework that is targeting android and iOS sepecifically which is Calabash, I have to say that this choice was made wisely as of n…