User Story


A user story is a brief description of a desired feature, which contains enough information for the team to estimate it and potentially develop it and test it in one sprint. The typical format of a user story is as follows:

“As a <role>, I want <goal/desire> so that <benefit>”


“As a job seeker I want to add a new resume to the site so that I can apply for jobs quickly”

user story


Anybody in the team can write user stories and add them to the product backlog but Product Owner owns the product backlog so it is expected of him to write and prioritize the user stories in the product backlog.


One of the first things to do right after the start of a project is to write user stories for the product to be developed and add them to the product backlog and also prioritize them. But the User stories are written throughout the life of a project.


Like my blog? 


8 thoughts on “User Story

    1. Agreed. Here’s some thoughts. Of course everyone can have different views. These are my comments regarding a few of the stories…
      Create, Search, Update, Archive, Remove are each a unique user story.
      “Provide a means for a CV title” is an activity of creating or updating a CV.
      “Create up to 3 CVs” belongs to the create story.
      “text version of CV” is an activity of of the Create or Update stories
      “sign on” is a user story as well as the typical forgot user id and PW and new user…
      “ensure the job seeker’s CV is stored in the CV database” is the same as the Create User story.

  1. I agree with Stephen.

    Also, I have worked on projects where there are so many Stories that start something like “As a System User….” – it turns into a woods and trees situation.

    An alternative, which as a Coach I encourage, is to put the business objective first.

    In Order to..
    As a..
    I want..
    So that..

    It tends to divide the backlog a little more, visually. And yes, I have seen it work better.

  2. I find syntax of Agile obtuse.
    As a , I want to so that
    can and ought to be shortened to,

    I don’t get why I would ever want to see repeating “As a …, I want to….so that …” syntax.
    gets right to the point, without silly extra words, and yes they are silly.

    Customer can open account — straightforward.
    As a Customer, I can open an account so that I can have an account — wow, unnecessarily wordy.

    When rationale is really needed, it can be put into the details as “Rationale: …” In practice, it’s actually rarely really needed.

  3. Case in point is the example you cite:

    As a job seeker, I want add a CV to the site so that I can apply for jobs.

    really? ….so that I can apply for jobs?

    Actually that creates a problem. There’s an implication here. The implication is that I CAN’T apply for a job unless I have a CV — maybe. Or maybe that I can but somehow that affects my ability to apply for a job in some unknown, unspecified way. It clearly confuses the story more than it clarifies it.

    If it actually were intended to restrict my ability to apply for said jobs, then I would think there should be an additional story like:

    Job Seeker cannot apply for job without CV
    Job Poster is not shown Job Seekers without CV

    I actually even have trouble with the simple statement “I want to”. Ok, well, we all want to do a lot of things. “USER CAN” makes a statement. And in fact when dev has verified and QA has approved, it states that a USER CAN do x.

    I really wish people would start using terse syntax and stop creating bloated stories. The terse syntax is also easier for a business person to understand, frankly.

    I have nearly always found rationale to be misused, confusing, unnecessarily coupling, and otherwise problematic.

  4. And I agree with Steven, this is an example that most practitioners would call an Epic, not a story. It contains many potential stories. Highly unlikely to be an 8. Probably more like a 50 ( or whatever is “needs to be seriously broken down” in the point scheme you use). It’s a kitchen-sink of functionality around CV. I can upload text (a story), I can search and upload from my drive (another story, or more), I can have multiple CVs and/or historical CVs (unclear, likely several stories). The rest is implied technical noise (performance, scale, CRUD operations etc). In fact the CRUD can often be separated into several stories. It isn’t typically required (nor necessarily desired) for a user to be able to delete something they’ve created, and even if it is, in agile practice, it is often less confusing when CRUD is broken out. The R in CRUD (reference) is often fragmented throughout a system (where should I see it displayed). Agile says, think small, don’t commingle.

Leave a Reply

Your email address will not be published. Required fields are marked *