Proactively define a user story in Agile: 15 Principles

What is a User Story

A key concept of Agile approach is putting people first. Authoring User-stories is driven by end users benefit. The user story articulates how a piece of work delivers a particular value back to the customer. Note that “customers” don’t have to be external end users in the traditional sense. They can also be internal customers or colleagues within your organization who depend on your team. The typical format of a User story is:

“As a [persona], I [want to], [so that].”

Breaking this down: 

  • “As a [persona]”: Who are we building this for? It is not just a Job title. It is a person to use the application as part of a large team of people to benefit from it. Stories must keep the focus on the user. 
  • “Wants to”: What this person try to achieve? This statement is not the design of the feature. It is the User requirement.
  • “So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

User story tries to capture the essential of the feature. The definition of user story original text may is not enough to build the code. However it should capture the essentials of the feature. Additional information may is required so developers/tester understand the full functionality. Sometimes this additional information could come from an extra design artifact attached to user story, a checklist, a flow diagram etc.

User story and how relates to acceptance criteria.

Acceptance criteria specify conditions under which a user story is fulfilled. In a way acceptance criteria is some kind of expansion of user story. Team uses them to reach consensus, used for estimation and a base for testing, The typical format for acceptance criteria is: “Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).”

Principles of defining proactively a User story.

So you may wondered if the format of user story is well defined what can I do proactively?.

You can follow certain principles. By doing that you proactively design a clear, accurate and complete user story. Those principles can easily be used as checklist to validate your user story before the rest of the team has a chance to provide feedback. This checklist can be used also from the team as a way to achieve a high quality user story definition.

A very popular list of six principals is known by the Acronym I.N.V.E.S.T. This could be your starting point. Personally I believe those 6 principles of i.n.v.e.s.t are not enough. So I created another 2 lists with the acronyms C.U.R.E.D and F.A.C.T. Including I.n.v.e.s.t is a total of 15 principles. Let’s see first the Invest list


  • “I”ndependent (of all others).
    • User story is the starting point to build something in a sprint. Defining a User story with high dependency from other user stories triggers a chain reaction. A story depends on another one that depends on another one etc. A story should be independent enough so team can understand the feature and build the code within a sprint. Defining independence does not mean sacrificing the collaborative properties of the user story. Simply we ensure that User can benefit from the features without having any constraints due to dependencies.
  • “N” egotiable (not a specific contract for features)
    • User story original definition should not dictate everything about what and how will be built. I.e. a developer may find that it is easier to implement an alternative solution from what the original user story dictates. User Stories should be Negotiable, so no time is wasted when the user or customer’s goals can be met with another easier way.
  • “V” aluable (to business)
    • User story must demonstrate some business value. With each passing story the development team enjoys a small win and a sense of increasing the business value of the completed application .
  • “E” stimable (to a good approximation)
    • A User story must have enough and clear information to be estimated. Even if it is estimable does not mean that a User story can be accepted to any size. In fact after you estimate a User story you may realize that is too long and consider to break it in smaller stories.
  • “S” mall (so as to fit within an iteration)
    • As mentioned in estimation a long user story is not good practice. Ideally the user story must be small enough to build in one sprint.
  • “T” estable (in principle, even if there isn’t a test for it yet)
    • A User story implementation code need to be eventually tested. The way that a User story defined must promote validation tasks to verify the correct implementation.


  • “F”easible (You can build it)
    • A user story simply must be able to be implemented in code. Any constraints should not exist when defining a user story.
  • “A”ccurate (No errors)
    • User story must describe accurately what is the essential of the feature. This may seems a contradiction with the principle of “negotiable” but is not. Accurate is about what we need to do. Negotiable is more than 1 ways to achieve that.
  • “C”ollaborative (Obvious how collaborates with rest)
    • You need to understand how the persona uses the functionality in collaboration with other personals. The wording you choose should emphasize collaboration and be consistent.
  • “T”raceable (easy to find)
    • Traceable user story is about the ability of navigating and find a User story based on various search scenarios. Such as trace a user story linked with another user story or linked to a piece of code or to a defect or to a business process etc.


  • “C”omplete (nothing is missing)
    • Defining a user story aim for a complete functionality. This should not be confused with breaking a big user story to smaller ones. A user story should not lack information necessary to implement the code.
  • “U”nambiguity ( easy to understand)
    • I could use the word clarity here. Any member of the team should be able to read/understand the user story. It must be a common understanding about the essentials of the feature. It should be free from any ambiguity.
  • “R”elationship (easy to relate with others)
    • A User story must be written so the relationship to other User stories is obvious. This goes beyond the principle of collaboration. In relationship you may have 2 stories that do not have any collaboration but related. You need to understand how those 2 user stories are related in the context of delivering a business value.
  • “E”vident (Clear to vision)
    • User story must have the format and the kind of language that fits with the vision of the Project and the expected benefit of the User story.
  • “D”one (Finish properly)
    • User stories must have clear Definition of “Done” .  The story is generally “done” when the user can complete the outlined tasks. It should be obvious what tasks are expected to be completed so the user story can be defined as Done.


  • A user story is the building block that describes the essential of a future.
  • There is always a review from the Sprint team and is negotiable how to build the code and implement the story.
  • User story is always User (persona) driven
  • Acceptance criteria specify conditions under which a user story is fulfilled.
  • By following the next 15 principles you design proactively a high quality user story. This way you save time and prevent other issues/defects. As a result rest of the team can focus on the best implementation instead of trying to clean up errors or misses from the user story


  1. “I”ndependent (of all others)
  2. “N” egotiable (Open to alternative solutions)
  3. “V” aluable ( Business benefit from it.)
  4. “E” stimable (to a good approximation)
  5. “S” mall (so as to fit within an iteration)
  6. “T” estable (in principle, even if there isn’t a test for it yet)


  1. “F”easible (You can build it)
  2. “A”ccurate (No errors)
  3. “C”ollaborative (Obvious how collaborates with rest)
  4. “T”raceable (Trace it based on various search criteria)


  1. “C”omplete (nothing is missing)
  2. “U”nambiguity ( No umbiguity)
  3. “R”elationship (Obvious how relates with others)
  4. “E”vident (Clear to vision of the project)
  5. “D”one (Definition of Done)

Thank you for reading my article. I look forward to receive any comments or question you may have. Please follow my blog so we can keep in touch.

Angelos Mavrogiannakis ITQA Services


Ambler, Scott. Introduction to Disciplined Agile Delivery

Leading Agile

Atlassian User stories

Agile Alliance

Product Plan

Agile for All

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: