Example story:

As a player, I want to buy weapons from merchants, so that I can progress further

The other parts of the story could have acceptance criteria such as "There is a gun merchant in town" and "The gun merchant can buy and sell weapons". But the problem is with writing down acceptance criteria for the prices of the weapons.

Now the acceptance criteria could be:

  1. "Find right values for weapon costs" OR
  2. "Weapon costs are decided"

The first one seems way too vague to use. But the second one makes the story result seem final. Without going on a spike "To find values for weapon costs", how could the acceptance criteria for the weapon costs be defined for a story like this? When the story includes acceptance criteria that is likely to change and is not absolute.

  • 1
    I have not come across this usage of the term Acceptance Criteria before. In my experience and in relation to Project Management, Acceptance Criteria are the measures or tests that must be "passed" for the project to be considered a success. Conversely, failure to meet an Acceptance Criterion will automatically define the project as a failure. What you are discussing here are functional requirements as far as I can see. – Marv Mills Feb 23 '15 at 14:07
  • 1
    The story is poorly defined, "progress" is an ill-defined non-functional requirement in your story, and acceptance criteria should be about verifying correctness of an implementation rather than a vision statement of some sort. --What is your role here? It seems unlikely that you are the Scrum Master; what does your Scrum Master or Product Owner have to say about your issue? – Todd A. Jacobs Feb 23 '15 at 18:56
  • @MarvMills There seems to be many names for the conditions that have to be met in a user story for it to be considered done. 1. boost.co.nz/blog/2010/09/acceptance-criteria 2. scrummethodology.com/scrum-acceptance-criteria 3. mountaingoatsoftware.com/blog/… – Esa Feb 25 '15 at 11:23
  • @CodeGnome How would you suggest adding a acceptance criteria to stories which is not definitive. E.g "The user can tick remember me checkbox to save account credentials" is very definitive, you know when it is done. But for example balancing item costs in a game is very iterative. – Esa Feb 25 '15 at 11:26

Improve Stories to Make Features Testable

The stories as you've posted them violate the INVEST criteria. In particular, your stories lack testability. If you had testable stories you'd have self-evident, testable acceptance criteria for each story. Consider the following example:

As a level 4 character
I need to be able to do 48 hit points of damage per second
so that I can successfully fight the 4th level boss.

You now have a meaningful feature to work towards. This feature suggests two obvious tests, and a lot of inferable tests. For example:

  1. You can test the level 4 character stats against a defined target (whatever is required to deliver 48 damage per second) to see if your character-progression curve is balanced.
  2. You can test whether the level 4 character has been able to amass enough money to buy weapons that can do at least 48 hit points of damage per second.
  3. You can test whether the money/cost system for weapons is sufficiently balanced.
  4. You can test whether the 4th level boss is statistically beatable by a 4th level character outfitted with appropriate weapons.

Compare this to your story:

As a player,
I want to buy weapons from merchants,
so that I can progress further[.]

Vague stories with vague goals and unmeasurable success criteria lead to all sorts of problems, including simple definitional problems like "What does 'progress further' actually mean within the project?" Most of these problems go away with properly-written stories because you then have measurable goals, but you will still have plenty of work to do in properly defining the implementation details.


You might consider separating out the implementation from the defining of business rules.

So the team would write code that satisfies "As a player, I want to buy weapons from merchants, so that I can progress further". They write the code in such a way that the price of weapons is configurable and possibly even provide an interface for a non-technical person to set the price when needed.

Then your acceptance criteria becomes:

  1. The price of weapons is configurable
  2. The configuration is accessible to the business user that determines weapon prices
  • Thank you for you answer! Yes, this is how we currently data drive our code. But, the question is more about how to write and define an interative process in acceptance criteria. Since it could be done until kingdom come, so having a written boundary of when to stop iterating would be great. – Esa Feb 25 '15 at 11:29
  • I hear what you are saying, but I would be a little bit cautious about that approach. We want to keep stories discrete and small so that they fit easily within sprints. That is so we get clear visibility of progress (as 'done' is done). I would consider having a separate story for the optimisation process, completed in the same sprint if possible, but in a later one if not. You could make the feature hidden until the optimisation is completed, then switch it on. – Barnaby Golden Feb 25 '15 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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