INVEST in good user stories

C2 General
An INVEST-able
User Story
evolves
through the
journey of a
Sprint.

C2 General
To elucidate this further, I would like to take an example from a real-life scenario and track the evolution of a User
Story during the journey of a Sprint and present it from the perspective of an Agile Team Member.
Consider the user requirement as below -
“The e-commerce website processes huge amounts of payments daily through their checkout process. The business
user from the marketing requires an urgent “One-click Payment” feature to be implemented within the check-out
process that would immensely simplify the experience of the customers to complete their order faster, thereby
increasing customer delight and reducing the overall cart abandonment rate.”
User summarizes, “We need to urgently integrate a ‘One-click Payment’ facility within our Checkout process!”
A User Story must aim to have the following facets:
• User Story Template
• Acceptance Criteria
• Conversation
• Sub-tasks
Credits:https://capgemini.github.io/agile/invest-in-user-stories/

C2 General Credits : https://masteringbusinessanalysis.com/user-stories-are-you-ready/

C2 General
User Story
Template
A User Story is a short and simple description of a feature (the
“what”) told from the perspective of the person who desires the new
capability(the “who”), usually the customer of the system.
The User Story must be told from the perspective of the area of the
business that is responsiblefor managing the efficiency and
effectiveness of the customer-facing business of the system.
Additionally,a User Story must clearly list the direct “benefit” or
“value” that the customer or the user will enjoy (the “why”), once the
User Story is successfully delivered.
Finally,a well-written User Story must alwaysanswer the question: “Is
the User Story INVEST-able?”
This INVESTmnemonic for agile software projects was created by Bill
Wake in his originalarticle, INVESTin Good Stories, and SMART Tasks.

C2 General
Example template of a User Story:
• As a… <”CUSTOMER” or “USER” who directly benefits
from the successful delivery of this User Story>
• I want to… <perform a “FEATURE” specified in the
User Story>
• So that… <”BENEFIT” / “VALUE” that the customer or
user will enjoy on the successful delivery of this User
Story>

C2 General
Let us write the user requirement, following the template of a User Story:
“As an XYZ customerorderingusing the website,I want to be able to use the One-click
Paymentoption,so that I can skip the payment pages and completemy order faster”
Is the above User Story INVEST-able?The simple answer: NO!
This User Story leaves several questions unanswered:
• Type of Customers: Is this feature available to all new and existing customers?
• New Customers: What should be the workflow for a new customer after the One-
click Payment option has gone live?
• First Visit of Existing Customers without saved card details: What should be the
workflow of an existing customer who has not saved any card details and visits for
the first time after the One-click Payment option has gone live?
• First Visit of Existing Customers with saved card details: What should be the
workflow of an existing customer who has already saved their card details and visits
for the first time after the One-click Payment option has gone live?
• Existing Customers not opted for One-click Payment: What should be the workflow
of an existing customer who has not opted to register for the One-click Payment in
their previous visit after the feature has gone live?
• Existing One-click Payment Customers: What should be the workflow of an existing
customer who has successfully registered their card for the One-click Payment in
their previous visit?

C2 General
Let us assume that the ExistingOne-click Payment Customers use-case received the
below answers from the user:
• Customers must be presented with a “Buy Now with 1-click” buttonon the
Checkout Screen (where the Checkout Screen is any section that can act as the
startof a checkout process).
• Clicking on the button must skip the Paymentscreens and the customer must be
presented with the Order Confirmation screen directly.
Based on the above answers, let us rewrite the User Story:
“As an EXISTING ONE-CLICKPAYMENT XYZ CUSTOMER orderingfrom the website, I
want to be able to CLICK ON THE ONE-CLICKPAYMENTOPTION so that I canskip the
payment pagesand completemy order faster”
The above User Story is Independent as this feature can be developed and
delivered independently after the First Visitof ExistingCustomers use cases have
been done.

C2 General
The above User Story is Negotiable as this feature can incorporate changes if
required.
Let us look at this scenario in our case study:
As always, the business user comes to our Product Owner (PO) once the Sprint
has commenced and says,
“Whoops! I justgot the numbersin from my market research teams and it highlightsthe
fact that 55% of our customersare using their mobiles and tablets(30% of those are
Apple device users).Since we are already addingthe featurefor our web users, could we
increasethe scopeof the delivery of this featurejust a teeny-weenybit so that this is
available not only to our web but also to our Apple and Android tabletand mobile apps
users as a priority?Later maybe we couldmake this facility available to our Windows
app users since that’snot much of a priority as of right now!”
In such a scenario, is the above User Story Negotiable? Yes!
I would negotiate the User Story by breaking it down further as listed next -

C2 General
• As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the WEB using a DESKTOP
OR LAPTOP, I want to be able to CLICK ON THE ONE-CLICK PAYMENT OPTION so that I can skip
the paymentpagesand completemy order faster
• As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the WEB using an APPLE
TABLET OR MOBILE, I want to be able to CLICK ON THE ONE-CLICK PAYMENT OPTION so that I can
skip the paymentpagesand complete my order faster
• As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the WEB using an ANDROID
TABLET OR MOBILE, I want to be able to CLICK ON THE ONE-CLICK PAYMENT OPTION so that I can
skip the paymentpagesand complete my order faster
• As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the MOBILE APP using
an APPLE TABLET OR MOBILE, I want to be able to CLICK ON THE ONE-CLICK PAYMENT OPTION so
that I can skip the paymentpagesand complete my order faster
• As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the MOBILE APP using
an ANDROID TABLET OR MOBILE, I want to be able to CLICK ON THE ONE-CLICK PAYMENT
OPTION so that I can skip the paymentpagesand complete my order faster
The priority of which deliverables need to be included in the current Sprint and which
can be excluded can then be negotiated with the business user by the PO as a
“Minimum Viable Product” (MVP).

C2 General
The above User Story is obviously Valuable as the value / benefit
has been clearly stated.
Each of the above User Story is easily Estimable as we have now
broken it down to an independent, negotiable, valuable, small
and testable MVP.
The User Story is Small enough to be “done” within a Sprint.
The User Story is Testable as it is small enough to be developed
and tested within a Sprint.

C2 General
2.
Acceptance
Criteria
The quality of deliverables increase immensely, when all Acceptance Criteria
is written in a combination of Given-When-Then and checklist formats.
A Behavior-Driven Development (BDD) approach follows a “Given-When-
Then” format to help break the behavior of the system down to an agreed
and specific flow.
According to behaviourdriven.org, BDD relies on the use of a very specific
(and small) vocabulary to minimize miscommunication and to ensure that
everyone – the business, developers, testers, analysts and managers – are
not only on the same page but using the same words.
Hence, using the BDD approach ensures that everyone involved with the
User Story has a consistent understanding of what is expected to be
delivered of the new functionality that would be built from tests that satisfy
the Acceptance Criteria.
Use a Given-When-Then format for a one-to-one mapping of acceptance
tests that must be met and tested against.

C2 General
Acceptance
Criteria …
Use a Given-When-Then format for a one-to-onemapping
of acceptance tests that must be met and tested against.
Given: An existing scenario
When: I perform some action
Then: I expect a specific result
Use a checklist format for a scenario where an acceptance
test satisfies multiple Acceptance Criteria checklist items.

C2 General
After discussions with the Team Members, our PO has now negotiated with the
business user that in this Sprint, the team would commit to deliver the web version of
the User Story.
So let us write Acceptance Criteria specifically for those user stories.
“As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the WEB using
a DESKTOP or a LAPTOP, I want to be able to CLICK ON THE ONE-CLICK PAYMENT
OPTION so that I can skip the payment pages and complete my order faster”
Acceptance Criteria:
Given: An EXISTING ONE-CLICK PAYMENT WEB XYZ Customer, When: The Customer
orders through the website and clicks on Checkout using a desktop or a
laptop, Then: The Customer must be presented with a One-click Payment button.
Checklists: This test must pass when tested on:
• Approved versions of IE browsers
• Approved versions of Chrome browsers
Given: An EXISTING ONE-CLICK PAYMENT WEB XYZ Customer, When: The Customer
clicks on the One-click Payment button using a desktop or a laptop, Then: The
Customer must directly be presented the Order Confirmation screen.
Checklists: This test must pass on:
• Approved versions of IE browsers
• Approved versions of Chrome browsers

C2 General
“As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from
the WEB using an APPLE TABLET OR MOBILE, I want to be able to CLICK ON
THE ONE-CLICK PAYMENT OPTION so that I can skip the payment pages and
complete my order faster”
Given: An EXISTING ONE-CLICK PAYMENT WEB XYZ Customer, When: The
Customer orders through the website and clicks on Checkout using an
Apple device, Then: The Customer must be presented with a One-click
Payment button
• Approved list of Apple mobiles
• Approved list of Apple tablets
Customer clicks on the One-click Payment button using an Apple
device, Then: The Customer must directly be presented the Order
Confirmation screen
• Approved list of Apple mobiles
• Approved list of Apple tablets

C2 General
“As an EXISTING ONE-CLICK PAYMENT XYZ CUSTOMER ordering from the WEB using
an ANDROID TABLET OR MOBILE, I want to be able to CLICK ON THE ONE-CLICK
PAYMENT OPTION so that I can skip the payment pages and complete my order faster”
Customer orders through the website and clicks on Checkout using an Android
device, Then: The Customer must be presented with a One-click Payment button
• Approved list of Android mobiles
• Approved list of Android tablets
Customer clicks on the One-click Payment button using an Android
device, Then: The Customer must directly be presented the Order Confirmation
screen
• Approved list of Android mobiles
• Approved list of Android tablets

C2 General
Conversation
This section of the User Story summarizes all important and relevant email discussions,
code discussions, visual representations / diagrams, screen grabs, test results, et al. that
have occurred during the uncovering of the User Story and recorded either as comments
and / or attachments.
Use this section to record a summary of what discussions and actions have occurred on
this User Story during its journey through the Sprint.

C2 General Credits:https://capgemini.github.io/agile/invest-in-user-stories/

C2 General
Continuing with our case study, after the delivery of the User Story in the Sprint, it is time for the team’s
Retrospective.
Let us refer to the “Conversation” of the User Story to record the team’s Retrospective points:
Conversation:
Created this User Story as a part of a change agreed by the PO with the business user after the Sprint had
commenced.
Team had to spend a time-boxed amount of time in re-planning and re-estimating the story.
Work on this story commenced 3 days into the Sprint and delivery has been agreed to the Web platforms
only.
Why invest precious time on a Conversation?
1. To decipher the actual “complexity” of the User Story
2. To empower the team or any other team working on a similar User Story to make better and more
accurate estimations
3. To save any time that might be spent on potential rework
4. To act as documentation on the feature delivered
5. To act as a tool to take corrective measures mid-Sprint rather than render the story as not done at the
end of the Sprint

C2 General Credits : https://www.prince2primer.com/using-user-stories-with-prince2-part-2/

INVEST in good user stories

More Related Content

Similar to INVEST in good user stories

Recently uploaded

INVEST in good user stories