User stories are typically the customer requirements written short and simple that help to focus on one requirement. The description of a feature or work is normally written in a sentence or two that follows a template:
As a < type of user >, I want < goal > so that < reason >
User stories are often written on sticky notes or index cards and arranged on Task boards to facilitate brain-storming and planning the work. The Product Owner is the owner of the User Story, but anyone in the team can write it.
Good user stories comprise three key elements referred to as the three C’s (as proposed by Ron Jeffries):
Card, Conversation, and Confirmation.
Card – The User Story should be small enough to fit on a card (or often a Post-It note) which should capture all the necessary information still written concisely to roll out the discussion around the requirement.
Conversation – Firstly, the Product Owner discusses with the customer to understand the requirements and break them down into user stories. A user story should address one particular requirement or a problem. It will then be reviewed with the Scrum Team and the other stakeholders. If it requires further details, a more elaborate conversation can happen with the customer and can refine the user story. So, the user story written on the notecard acts as a starting point for the conversation.
Confirmation – In order to confirm the understanding and to make sure when a user story is said to fulfill all the requirements is by validating against the acceptance criteria. Acceptance Criteria must be defined listing all the conditions to be satisfied to say the user story is fit to say it is “done” in terms of requirements. In addition to this, passing tests and sign-off, etc are required to move the work item to “done” state. Also, A well-written user story and acceptance criteria confirm that the prioritised user story is ready to get added to the sprint backlog.
In agile software development, a Spike Story is a special type of user story created when there is more insight is required before starting the actual work such as researching, deciding on evaluating a technology, assessing the technical feasibility, doing a proof of concept (POC), etc. Since the approach is unclear at this stage, the spike stories cannot be estimated as like a user story. But a certain number of hours are allocated for the work during the sprint and the team would spend the allocated time only for this Spike story.
Also, Spike Stories are created for the work visibility and the output of this may eventually turn into a user story subsequent sprints. They are not direct requirements from the user, but they are required to make a decision way forward in the project development and delivery. Spike stories can be Technical Spike Stories (for technical feasibility) or Functional Spike Stories (evaluating a functionality or the usability through prototyping, wireframes, etc, and get customer or stakeholders feedback).
INVEST is an acronym coined by Bill Wake to help writing good user stories. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Independent – The user story should be written in such a way that it is not interdependent with other stories which might lead to a confusion of priortising and ordering the work. It can be developed as an independent entity.
Negotiable – User Story is not a contract. It should allow a conversation around and encourage negotiation and the scope can be revisited by the Scrum Team and stakeholders. This may happen due to scope and budgetary constraints.
Valuable – Every user story should deliver a business value to the customer. This may not be a direct feature to the customer but may work in the background indirectly, supporting another feature, etc. This will help in prioritising the work, understanding the risk factors.
Estimable – A good user story should be easily estimated (relative estimate) because it is not complex and has a well-defined scope of work. Developers can understand it easily on how to implement and can estimate the work.
Small – A user story is a smaller unit of work that focuses on delivering value. If it is complex, then it has to be broken down into another user story and should be relatively easy to estimate.
Testable – Every user story comes up with a set of acceptance criteria that defines the conditions to satisfy and so the work item can be tested and the feature is verified.
Themes are a group of user stories that share top-level objectives of the product to be delivered. Implementation of Themes span across several releases. In order to develop and deliver the Product in releases, Themes are further split into Features and User Stories which fit in Sprint scope of work. The work items are prioritised, built and delivered incrementally in Sprint cycles.
Non-functional Requirements (NFRs) in the Agile context can be defined as quality attributes of a product rather than functional behaviours. These attributes serve as constraints and they are availability, accessibility, maintainability, performance, reliability, scalability, security, usability, etc.
The Non-functional Requirements can be made visible as a Product Backlog Item. A User Story may have many Acceptance Criteria which may include some non-functional requirements. Also, we may include the NFRs in the Definition of Done.