Some projects have a policy where only user interface functionality that can be seen on a screen is eligible for promotion to user story status, the rest are just tasks and don't even make their way onto the task board.
Does this mean a two year integration project without screens can't use Stories to define work? Not at all. Perhaps there is confusion around the word “User” in User Story so stick to “Story” on its own.
Every project activity has acceptance criteria that can be a written as a story that most will understand. Acceptance criteria for a task might be just for programmers to verify, but every piece of work needs some very clear acceptance criteria to be able to prove it has been done.
Some examples of stories and acceptance criteria:
Acceptance Criteria don't need to follow strict conventions as long as it specifies in plain language how the programmer or tester will know the task is complete.
Tip: Keep Acceptance Criteria very specific to remove dependencies on common functionality. For example, if a project requires auditing of all user activities, deliberately exclude the audit requirement from screen stories so they can be delivered on their own before the audit module is ready. Create a new story or stories that cover the auditing for the screen. Stakeholders will be interested in early progress on the screens so auditing won't be high priority. The screen story can state that it will be accepted even if auditing isn't yet delivered, but the audit story should then state that auditing must work for that specific screen.
Trap: Don't repeat common information like maximum field lengths or how validation or error messages are displayed in every Story. This kind of thing changes easily and is usually managed in one place in the code so it makes the stories cumbersome when repeated. Move it into a separate story or even to a Wiki page. It is okay to explain in acceptance criteria that a story should match the common validation rules shown on a wiki page, or should match a chapter in a version of a functional specification (provided the reference document isn't still changing). Do not say “this story will match section 4.6 of our 175 page requirements document” - extract it out if you must.
Simple things don't always need to be qualified so use good judgement on the level of detail in a story or if it even needs to be a story at all. For example, simple text changes on a screen that the developers already know might be done just by looking over someone's shoulder. They might not care why marketing have decided to change the text.
Tip: If Acceptance Criteria can't be identified for a task or story, consider if it should be done at all. It's like saying “I want you to complete this task, but I can't work out how to tell it has been finished. In fact, you can bet when I first see your work, I will not be happy and ask for changes”. Such a story creates delay.
