Context : A team working in agile , on an complex Front end Application.

Question:How an team working in agile come up with a definition of common guiding "entry criteria" for testing to decide when user stories should be rejected right away when not meeting the basic conditions without performing any further testing.


4 Answers 4


Basic entry condition for the user story testing could be:

  • clear description
  • status that is declaring readiness from development prospective
  • remaining team iteration capacity that is enough for story testing according to the estimations given on sprint planning
  • a build that has been prepared by dev team with enabled unit tests where all the tests passed successfully

Agree on the basic conditions for criteria for all stories.

This 'meta' conversation needs to be had. It doesn't arise of its own accord, not being related to a ticket.
This is where leadership (at all levels) comes in.
Take charge of the situation, organize the meeting, get an agreement and then live by it.

The result of this is that future discussions can now be about the agreement, if its being met, if it needs to be changed, rather than trying to raise an issue about any given particular story.

Making something up, it could be:

  • initial data state required
  • user taking action
  • expected result
  • happy and sad cases


Make sure the Behavior of users is the Driver of the Development process

See also https://www.mountaingoatsoftware.com/agile/user-stories for Mike Cohn's take on user stories


So basically you are looking for Definition of Ready if I understood the question correctly.

Usually the INVEST matrix is used for this: A good user story should be:

  • “I” ndependent (of all others)
  • “N” egotiable (not a specific contract for features)
  • “V” aluable (or vertical)
  • “E” stimable (to a good approximation)
  • “S” mall (so as to fit within an iteration)
  • “T”estable (in principle, even if there isn’t a test for it yet)

There is also a good take on it by Vojtech Barta called Parallel of Rally Dakar and Agile - rediscover of DoR & DoD where he gives examples on how to start the process of defining the DoR. DoR should not be set in stone but should evolve along with the team development process.


I think if the application is complex then its complex for both the testers and the developer so i think all the team members should work as across functional so this may solve the complexity of user stories and facilitate to understand user stories .

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.