User Story - at business rule / field validation level.

Last post 02:27 pm July 1, 2016
by Michael Kogan
7 replies
12:46 pm June 27, 2016


I wanted to know if any standard is or should be followed for writing User Stories. I have seen Stories varying from being at business rule, to a field validation rule, to output delivered as a result of user action, to usability related.

Would like to know if others follow any standard.


10:15 am June 28, 2016

From my experience the User Story itself should be quite simple. It should reflect the reason and intention of solution. What makes difference is the additions to User Story in my opinion and here I find 2 which makes sense to me.
1. Scenarios
Describe what should happen. I cannot even tell how many weak points of solution were found quickly while trying to define the exact scenario. I use gherkin syntax to write scenarios. If the agile project management tool gives you syntax higlighting you have another win.
If you find BDD topics interesting you win another time :)
2. Acceptance criteria
You can specify almost everything in scenarios. If you find it too long to write all scenarios in front of the rest of the team, use additional Acceptance Criteria.
I'd recommend to specify many items here including validation rules, output etc.
I try to make sure that team will know 'how to test' the story.

Of course giving examples can make things much easier for the team to implement. It is better to specify sample title of the email, color palette etc. if possible.
Not everything has to be given when planning, some details can be delivered later - in last responsible moment :)

08:29 am June 29, 2016

Not every detail can be specified/detailed as part of the user story.

So my question is - as project team learns/discovers more about a particular story(requirement) - additional details like field level validations/business - where should these be captured and documented? These details also help enhance the acceptance criteria/testing conditions applicable against the story before same can be marked as "done".

10:14 am June 29, 2016

An user story should be non technical and independent, and for sure written from the users eyes.

That is captured or is doing on refinement / grooming process, as you said you can get more details of backlog, remember that the PO is the owner of PBL, and the team can modify the sprint backlog at any time.

You should use the standard for uses story

I as <user> I want to <do....> so the benefit <...>

Considers the 3Cs (card, communicated and confirm) and INVEST for get more clear backlog.

The backlog is in continues changing.

The best,

11:05 am June 29, 2016

A User Story has 3 parts: Card, Conversation, and Confirmation.

Which part or parts do you think would be most appropriate for capturing the field-level validations and business rules you describe?

01:34 pm June 29, 2016

Business Rules/Field level validation are best suited for "Conversation" part of the user story!

Common understanding of "Definition of Ready" should support the level of details including conversation and confirmation be captured /available for each PBI/User story!

03:05 pm June 29, 2016

Yes are part of the story, but keep it simple as standar mentioned above, and the acceptance criteria encompass its.

And for your second part of the discussion, for me is not, remember one agile value "working software over compressive documentation", and the right way to create story and developed the product backlog, that is not documentation, the story need to cre written as a user or client eyes.


02:27 pm July 1, 2016

Hi Ashish,

there are several criteria to a good US:
1. It should have a DoD
2. It should follow the "CCC" rule:
Card: the description should be short enough to fit on an index card. The description should be documented.
Conversation: there should be conversation between the PO and the team where PO details the requirements. No need to document.
Confirmation: description (by the team) of what they are going to present to the PO at the review meeting at the end of the sprint. This should be documented.
3. It should satisfy the INVEST criteria (see

Hope this helps,