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?

3 Answers 3


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.


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.


I agree with you about the estimation. In my company, we have a very formalized requirements process (dictated by our customer), and a lot of user stories being generated. Business Analysts like myself are writing these stories, and in many cases, we do not have the technical knowledge to realistically estimate them. For us, the estimation step occurs after a scrum team has decided to pick up a story out of the backlog. At that point, we hold a quick planning/grooming session where our tech leads and us BAs can talk about the stories we are going to work that sprint, and the devs will use "planning poker" or whatever method makes sense for a given scrum team to give a story a size estimate. I make it a point (as a BA) to NOT vote in the planning poker even though I am embedded in a scrum team.

I also agree that ACs should be part of the story before it is estimated. It is entirely possible for a developer to look at just the value statement and not fully see all the logical necessities that come out of it right away, and inaccurately estimate a story. To me, a story is not "done" unless it has acceptance criteria spelled out. For obvious reasons, I am also extremely careful if I ever have to touch ACs for a story "in flight" (already accepted by a team), because that is like messing with the goal posts during a football game. If I ever have to change an AC, it is with the agreement of the developer who owns that story and after carefully considering whether or not to just create a new story in the backlog (ideally, we should always do that, but we don't live in an ideal textbook-agile world).

As far as the best writing format for testing purposes, you can go either way. I find that the classic "As an X, I need Y, so that I can Z" works best because it is instantly comprehensible to any team member or stakeholder who comes across it. If you write it correctly, it should always be pretty easy to derive test cases. Very often, as I am writing a user story, I find myself thinking "how would I test this?". I also find it very informative as a requirements guy to go find our testers and pick their brains whenever I can. It turns out that they often have a different view of our application than a BA does, and "thinking like a tester" helps us close the logic loop when writing a good user story.

We have peer-reviews of user stories among the BAs on my project, which I think is good practice, and we end up having a pretty darn standardized way we write them. This is a good thing for a project as large as ours because our customer (or whoever) can go through the user stories and doesn't have to grapple with multiple types of user story formats.

As far as tasks, that really is an organization-specific question. For us, tasks are most useful when multiple devs end up working on a single user story. Tasks help us keep track of what each dev is doing. Our Scrum Masters like developers to break stories into tasks because it gives them a more granular view of what is going on and helps them estimate velocity. On our project, we also track tasks by hour, but stories by point. I think that isn't 100% agile-scrum "kosher", but it helps the project management team. Really, what you do or don't do with tasks is very dependent on what you are trying to keep track of, how you want to do that, and how you are organized.

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.