How to Use Wireframes with User Stories

How to Use Wireframes with User Stories?

6-7 minutes

A user story is a lightweight method for quickly capturing the “who”, “what” and “why” of a product requirement. In simple terms, user stories are stated ideas of requirements that express what users need. User stories are brief, with each element often containing fewer than 10 or 15 words each. User stories are “to-do” lists that help you determine the steps along the project’s path. They help ensure that your process, as well as the resulting product, will meet your requirements.

When getting started with writing user stories, a template can help ensure that you don’t inadvertently start writing technical tasks:

User Story Template

User stories only capture the essential elements of a requirement:

• Who it is for?
• What it expects from the system?
• Why it is important (optional?)?

Here is a simple format of user story used by 70% of practitioners:

• Role – The user should be an actual human who interacts with the system.
• Be as specific as possible
• The development team is NOT a user

Action – The behavior of the system should be written as an action.

• Usually unique for each User Story
• The “system” is implied and does not get written in the story
• Active voice, not passive voice (“I can be notified”)

Benefits – The benefit should be a real-world result that is non-functional or external to the system.

• Many stories may share the same benefit statement.
• The benefit may be for other users or customers, not just for the user in the story.

Detailing User Stories

Ron Jeffries, another of the creators of XP, described what has become our favorite way to think about user stories. A User Story has three primary components, each of which begin with the letter ‘C’: Card, Conversation, and Confirmation to describe the three elements of a user story. Where:

A user story is defined incrementally, in three stages:

• The brief description of the need
• The conversations that happen during backlog grooming and iteration planning to solidify the details
• The tests that confirm the story’s satisfactory completion

And these, although, are known as the 3C’s – Card, Conversation and Confirmation. We will talk more about this later on in this user story guide.

Card

Card represents 2-3 sentences used to describe the intent of the story that can be considered as an invitation to conversation. The card serves as a memorable token, which summarizes intent and represents a more detailed requirement, whose details remain to be determined.

You don’t have to have all of the Product Backlog Items written out perfectly “up front”, before you bring them to the team. It acknowledges that the customer and the team will be discovering the underlying business/system needed as they are working on it. This discovery occurs through conversation and collaboration around user stories. The Card is usually follows the format similar to the one below:

As a ( role ) of the product, I can (do action ) so that I can obtain (some benefits / value)

Note: The written text, the invitation to a conversation, must address the “ who (role) “,“ what (action) ” and “ why (benefits) ” of the story.