What is Agile?

Agile is the ability to create change and respond to it. It is a way to deal with an uncertain and
turbulent environment and ultimately succeed in the development process. The authors of the
Agile Manifesto chose “Agile” as the name for this whole idea because the word epitomizes
the adaptability and responsiveness to change that was so important to their approach.

What are stories, epics, initiatives and themes?

i
nt
● Theme

da
○ A theme can be considered as a large area that spans the whole
company.

Ve
○ Example- Mobile App Upgrades
● Initiate
○ An initiative represents epic collections that lead to a common goal.
○ Example- Introduce tracking enhancements to our cycling app.
by
● Epic
○ An epic is a large piece of work that is typically broken down into small
pieces (tasks known as stories).
oc

○ Example- Enhance the cycling app's GPS tracking functionality.

● Story
○ A user story (or simply – story) is a brief request or requirement
D

composed from the end users’ perspective.

○ Example- Integration of Google Maps in the cycling app.
ile
Ag
Ag
ile
D
oc
by
Ve
da
nt
i
Difference between Persona and Stakeholder
● Stakeholders are “all individuals, groups or organizations who are
involved in, influencing, affected by, or interested in, the execution or the
outcome of a project.” (Stakeholders are mostly individuals having
interest in the project outside the Scrum Team)
● Personas are highly detailed fictional characters, representative of the
majority of users.

i
nt
User Story

da
● User stories follow a simple template. The chosen user story format will
outline the “who,” “what,” and “why” of a particular requirement.

Ve
○ Who wants something?
○ What do they want?
○ Why do they want it?
● User Story Voice Template- “As [persona], I want to [action], so that I
by
can [benefit].”
● For each story, the writer will include a user persona, the action they
wish to take or the ability they wish to have, and the benefit they hope to
oc

achieve as a result.
● Are written in active voice - i.e. “ AS the end user, I am able to ...”
D

instead of “The button may be pushed by the end user.”

● Examples-
○ “As an online gamer, I want to have a multiplayer option so that I
ile

can play online with friends.”

● Making a good User Story-
Ag

○ Independent: The user story should be independent of all others.

Because they are not connected, they can be worked on in any
order.
○ Negotiable: A user story should be flexible enough to allow for
negotiation between the customer and product owner. (agreement
between the “what” and not the “how”)
○ Valuable: What value does the user story bring? If you cannot find
any value, the story should not be completed.
 ○ Estimable: You should be able to estimate how long a user story
will take so that you can effectively manage your time.
○ Small: The user story must be small enough to be completed
within a single sprint.
○ Testable: You must be able to test your user story in line with
quality assurance standards.
● Tips for Writing Effective User Stories-
○ Goal oriented - deliver value to the customer.

i
○ Contain only one viewpoint.

nt
○ Describe how functionality should work, not how it shouldn’t.
○ Have a title that accurately reflects the content of the story.

da
○ Have constraints/assumptions in the NOTES – i.e. “user must be
in sudo to execute command, Users logged in as ROOT can

Ve
perform action OR Command must be run from user directory”.
○ User Comes First- a user story describes how a customer or user
employs the product; it is told from the user’s perspective.
○ Use Personas to Discover the Right Stories- Ask yourself what
by
functionality the product should provide to meet the goals of the
personas. The goal is the benefit the persona wants to achieve, or
the problem the character wants to see solved by using the
oc

product.
○ Creating Stories Collaboratively- Derive ideas, feedback and data.
D

○ Defining Scenarios- Identify the business cases wherein the need

for requirement will exist.
○ Keep Stories Simple and Concise- Use simple language and write
ile

stories in an active voice.

○ Add Acceptance Criteria- The criteria enrich the story, they make
Ag

it testable, and they ensure that the story can be demoed or

released to the users and other stakeholders.
○ Assumptions- A condition that impacts the user story that the
team believes is true. Similar to assumptions in business
requirements.
● Actual examples of assumptions: “All systems will report
issues in the same way.”, “Provided user rights are in
scope”, “When requesting the transmission of a message,
Server communication must be present ...”
 ○ Dependencies- When the user story requires completion of
another activity in order to either begin development or achieve
functionality when deployed.
● Format/ Template
○ Summary-
● This is a short or compressed title of the requirement
○ Title-
● Consists of the User Story Voice in format: As [persona], I
want to [action], so that I can [benefit].

i
nt
○ Business Scenarios-
● Description of all the ways an end-user (personas) wants to

da
"use" a system. Business Scenarios capture all the possible
ways the user and system can interact that result in the user
achieving the goal. They also capture all the things that can go

Ve
wrong along the way that prevent the user from achieving the
goal.
● Scenarios establish the conditions of acceptation
by
● Scenarios are concrete examples that says in the words of the
stakeholders how they plan to verify the desirable outcome
● Scenarios enable the team to know when they are done.
● Scenarios are a specification as important, if not more
oc

important, than stories.

● Does-
D

● Include a specific example

● Specify what system does
● Describe the business functionality
ile

● Does Not-
● Restate business rules
Ag

● Describe how to use the system

● Describe software design
○ Business Context-
● A high level argument that attempts to articulate the reasons
for initiating a feature/ functionality/ project. It is an important
artifact for the requirements analyst because it will typically
contain information describing business value and drivers with
respect to the stakeholders.
 ○ Description-
● Details about the story that serves to flesh out the needs of
the story. Concentrates on the scope of the story.
○ Acceptance Criteria-
● Acceptance criteria are the conditions that a software product
must satisfy to be accepted by a user, customer, or, in the
case of system-level functionality, the consuming system. A
set of statements, each with a clearpass/ fail result, that can
be measured.

i
nt
● Defines the boundaries for the story.
● Describes any follow-on actions during or after the user

da
performs the activity, such as mouse-overs.
● Avoids keywords such as all, any, every, if appropriate, etc.
● Lists the individual roles, or group of roles, of those who are

Ve
able to perform the activities in the story.
● Given When That: Functional Acceptance Criteria
○ Functional Acceptance Criteria- Describes how a system should
by
behave when certain conditions are met. These requirements
include technical details, calculations, data manipulation and
processing, and other functionality that characterizes what a
framework should achieve.
oc

○ The GWT clauses are the heart of Gherkin. They provide a means
of structuring a sentence to explain the logical progression of an
D

action or event.
○ Given (an initial context)-
● Does-
ile

● Reflect the business intent

● Describe only the required context for the scenario
Ag

● Express a pre-existing condition

● Use the ‘AND’ clause when there is more than one
pre-existing condition
● Does Not-
● Reflect technical implementation or developer actions
● Describe more than the required context for the
scenario
● Express an action
 ○ When (something happens)-
● Does-
● Describe the ‘what’
● Consist of a single action
● Execute the event or action you are testing
● Does Not-
● Describe the ‘how’
● Use the ‘AND’ clause
○ Then [observable outcome(s)]-

i
nt
● Does-
● Describe what the system should do

da
● Describe the business result
● Verify only the outcome relative to the action
● Use the ‘AND’ clause when there is more than one

Ve
observable outcome
● Does Not-
● Describe what the user does
by
● Describe something part of the implementation
○ Example-
● Given an empty shopping cart is created And a monthly
student pass is added to shopping cart When buyer checkout
oc

the shopping cart Then a 76 dollars sale occurred.

● Example: Functional Acceptance Criteria
D

○ User Story: As a customer, I want to order and pay for the book
via a secure web-based form, so that my credit card information is
safe.
ile

○ Acceptance Criteria:
● All mandatory fields must be completed before a customer
Ag

can submit a form.

● Information from the form is stored in the customer orders
database.
● Payment can be made via Amex, Master Card, or Visa
credit card.
● The system shall accurately calculate and apply sales tax.
● The system shall accurately calculate and apply shipping
charges.
 ● The customer shall be able to verify the accuracy of the
order.
● An acknowledgment email is sent to the customer
submitting the form.
● Protection against spam is working.
● Non- Functional Acceptance Criteria
○ Non- Functional Acceptance Criteria- Describes how a system
should behave and the limits of its functionality. These requirements

i
affect the user experience because they define a system’s behavior,

nt
features, and general characteristics.
● Types of Backlog Items

da
○ Non-User Stories – Backend functions/technical debt
● Statements on infrastructure/technical needs that help

Ve
deliver User Stories in the Product Backlog. Complete
backend functions or address technical debt
● Example: As a Developer, I want to configure our assigned
development region, so that we can begin developing User
by
Stories in our backlog.
● Example: As a Tester, I want to prepare a test lab, so that
we have representation of all device types & operating
oc

systems we need to execute tests on.

○ Spike Stories – Analysis/research
D

● Gather information on technical or functional questions. Do

not produce shippable product
● Example: As a Systems Analyst, I need to check the
ile

feasibility of storing all the parameters captured from

different systems.
Ag