The real answer to asking the right questions is simple: Keep asking. In the end, the right questions are those that get you relevant information! -Steve Blais

Have you ever wondered why user stories and wireframes are important?

The user requirements are shaped in user stories with ‘Persona” and “Acceptance Criteria.”

Unless our words, concepts, and ideas are hooked onto an image, they will go in one ear, sail through the brain, and go out the other ear. Words are processed by our short term memory and images are stored in our long term memory. – Dr. Lynell Burmark

Wireframe design is not just how it will look. The design shows how it will work.

USER STORY

• A user story is a requirement for any functionality or feature which is used to describe the functionality of the product from a user’s perspective. It’s usually written separately for each functionality. They help in defining the entire product — as a set of solid, wisely-prioritized stories.
  E.g. There will be separate user stories for search (for a theatre/movie) and book tickets in an app to book and buy movie tickets.
• A user story should be written in a very simple and concise language in the active voice. User stories describe a piece of functionality with no technicalities and implementation details. User stories are contemplated as a standard way of communication to summarize the functionality of the product by both technical and non-technical members as they are easy to define, understand, and revise.
  Generally, the user story follows such a template:

          As a <type of user>, I want <some feature> so that <some reason>

          Breaking this down further:

          As a <type of user> — this is the WHO. Who is the user?

          I want <some feature> — this is the WHAT. What is the intention?

          so that <some reason> — this is the WHY. Why are we building it?

• The product development team can define the superset of user stories, and then assign priorities (which reflect the expected value for the user, complexity, dependencies and other business priorities).
• For the stories which do not reflect the core functionality, one can assign a lower priority instead of flagging them “out of scope.”
• Epics are groupings/containers of related, smaller stories, all serving a common goal. Epics can take the form of higher-level stories, which describe large pieces of functionality.
  E.g. Manage Bookings, Manage Users, etc.
• Each user story can be kept small by splitting it into multiple user stories, improves the chances of delivering it early, seeking feedback faster, hence reduces risk.
• The client and the team should be on the same page about goals of product/app development and ways of achieving these goals to avoid miscommunication.
• The user stories are aimed at:

1. Delivering a product that the client needs.
2. Budget estimation
3. Time estimation
4. Saving time on coding and giving clear tasks to developers
5. UI design

ACCEPTANCE CRITERIA

• Acceptance criteria are a formalized list of requirements that ensure that all user stories are completed and all scenarios are taken into account while development. In simple words, acceptance criteria specify conditions under which a user story is fulfilled. So acceptance criteria are a part of a user story. Concisely written criteria help development teams avoid ambiguity about a client’s demands and prevent miscommunication.
• Acceptance Criteria defines how a particular feature could be used from an end user’s perspective. It focuses on business value, establishes the boundary of the feature’s scope and guides development. These are unique to a user story and form the basis of user story acceptance testing which establishes the conditions for the success of the feature.
• Acceptance criteria could establish a boundary that helps team members to understand what’s included and what’s excluded from the scope of the user story. The criterion of user story acceptance not only informs the product behavior in happy path scenarios, but it also guides the user experience when things don’t work as intended. When the product owner verifies particular user story acceptance criteria and the developed feature passes it, the development of the user story is considered a success. Pass / fail type results allow Acceptance Criteria to form the basis of creating tests that can be automated and executed.

Importance of Acceptance Criteria

• To reach consensus.  Acceptance criteria synchronize the development team with the client. The team knows exactly what conditions should be met.
• To serve as a basis for tests: Acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected and the user story is completed.
• To allow for accurate planning and estimation. Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned.

Who writes Acceptance Criteria?

• Either a client or a development team write acceptance criteria.
• As a rule, criteria written by a product owner (the client) are reviewed by a member of the development team to make sure that the criteria are specified and that there are no technical constraints or inconsistencies from the development perspective.
• Such flow is an excellent way to collaborate if a product owner has some experience in software development and is aware of how to write project documentation.
• If one prefers to assign writing acceptance criteria to the development team, then a requirements analyst, project manager or QA specialist should deal with this task, since they know the technology stack and the feasibility of features.

Tips for Writing Acceptance Criteria:

1. Each user story should have at least one acceptance criteria.
2. Each acceptance criterion should be such that it is independently testable.
3. Acceptance criteria must have a clear Pass / Fail result. Each criterion should be concise, unambiguous and well-defined.
4. Team members should write acceptance criteria and the Product Owner should verify it. This confirms that the team and Product Owner have a similar understanding of product functionality.
5. Keep the criteria realistic and achievable. Acceptance criteria should allow the person to estimate the development time and define the minimum piece of functionality that is possible to deliver in a particular time frame.

• Consider a scenario where the user should be able to search on the webpage. The user story and the acceptance criteria are:

          As a website user

          I want to be able to search on the webpage

          So that I can find the necessary information

• Acceptance criteria:

1. The user searches for an item by its name on the “Products” page.
2. Displays a list of all products.
3. The “Search” section in the top right corner of the screen.
4. The “Search” field to enter the name of an existing item in the product list
5. The “Apply” button
6. Displays products in the Search Results section with product names matching the entered product name.
7. Number of search results at the top of the Search Results section.

• Thus, writing acceptance criteria is truly a win-win activity for both clients and development teams: Not only does it help the team know exactly what they have to do, but it keeps the client abreast of the development process and lets them check that developed software meets actual business requirements.
• Also, Acceptance criteria serve as a basis for use cases and test cases that ensure one to achieve business goals and to produce bug-free apps.

WIREFRAME

• Wireframes can be defined as an image or a set of images which displays the functional elements of a website, app or a product, typically used for planning a structure and functionality.
• It is a practice used by UX designers which allows them to define and plan the information hierarchy of their design for a website, app, or product.
• Creating the pages before finalizing the design is also a great way of getting to know how a user interacts with the interface, through the positioning of buttons and menus on the diagrams.
• Wireframes act as a grid that the web designer places on a web page in the planning phase to define in which grid square different elements are located.
• Wireframes are simple black and white layouts that outline the specific size and placement of page elements, site features, conversion areas and navigation for the website.
• This allows clients (and other team members) to provide feedback earlier in the process.
• They are devoid of color, font choices, logos or any real design elements that take away from purely focusing on a site’s structure.
• We often say that they are much like a blueprint to a home, where one can easily see the structural placement of plumbing, electrical and other structural elements without any interior design treatments.