How to Use Wireframes with User Stories?

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.

  

Conversation

Conversation represents a discussion between the target users, team, product owner, and other stakeholders, which is necessary to determine the more detailed behavior required to implement the intent. In other words, the card also represents a “promise for a conversation” about the intent.

• The collaborative conversation facilitated by the Product Owner which involves all stakeholders and the team.
• The conversation is where the real value of the story lies and the written Card should be adjusted to reflect the current shared understanding of this conversation.
• This conversation is mostly verbal but most often supported by documentation and ideally automated tests of various sorts (e.g. Acceptance Tests).

  

Confirmation

Confirmation represents the Acceptance Test, which is how the customer or product owner will confirm that the story has been implemented to their satisfaction. In other words, Confirmation represents the conditions of satisfaction that will be applied to determine whether or not the story fulfills the intent as well as the more detailed requirements.

• The Product Owner must confirm that the story is complete before it can be considered “done”
• The team and the Product Owner check the “doneness” of each story in light of the Team’s current definition of “done”
• Specific acceptance criteria that is different from the current definition of “done” can be established for individual stories, but the current criteria must be well understood and agreed to by the Team. All associated acceptance tests should be in a passing state.

  

How to Incorporate Wireframes with Use User Story Scenarios

A scenario is a narrative, which describes how a user might interact with a website or software application which focuses on users’ needs rather than the technological aspects of design. It allows us to explore the user interaction in more detail, to describe the necessary steps and their relationship. It important as these enable usability experts and developers to get into the mindset of potential users. Another benefit of user scenarios is that they are written in a language that all team members should understand, regardless of specialism.

Roman Pichler (a leading scrum expert) suggested that, we can derive stories from a scenario, and we can also use a scenario to illustrate the relationship between different stories. The following diagram illustrates the three options:

In Visual Paradigm, you can use the Conversation Part of the user story to refine into narrative steps to be stored under user story scenarios as suggested in option one above. By this way, you can attach wireframes to each of the steps for UX planning and design. After you finished with the scenario and wireframes, you can output wireframe storyboard slide show and as well as use case report embedded with wireframe design in the specification.