Writing Good User Stories

Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here: User Stories.

User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front.

As a guide for people writing User Stories, they can follow this basic construct:

As a [user role], I want to [goal], so I can [reason].

This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.

As well as capturing User Stories in the above format on the Product Backlog, User Stories should be written on a card.

The card comprises 3 parts:

  • Card (i.e. the bit above, “as a user, I want…”)
  • Conversation (notes and/or small wireframe to remind people about the feature)
  • Confirmation (the tests that will show the feature is complete)

Here’s an example User Story for you to take a look at.

Ultimately, User Stories should be small. But when they’re first entered on the Product Backlog, when they’re quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.

Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.

Here’s a PowerPoint presentation about User Stories to help share the concept with others.

The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:

* Independent. Okay, for some systems, it’s near impossible to make each feature completely independent. In other solutions, e.g. web sites, it’s easier. But it’s an important aspiration. User Stories should be as independent as possible.

* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

* Estimable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

* Small. User Stories should be small. Not too small. But not too big!

* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

I hope this series of posts has been useful…


8 Responses to “Writing Good User Stories”

  1. PierG says:

    congrats, a very good summary.

  2. Patrick Merg says:

    Nice set of articles. I read the comments on making user stories Independent. Making a user story Independent is really hard especially on large projects.

  3. Unpublished Guy says:

    This article reminded me about one user story that was once presented to me as an example. In this case the user were prospects at a trade show that would need a demonstration of a hypothetical company’s yet-to-be-completed software product. So given a limited time to include the features of the product in a demo, what do you include.

    Almost everyone thought that a login would be necessary, which seems like a logical starting point. However, for the purposes of a demo, it really isn’t that necessary. It is not exactly a feature you want to show off. Much better to focus on features that will impress and bypass the login.

  4. Rajeev says:


    Very useful and well written. It helped me come up to speed with Agile, a lot of PMs will find this a good starting point.


  5. Bhavtosh says:

    very nice article


  6. Sena says:

    Hi Kelly,

    Could you also give a similar example of writing a non functional requirements please? This will help us to understand how to write user stories for such as well.

    Thank you very much.

  7. AnAn says:

    Very useful! Crafting a perfect user story requires a bit of experience. Here’s our recipe for doing it the right way: https://netguru.co/blog/posts/doing-features-and-user-stories-the-right-way

  8. tunay says:

    Hi Kelly,

    I am an international grad student in the U.S. and I am taking the agile management for project managers class this term. I am learning a lot of new things from both school and online. Agile is very different from traditional project management. I have used user stories for the first time in the class, and I found using them very useful. It is very simple way to delivery information or learn what users’ expectations are. This small piece of paper definitely improves the communication between the project ownership, team and end users. Or it helps to make things clear.
    The first question came to my mind is why traditional project management does not borrow this simple tool from Agile. I know I am not the first person who would think of this but the idea of user stories can be used in traditional project management. For example, the project manager would use something similar to user stories to develop a risk register.
    I don’t know if someone else have tried to use the idea of user stories in traditional project management but I would like to hear from your opinion about adopting this simple communication tool to the traditional project management. I also think that there are many agile tools that be used in the traditional project management.

    Thanks and best regards

Leave a Reply

What is 2 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”