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

As an administrator I can put the system in maintenance mode so I can safely upgrade the database without corruption.

Log in as a user with administrator role.

Navigate to the admin console.

Click on the [switch ON maintenance mode] button.

Log out and log back in as a non-admin user.

The system shows the
“System Maintenance” screen (another story – a placeholder is OK if the other story is not yet completed) and the user can't do anything.

Log out and log back in as the admin user.

Click on the [switch OFF maintenance mode] button.

Log out and log in as a non-admin user.

No “System Maintenance” screen is shown.

As a developer I have access to automatic and on-demand continuous integration builds.

(a programmer will accept this story).

A programmer makes a minor change to a file (that will be seen by a user, e.g. add an HTML comment to a JSP) and checks it into source code control.

They access the continuous integration build server, navigate to the project and watch it. Within half an hour, the change is automatically detected and a build of the project occurs.  The automated build deploys the change to the development server where it can be verified.

The programmer reverses the change to the file they made earlier and checks it in. Instead of waiting for the automated build to occur they start a build immediately on the build server and verify it has been deployed to the development server (the change is no longer present).

As a user my login is recorded in an audit trail.

A user logs in.

A new row is created in the Audit table in the database to show the username, date/time, and IP address of the access.

(Quality Assurance: A member of the programming team will show you how to view the resulting record in the database).

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.

blog comments powered by Disqus