I read on a similar forum https://stackoverflow.com/questions/8117530/examples-for-acceptance-criteria-for-a-user-story about putting in the acceptance criteria for product backlog item.

I am working on a Scrum based project and I need more info as my backlog item is as follows -

UserProfiles ( I am using this in the title field in tfs 2013) and the description contains all the "As a user I want to be able to create new users and assign permissions'

The acceptance criteria talks about how the user interacts with the UI (as discussed in one of the answers in the above link - which is very logical)

For example

  • As the user clicks on the home button, system will bring up 3 options
  • And then the user can enter their user name

Is this the right approach I am using to use title for PBI and put the actual user story in description field in tfs

Thanks in advance

  • If it works for you and your team, then it can be considered a right approach. I don't think there is a 'the right approach' for writing PBIs Dec 10, 2013 at 7:31

4 Answers 4


I like utilizing acceptance criteria, but as another user mentioned, stories should be negotiable. Let's see an example of how we could change this to better fit an agile environment:

"As the user clicks on the home button, system will bring up 3 options."

This is too specific for a story as far as I'm concerned.

You (sort of) have two options.

Change it to something more like, "The user needs to be able to select between these options when they are logging in...". This way we're not directly dictating implementation. Depending on context, it's possible that this way still may be too specific.

And even then, this may be a separate story all together, depending on context: "As a user, I need to be able to select between these options, so that..."

In the end, this is up to your team and what they're comfortable with. Talk to them. Bring it up in the retrospective.


"As a user I want to be able to create new users and assign permissions"

I see at least two different stories in this statement:

  1. As a user, I want to be able to create new users (and default permissions are assigned to these users)

  2. A user can assign permissions to other users.

Small stories that add value to the product make for simpler story definition and more predictable development. For the acceptance criteria of a story, I personally use scenarios in the typical "given-when-then" form - for example, one scenario for the first story:

Given a user logged in the system (you can use "personas" instead of "a user"),

when the user enters the name and password of the new user,

and sends the request to create a new user,

then the new user is created,

and this new user can login into the system.

You can have other scenarios - for example, one more for dealing with duplicate names, another for weak passwords - probably you would also want to implement some kind of captcha or similar human detection stuff...

If you mix the user creation with the permissions assignment you will probably end up with a very big story. IMHO the most difficult part of writing good user stories is not writing the most accurate acceptance criteria, it's learning to define really small stories that add some value to the product. With stories that are all small, it's simpler and easier - I learned this the hard way...


It is one possible way, but strictly speaking there is not need for acceptance criteria as a story should be negotiable.

In other words, what constitutes a correct implementation of a story should be decided while it's being developed and not before.

That said, there could be some basic criteria that you might expect to see in a correct story, keeping in mind that stories are about "aims" and not "specs".

"A user can create another user" is a good candidate. "A user can set permissions for a user he created" is another good one. "As the user clicks on the home button, system will bring up 3 options" is not a good example of an acceptance test. It prescribes an interaction in advance.

  • If you don't know what you're being asked to develop, how can you estimate it? The acceptance criteria could cover all kinds of complexities, and you can't just negotiate away business requirements. Sep 26, 2014 at 18:47
  • You can estimate it, but not in days. The only estimation necessary (in Scrum, that is), is how many and which stories will fit in the next iteration. It's pretty easy to tell whether something will fit or not based on previous examples.
    – Sklivvz
    Sep 26, 2014 at 22:37

yes this is a right approach and you can add additional information e.g. like performance parameters, usability etc.

basically it should be clear to developers what you will use to accept the work they are doing. If you are not developer yourself or you don't know the co debase then it should be helpful if you can use some of your developers time for backlog grooming to understand what major assumptions they will make when they pick the PBI in the next iteration. and then just make those assumption part of acceptance criteria e.g. we will only support English letters etc..

  • Acceptance criteria should be driven by business requirements, not developer assumptions. If you cannot find out business requirements this just creates waste where you guess something that might be wrong, so you should try to do something else instead for which you do already know the requirements. Sep 26, 2014 at 18:49
  • i am talking about development assumptions about business requirement. Nov 6, 2014 at 20:11
  • Yes, so am I. I accept that sometimes it is necessary to make such assumptions because stakeholders are unavailable, but that is not an ideal situation which should be avoided whenever it is feasible to avoid it. Nov 7, 2014 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.