Serverless

Agile User Story Overview, Design Thinking for Agile User

Stories
By Navdeep Singh Gill | 03 May 2019

Table of Contents

1. Key principles of Agile User Story

2. Overview on Agile User Story

3. When Are Agile User Stories Written?

4. Acceptance Testing Agile User Stories

5. Design Thinking for an Agile User Story

6. Best Practices for combining Design Thinking and Agile User

Thinking

7. Benefits of Using User Stories in Design and Development

 8. An Agile User Story Approach

Key principles of Agile User Story

Agile Development is one of the buzzwords for the software development
industry. The exciting thing is knowing precisely what Agile Development
is? Answer for this is as follows; It's a different way of managing software
development projects that empower teams to make decisions, software
delivered in small iterations. Agile user story involves high priority to
Customer participation from the beginning of the development cycle so
that Product can be developed as per client requirement and Team goal is
to deliver a product that is happy with at the end. Agile manifesto in brief

Respond to change

Working Product

Great Team

Delight the customer

Overview on Agile User Story

User Story is the High-level definition of the requirement of project
demands, that involves enough information that the developer has to give
an estimate of the effort required to implement it. User Story is one of the
artifacts for Scrum Project Teams Sometimes also called as a description
of a feature, In Agile Development we define user story and as per the
priority of feature moved to particular sprint or iteration. Sprint can be of 1
week or 2 weeks. It's better not to make a sprint for more than two weeks.
The vision behind User Story creation is Aligning Goals & Constraints.

The three C's of a user story

Card

User story card contains a concise description of the functionality of the

particular feature.
Conversation

It happens Just in Time when Team does a discussion about the Story to
get more details.
Confirmation

Test efforts that confirm a story's completion which involves the actual
definition of "Done."

When Are Agile User Stories Written?

User stories are written throughout the project. While planning product
backlog, Development team participates and describes the functionality to
be added during 3 to 6 months cycle. One of the features listed in the form
of a card. The Team includes developers, Product manager, Testers,
Interaction Designers. The Team writes the features instead of the
customer because team betters express the features and prioritize them
which can be released earlier. Mostly stories are prioritized on their value to
the organization. Accordingly release is planned after every short interval
of time. If one of Story does not get fit in iteration, the best way to split into
smaller stories, Team should follow Test-driven development approach,
and that must be part of user story creation.

User Story - Key Takeaway/ Facts

User Stories are not a specific task, and they are always a short
description of any independent feature of Product.

It doesn't tell the developer how the feature works.

It not final word in the Development as agile Development says welcome

change during Development.

User Stories doesn't need to be independent, can be a combination of 2

or more features if it's feasible in one sprint.

User Story neither have specific format nor rules for writing them

Also, User Story not shared with the customer some times.

User story checklist

It must Be as short as much as possible.

Should be Simple, easily understandable to the customer or end user.

User Story Written as per users perspective.

The Story must be created with agenda, i.e., What's the reason behind a
particular Story? i.e., Value benefit of Story must be cleared.

It must derive one of the functionalities if it's larger break it into small
parts.

Always follow Acceptance criteria.

Acceptance Criteria

Acceptance criteria define two things in the starting of development test

cases must be written first, and while closing any of task, it should satisfy
what's definition of done demands. Acceptance criteria denote what are
the conditions of satisfaction for the end user It help Team to understand
what's the value of a story and set the expectation accordingly. It varies as
per project and ends user demands.
Acceptance Criteria Goals
 First of all, Team should be clarified before starting Development on any
task.

We must ensure Team has a common understanding of the problem as

well.

Team members must be aware of the deadline or when Story to get

completed.

The Team must verify a story via automated Test.

Acceptance criteria should include

Functional and Nonfunctional Use case

Best practices, Guidelines and Performance concern

What a particular feature intends to do

End to end flow

User story impact on other featured.

UI/ UX concerns must be kept in mind

Acceptance criteria should not include

It's already conveyed that Team must have a clear understanding of what's
the definition of a done, i.e. unit/integrated tested, ready for acceptance
test, deployed on the demo server, releasable. So acceptance criteria
doesn't include the following things -

Non-blocker or major issues

The code review was done

Performance testing performed

Acceptance and functional testing done

Acceptance Testing Agile User Stories

Acceptance Test Provides essential criteria that can be used to determine
if Story is fully implemented or not.

User Story facts

Writing Stories

The first step is writing the User story, first of all, we should know what the
characteristics of a good user story are, As there are no hard code rules for
writing a user story. Independent User Stories should be separate as much
as possible. Otherwise, it becomes difficult to prioritize the Story and give
an estimation as well. Like if a customer wants one of the feature to get
implemented on high priority, but that is dependent on low priority feature,
so becomes much harder. Negotiable Requirements can't be drafted in the
form of a user story, and User story includes a short description of
functionality, which can be negotiable at the time of the conversation
between the client and development team. Estimable It's essential to give
rough estimation at least for user story assigned If developers say it can't
be estimated than it involved the following reason -

Developers lack domain and technical knowledge.

The Story is too big.

Small A user story must be as small as much as possible. We should break

more considerable functionality into small chunks that become easy to
estimate, prioritize and execute as well. Testable The Story must be written
in such an away that successfully passing through tests. Here involves the
definition of the done concept.
Gathering User story

It's not possible to convert the requirement of the project into small stories,
and Stories keeps on evolving throughout the project, So, we need a set of

practices or techniques to gather user story that can be used iteratively.

Guidelines for good user story

Start with Goal Stories

Slice the Cake

Put Constraints on Cards

Write for One User

Don't Number Story Cards

Don't Forget the Purpose

Estimating and Planning

Estimation should be under team hands, and They have to give a rough
estimate for their user story.
Planning a release set

First of all, it must be known when the customer would like to release,
accordingly prioritize the user story and put them in the iteration.So, Stories
are prioritized by the customer but with input from the developers. There
are many ways to prioritize in the form of first, second, third or Highest,
high, medium, but the best way is to put numbers.
Planning an iteration

It's to be done by Team, and Team discusses each Story as per feature
prioritize by the customer, accordingly divide among Team and get the
iteration started. Each developer form team accept responsibility for each
task There are no hard rules for particular task range can be of 3 to 5 hrs or
1 to 2 days as well, but better to spit into a checklist.
Measuring and monitoring Velocity

Estimation is mandatory to analyze the Velocity of task completion. Also,

another way is to graph the stats in the form of estimated time and actual
spent time

Design Thinking for an Agile User Story

Design Thinking revolves around three buzz words, i.e. What, When, How.
What is Design Thinking? It's an approach to solving design problems by
understanding User's needs and developing insights to address those
needs. When Design Thing? Developing and deploying a solution to a
problem How design thinking? Understand, Observe, Synthesize, Ideate,
prototype, Iterate

Understand the necessary knowledge so that the right question can be

asked

Gain Empathy with your target user by talking and observing them

Synthesize means coming up with a point of view statement that will

inform your prototyping

Ideate means based on your point of view generate many ideas as

possible

Prototype means to make your ideas real and learn from people reaction
to your prototype.

Iterate means revisit your assumptions.

The problem is How we can connect design thinking with Agile

Development? Solution for this is User Story Mapping.

User Story Mapping

It connects as a bridge between design thinking and agile Development
and generates business value. Here comes How business values getting
generated, there are numerous reason for that, some of them are as
follows -

Among Team members we create shared understanding whether its

design, engineering, product management, sales, and marketing

Teams themselves prioritize their most important work

We can have Visual representation of Product work

Helps in generating user story

 Assists the Team to enforce their focus back and forth between mission
statement and the individual user stories, we can iteratively improve both
in the process

Best Practices for combining Design Thinking

and Agile User Thinking

We should Invest in user Research

Before starting anything first, it must be enforced to do research, must
involve the entire Team to understand the end user. If research has already
happened then start with testing some ideas. This helps Team to discover
new problems that need to be solved and come out with a solution.

The problem statement must be defined clearly

Design Thinking should be part of Sprint 0, that allows Team to understand
the problem statement in deep and create a robust solution.

Build a productive team culture

Delimit the team size and make a core team that includes graphics
designer, scrum master, developer, QA, UX researcher. We should Create

such a culture that promotes collaboration across departments that

facilitates innovation, excellent ideas and a successful design solution.

Optimal Use of Design Thinking

At the first stage of project development or whenever vital feature has to be
developed, we should use design thinking. The feature requires innovation.

Design Patterns
It helps in reducing design and development times, and Design pattern
works as building blocks allowing teams to eliminate lower level design
decisions.

Periodic Testing
Testing must be enforced either once in a week or once during the sprint.
What the schedule is planned, you should test before the design gets
mature and Code gets finished.

Benefits of Using User Stories in Design and

Development
There are several advantages of using user stories in the design and
development cycles -

It becomes simple and easy to understand

Allows the developer to implement user value

 Allows project to be chunked into smaller pieces of features.

Facilitates cooperative working with clients and users.

Ready and done, What's the big difference?

Definition of Ready

User Story has been defined along with acceptance criteria, and Product
Owner has approved the Story.

The Story must include either documentation or description or use case.

The Story has been sized feasible as per 2 weeks plan.

Definition of Done

Unit test cases are written and passes when run

Code commenting has been done

Peer review, i.e., followed by best practices

Tested by QA or functionality of modules has been tested by automation

framework

No Outstanding Bugs are there

Documentation also accomplished for module defined in user story

In a Nutshell it includes Code meets the standard, Test achieved by level of

quality. Each Story meets acceptance criteria, and Documentation is
completed and approved.

An Agile User Story Approach

For Product or project design, the User story is the fundamental that help
us to understand the purpose behind any work. When Design Thinking and
Agile methodology combines, it results in innovation, productivity, and
profits. Combination of both is powerful and result oriented if followed with
best practices.To know more about Agile Methodology we advise taking
the following steps -

Know more about " Role of Automated Testing in Agile Enterprise "

Get an Insight about " Agile Analytics "

Learn more about " Agile Thinking"