I wanted to start this blog with a topic that I am passionate about and that is user stories. Scrum User Stories - A Key Communication Tool-1.jpgWhen practicing Agile, there is a very specific format for user story construction and that is:

As a... ROLE   I want... FEATURE   so that... BUSINESS VALUE

What is a user story? First and foremost it is a communication technique. It is the start of a conversation. User stories should never dictate code or coding methodologies. These are for the development team to determine. User stories replace requirements in former methods. But unlike requirements, a user story always keeps the end user and the business value clearly in the forefront. Because of this, we continuously consider the business value as we review the user story. And finally, as a communication technique, the user story acts as a placeholder to engender further conversation.

On a broader note, all team members benefit by the standardized format:

Product Owner 

A consistent structure helps the Product Owner prioritize. The Product Owner needs this structure to ensure the business value is always visible to both themselves and the team. Most of the issues I see on a regular basis are either improper identification of the business value or a lack of the business value altogether.

Development Team

A consistent structure helps the development team by presenting a familiar interface. They understand the expectations and know how to accomplish a “done” status.


A consistent structure helps the testing team ensure they have completed their testing. By presenting the Acceptance Criteria, the testers have a roadmap to build their test scripts. With all of the above in mind, I took a relook at some of the user stories I've seen in the past. All in all, most user stories are on the right track but they need a little nudging to get them in alignment. Review the user stories in your backlog and watch out for a few things.


Conjunctions specifically in the Feature section or the Business Value section will probably lead to dividing the user stories into multiple user stories. It would be difficult to prioritze a user story if multiple business values are listed. What if you have conflicting priorities in the same user story?


Who is the real beneficiary of the value? I'm finding a lot of stories that are listing the "Developer" or the "Product Owner" as the Role for the story. I can assure you that these two users should seldom be the Role in the user story. Examples of this are rare.

Extended Conversations

If the role and the business value are vague, the user story will probably lead to more confusion or an inability to understand the deliverable than is necessary. If you find your development team asking a lot of questions and revisiting items they covered in former discussions, take a look at the story.

Unstable Velocity

If you have difficulties sizing stories properly this will adversely affect your velocity. And sizing stories properly will include understanding exactly who the user is and the value to the business.

In my next blog I'll discuss some user story Dos and Don'ts.