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?
Best Answer
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.