Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In the great book User Stories Applied the author specified the following process for trawling requirements in the form of user stories:

Create user roles (personas) --> brainstorm user goals for each role --> Write user stories -->
estimate all user stories --> prioritizes stories --> select some user stories for the first release -->
write acceptance criteria for each story --> divide each story into tasks --> estimate tasks

However, I don't get why ALL stories should be estimated first and if they need to be estimated why leave the acceptance criteria out of the story till it's time to work on it?

Next thing is about the acceptance criteria itself, in the book acceptance criteria where simple statements as:

  • test with Master Card for payment.
  • test with Visa for payment.

Isn't the Given... When... Then... format better for writing acceptance tests?

Last thing is about breaking user stories to tasks, why bother re-estimating the tasks when the task itself was estimated in story point?

share|improve this question

I think the point of the initial estimate is to get everyone to agree on (at a high-level) the order of complexity involved in implementing the Story. This should help with Story prioritization.

When our team made the switch to Agile there was a lot of debate around how to write AC.

What we eventually concluded is that both "test with master Card for payment" and "Given... When... Then..." formats had their merits. The former is obviously easier to write because it is in a natural language. The latter is more precise because it explicitly sets up prerequisites, actions, and expectations.

We found that, for the sake of speed, AC were initially written in a natural language. If after this there is still an element of ambiguity then they get translated to the formal format. Also, if an AC is destined to be coded as an automated test, then it should be in the formal format.

Regarding the breakdown of stories into tasks: We also followed that advice for a bit, but found it to be needless overhead.

share|improve this answer

Accurately estimating a story is work (not much, but it adds up). An accurate estimate has no direct value for the customer. So estimate only as much (and as accurately) as you need for planning.

Long term, you can get away with 'small/medium/large'. Do that. Taking time to go through acceptance criterial, tests, tasking or spike for accurate estimation is a waste of time if you aren't going to work on the story for two month - by the time you revisit that story chances are that content, context or knowledge has changed.

In a sprint/iteration, you need fairly accurate estimates. Tasking and detail AC (in whatever format the team likes best) is worth the additional effort.

I think the idea to estimate the story (gross estimate) and then the task separately (fine grained estimate) walks you through the process of refining the estimates as you need them.

Also, 'Given...When...Then' has merits, as well as 'As foo, I want to...' and 'just make it work, we all know what we're talking about'. For me, there is not one format - it depends on the story and the context.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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