AWB - 04 - Agile Requirements

123 Agile White Book – AXA Emerging Markets EMEA-LATAM
Chapter 4
AGILE REQUIREMENTS
V1.0

Contents
WHAT I WILL LEARN IN THIS CHAPTER?.................................................................................................................................................................... 126
THE AGILE APPROACH TO REQUIREMENTS .............................................................................................................................................................. 127
WHERE TO START ............................................................................................................................................................................................ 129
GET TO KNOW THE PLAN ......................................................................................................................................................130
GET TO KNOW THE CONTEXT.................................................................................................................................................131
CHECK WHERE YOU ARE........................................................................................................................................................132
CREATE HIGH-LEVEL OBJECTIVES.............................................................................................................................................133
CREATE THE PRODUCT BACKLOG............................................................................................................................................134
IDENTIFY THE TYPES OF ELEMENTS ..........................................................................................................................................136
WHAT TO DO WHEN YOU ARE READY ................................................................................................................................................................... 139
FOCUS ON THE LOW-LEVEL REQUIREMENTS..............................................................................................................................139
PRIORITISE ELEMENTS ..........................................................................................................................................................142
WRITE REQUIREMENTS AS USER STORIES ................................................................................................................................144
THE EXPECTED OUTCOME ................................................................................................................................................................................ 149
TAKE AWAY.................................................................................................................................................................................................. 150
CHECKLIST 4.1.................................................................................................................................................................................................. 151
CHECKLIST 4.2.................................................................................................................................................................................................. 153
CHECKLIST 4.3.................................................................................................................................................................................................. 157

Agile Requirements
Agile assumes that any project or product has a
horizon of uncertainty, from which it is not possible
to know the detail of a specific need at the very
beginning, and that changes will be required to the
original scope in order to meet expectations
customer.

What I will learn in this chapter?
AGILE REQUIREMENTS
I know why Scrum and its benefits.
I know the good practises & techniques.
KNOW THE
AGILE
APPROACH TO
REQUIREMENT
S
LEARN HOW TO START
- High Level Objectives
- Roadmap
- Product Backlog
KNOW HOW TO CREATE
REQUIREMENTS
- Take detail down
- Prioritise
- Write User Stories
I know the Scrum roles and its practises.

We believe that having too many
assumptions at the beginning of a project
produces unwanted rework.
THE AGILE approach to requirements
We believe that the client does not know the detail of all the requirements and will learn
along the way about the product needs. The context of the project may also change and
incorporate those changes in to the product to provide the Business Value required. In order to
cope with this, you would need to identify, gather, write and prioritise Backlog Items.
Agile assumes that details are gradually increased as the time gets closer to development. To
accomplish that you have:
High Level Requirements (or Epics) used to build a Roadmap.
Medium Level Requirements (or Product Backlog Items) used to build the
Product Backlog and finally Sprint Backlog when the Sprint is run.
Roadmap
Jjdj jdjdj xx dj
djjjdj
Jjdj jdjdj xx dj djjjd cjcjj xkkx kd k kkj
Jjdj jdjdj xx dj djjjd cjcjj xkkx kd k kkj
Jjdj jdjdj xx dj
djjjdj
Jjdj jdjdj xx dj
djjjdj
Jjdj jdjdj xx dj
djjjdj
High Level
Requirements
Product
Backlog
Items

THE AGILE approach to requirements
The Agile approach supports not falling into Analysis Paralysis, which may occur during defining
a huge and unrealistic scope. Agile provides greater flexibility to changing customer requirements
and context at any time. As requirements might change or disappear, you don’t need to spend
time in taking the fine detail until you reach what we called the last responsible moment.
Extracted from http://what-buddha-said.net/
The Product Roadmap is a core document to be built as this is an overall view of the product's
requirements and a valuable tool for planning and organizing the journey of product development.
The later you do it, the more information you would have. That is what we call last responsible
moment.
The Product Roadmap includes a Vision statement (what the product will offer) and a Product
Backlog.

WHERE to start
Workshops need to be organised initially to create a Roadmap: this includes a meeting to define
and write the High Level View Product Backlog Items (or Epics) where goals are defined.
It also assumes that a common business vocabulary is established and everyone can clearly
understand each other.

WHERE to start
GET TO KNOW THE PLAN
An Epic describes a business need –part of the Roadmap- that establishes a conversation
between Team, Product Owner and Stakeholders to discover what is needed in order to
reach specific business objective. It is written in a way that opens the door for an opportunity to
learn without getting into fine details until the feature is close to be developed.
As time gets closer, an Epic is splitted up into many Product Backlog Items, which are later
prioritised.

WHERE to start
GET TO KNOW THE CONTEXT
The aim of the high-level requirements or Epics in the Roadmap is to inform everyone what
the business wants to achieve. They represent achievable objectives that detail a plan to follow in
order to satisfy initial business intent.
The whole team needs to check the project objectives and Vision to make sure they
understand the whole view and scope. During this phase, it could also help spending time with
similar products to get some ideas.
If I were in your shoes, I would check that everyone:
 Understands the Vision.
 Knows the solution approach.
 Understands the Project Objectives and timeline,
 Quickly reviewed the high-level requirements.
 Checked similar products if available.
Once these FIVE things have been checked, make sure all expectations are aligned.

WHERE to start
CHECK WHERE YOU ARE
The first difference with other methodologies is that in Agile all requirements must have a business
justification (Business Value). The Product Backlog Iceberg is generally used as a metaphor
to express the idea of the Rolling Wave Planning: the level of detail and size of requirements
vary according to their priority and the proximity with its development.
The idea in here is not to dedicate more effort than the necessary to things that may
probably change or even objectives that could be cancelled.
The easy way to understand the pyramid is to read it from bottom (base) to top. The lower part
contains the business goals that are part of the Roadmap (Epics); for example, “we want our
VIP clients to obtain more benefits than our Standard clients”.

WHERE to start
CREATE HIGH-LEVEL OBJECTIVES
In order to create a Product Backlog with High-Level objectives usually:
 I facilitate identification a relative size for each requirement (i.e. XL, M, S) by the whole
team
 I share an initial idea of importance of each product backlog item (a score can be
used).
 I sort product backlog items by importance having in mind the size and basic metrics to
check against goals
 I ensure that we work on detalization of small batches of requirements.
An initial Scoring System can be used to weight the importance of each requirement; for example:
 Smaller items potentially enable faster return of investment (or at least feedback from the
market).
 Most important for the company/client/CEO and/or that can be achieved more quickly.
 Elements which allow other areas of the company to move faster and can be achieved with
a little effort, Maturity, Certainty, etc.
These score values are an integral part of Agile as they are very useful later on in the project
lifecycle to measure and communicate the success ratio to the rest of the company. Remember
that all the team members and stakeholders should join this activity.

WHERE to start
CREATE THE PRODUCT BACKLOG
On a second phase, people take an Epic, have a conversation and come up with a collection of
related elements which alone confer a benefit to the user, i.e. “VIP client can access to
discounts”, “VIP Clients have rewards”, etc. Finally the top part of the pyramid contains the
requirements that are ready to be developed during the coming Sprints (Scrum iteration). Once
they are taken on-board in the Sprint, they are fully detailed (Last Responsible Moment). One
thing to have in mind is that the top elements are always the ones with higher priorities.
As we have seen, requirements are set at different levels of granularity to avoid expending
effort to detail aspects and approaches that can change and even disappear. They are then split
when they become closer to development.
The possible levels of granularity are:
Epic - High level requirement that is not going to be developed in the short term, so
its size is usually large.
Feature - Feature or service system which alone confers a benefit to the user. This
covers the gap between problem and solution, without elaborating them. A system
can be described with a list of 25-50 features, which helps plan the delivery of value
to the project.
User Story - Feature detailed already that can be potentially implemented during a
specific iteration.
You can also classify the features in different categories in order to understand and create different
categories. One technique to do it is by using the Kano Model.

WHERE to start
As we have seen, all elements are part of the Product Backlog. To simplify visibility,
requirements can potentially be grouped by Theme. A Theme is a group of User Stories that
share a common attribute, and are grouped together for purpose of convenience.
Each element in the Product Backlog (or PBI) is located in a single functional area and may be
labelled with one or more threads (which can cut across several functional areas).
Themes can be used, for example:
 Understand the system
 Define releases and marketing strategies.
 Inspire integration tests.

Agile Requirements are an open
opportunity to learn, establish a
conversation and explore new ideas
WHERE to start
IDENTIFY THE TYPES OF ELEMENTS
A typical Product Backlog Item comprises the following different types of items:
 Features (generally expressed as User Stories).
 Bugs.
 Technical Work.
 Knowledge acquisition.
The last one (Knowledge acquisition) is anything that could generate specific knowledge for the
Product, i.e. an Spike or any other activity which will bring light to some area of the product.
Have in mind that items can involve different people based on the stage they are (Stakeholders,
Developers, User experience people, etc.).
A requirement should be “closed” or ready just before developing it (last responsible moment). In
the meantime, people can grow, exchange points of view and make sure that the best
approach at a time is taken.

WHERE to start

WHERE to start
There are 2 rules that must be applied to a list of requirements in order to consider it a Product
Backlog:
 All elements must have a Business justification (Business Value)
 No two items can have the same priority
 All items are SMART
SMART acronym is a simple tool that can guide you align your requirements
are aligned to everyone’s expectations.
The Roadmap is created iteratively in a number of workshops. You can use several techniques
to make the meeting more efficient:
 Use the 5W
o Ask several times why an element is so important until information is fully clarified.
 Use Post-its
o Using post-it during this session is a powerful tool as it enables participants to see
and move collaboratively the elements from one place to other. Many colours can be
also used in order to represent different sizes or importance.
 You can initially split the wall in XL (eXTra Large) and Large and place the items across the
two areas following an estimated size. You can then split the XL in XL and XXL (Super Big)
and repeat the process until you get 3 sizes (XXL, XL and L)).
Sizing and some good Visual Management will help everyone see things more clear.

WHAT TO DO when you are ready
FOCUS ON THE LOW-LEVEL REQUIREMENTS
In the Agile world, this is performed at several points at different levels. Detail is iteratively
incremented and we consider this as a very efficient way as it provides greater flexibility to the
customer. You gather requirements during:
 When the Vision and Roadmap is being built (very high level business goals).
 Initial Phase (Phase 0) and Release Planning.
 Product Backlog Refinement (PBR) activity. This is a meeting to:
o Keep the Product Backlog ordered.
o Remove or demoting items that no longer seem important.
o Add or promote items that arise or become more important.
o Split items into smaller items.
o Merge items into larger items.
o Estimate items, etc.

I always avoid intermediaries to collect the
requirement as this introduces delays, lower
synergies and creativity bias, loss of
information, documentation and
interpretation hypothesis!
Since Product Backlog Items are quite often large and generic by nature, and since ideas come and
go and priorities change, Product Backlog Refinement is an on-going activity throughout an
Agile project which focus on the different kind of requirements.
This activity mitigates the risks by maturing the requirements and aligns everyone to the project
Vision.

Product Backlog Refinement can be considered as the change management process. As during this activity team learns about
actual priorities clarifies the business needs and original intent, review the technical dependencies.

PRIORITISE ELEMENTS
All requirements in Agile, despite the size, must have a business justification or Business Value
and have a unique priority. The factors that affect how important a requirement is are generally
immaturity, technology risks, ROI, cost, etc.
Requirements are exclusively prioritised by the Product Owner considering all the different
factors and views. If a Stakeholder believes an element should be higher or lower in priority,
they should have a conversation with the Product Owner to check why the requirement is there.

While prioritising the Product Backlog, follow this piece of advice:
 Prioritize requirements by Business Value. In general, the most important
requirements are those that are lighter, so the likelihood of re-work on them is lower.
 Do not prioritize immature requirements. Unless you think it is important to use them
as a proof of concept to generate knowledge.
 Work in small batches of requirements.
 Avoid large transfers of information that did not have real feedback from their
customers/users.
Remember that prioritise means to order items by their importance relative to each other. An easy
way to filter or prioritise requirements is by identifying and grouping first the requirements using a
MoSCoW analysis.
 MUST: describes requirements that must be implemented in the final solution for the
success of the project.
 SHOULD: is used for high-priority items that should be included in the solution if there is
such possibility. Usually, should represents quite critical requirements
 COULD: represents requirements which are desirable but are not necessary. This will be
implemented only in case time and resources permit.
 WON'T: describes requirements that will not be implemented in a nearest release (and
stakeholders reached agreement about that), however these features may be considered for
the future.
Open the checklist “Prioritising Themes” to see how to easily
prioritise a Theme or Checklist 4.2 to see how to “Prioritise Epics and Features by Size and
importance”.

“As a business representative, I want to
upload documents so that I can share them
with my clients.”
WRITE REQUIREMENTS AS USER STORIES
There are many ways to represent a requirement but one of the most widely used in Agile is the
Used Story. A User Story is a short text used in Agile to capture a description of a software
requirement from a Business perspective and written exclusively by the Product Owner.
A User Story describes the type of user, what they want and why and helps to create a
simplified description of a requirement. It is a template that follows this type of format:
As a <role>, I want <requirement> so that <business reason>.
In order to write User Stories for success, we advise you to have in mind the following points when
writing User Stories:
 Place a short title which defines the story.
 Describe it in a short and simple way (not containing all the details of a requirement).
 Use Business Language
 Use a small card to force yourself to include just the important things.
 Use the card to establish a conversation with the rest of the Team to check if there is a
shared understanding.

“The rocket should move at 5km per hour”
“A Maximum of 5% of extra fuel should be used when moving right
or left”
“If right or left is pressed twice, the rocket should accelerate to
20kmh”
“If right and left are pressed at the same time, no move should be
done”
Always keep the User stories short, usually fitting on a note card. They should be written using
the language of the customer so that it is clear to both the business and the development team
what the client wants and why she wants it.
On the back of the card an Acceptance Criteria should be written. This specifies when the story
is finished.
These are some of the advantages of using an Acceptance Criteria:
 It ensures that everyone has a common understanding of the problem.
 Helps the Team members know when any given story is complete.
 It clarifies what the Team should build, in code and automated tests, before they
start to work.
 Helps verify the story via automated tests.

These are some of the advantages I found when started using User Stories:
 Teams found easy to correlate each requirement with the corresponding Business Value.
 It was easy for the team to give a relative Size to the User Story.
 It was easier to understand the mapping between each requirement and the person
who uses it.
 We eliminated a huge gap sometimes found between users and the development team.
 Development teams found easy to translate the Acceptance Criteria into tests
(Check Chapter 12 for more information).
For most Agile teams, user stories are the main vehicle of incremental software delivery.
In Agile, a development team's job is to take care of how to develop the code that will satisfy the
requirements of a specific user story.
The 3c (CCC) mnemonic will help you remember the different components of a User Story, the
Agile Alliance guide defines them as following:
 Card (or often a sticky note), a physical token giving tangible and durable form to what
would otherwise only be an abstraction.
 Conversation taking place at different time and places during a project between the
various people concerned by a given feature of a product: customers, users, developers,
testers. This conversation is largely verbal but most often supplemented by light
documentation.
 Confirmation This is the Acceptance Criteria, which is the formal part that set the
objectives to be reached (Acceptance Criteria).

The INVEST mnemonic can be used as a reminder of the characteristics of a good quality user
story:
From the point of view of the Development Team, there is just one more thing to do to consider
a User Story done.
A Definition of Done (DOD) is an agreed-upon set of activities and results that must be
completed and achieved before any Backlog Item is considered done; that might include:
 Code is well-written, the code is checked in.
 Code comes with automated tests at all appropriate levels.
 Code has been either pair programmed or has been code inspected.
 Diagrams or other documents where updated, etc.

By analogy with the "Definition of Done", the Development Team makes explicit and visible the
criteria to the Product Owner that a user story must meet before being accepted into an
upcoming Sprint (DOR).
Remember that requirements should always be aligned with the Vision and project
goals. If the Team does not understand the relationship between them, the Product Owner
is responsible for explaining and clarifying it to them.
Have in mind the following points when writing User Stories:
 User stories focus on Business Value.
 They don’t just assume a slackness of specification; they actually encourage it in order to
reassure a higher level of collaboration between Stakeholders and Team.
 A User Story is a metaphor for the work being done, not a full description of the work.
 In order to limit scope, User Stories have collaboratively developed Acceptance Criteria.
The more you use User Stories, the more comfortable you will feel with them.
Open the checklist “Requisites: get to the detail” to see how to
get requisites detailed in a collaborative way.

THE EXPECTED outcome
After reading this how-to, you should have understood how to produce:
 A Backlog with elements.
 The different levels of requirements.
 What a User story entails.
 What a Definition of Done and Definition of Ready are and who produce them.

TAKE AWAY
REMEMBER
 Keep always simple the process to prioritise elements.
 Keep the focus on any conversation related to requirements to avoid branching out.
 Have in mind the rolling wave pyramid.
 It is healthy to have an overview of all the Product Backlog items before prioritising elements.
DEEPEN YOUR KNOWLEDGE
Creating your project Roadmap
Kano Model
User Story
User Story vs. Use Cases
BENEFITS
 Moves any goal or requirement towards an opportunity for discussion.
 Keeps everyone aligned and talking the same language.
 Empowers collaboration.
 Keeps people focused on business results.
 Sets clear rules and aligns expectations.

Theme Prioritising
Checklist 4.1
Version 1.0
DATE: __________
Attendants
Context
Theme prioritising helps to start with requirement prioritization and dependencies analysis. Themes
are groups of epics and features to be implemented. Product Owner starts with Theme
prioritizing exercise to enable further planning and diving deeper into details of epics, user-stories
and features.

Task Comments
Theme Prioritising

I made sure I had pens and sticky notes.

Gathered different criteria for the
prioritization
 Gave each criteria a percent value
 Made sure all criteria should sum up to
100%.
 Placed all the elements in a Theme to
prioritise in front of everyone.

Scored them on a scale from 1 to 5, where 1
means a bad accomplishment of the goal
and 5 means a good accomplishment of the
goal.
 Ordered according to the values

Epics & Features Prioritising
Checklist 4.2
Version 1.0
DATE: __________
Attendants
Context
Epics and features prioritizing usually happens after the Theme prioritising (if the scope is big
enough to have theme, otherwise theme prioritising may be skipped). Product Owner holds this
session for dependencies elicitation and technical design initiation to be able elaborate plan of
releases as the next steps. This how-to shows hot to prioritise requirements by Size and
importance.

Task Comments
Epics & Features Prioritising

I made sure I had pens and sticky notes.

Drew 2 columns with the titles : XL (eXtra
Large) and L (Large)

I stuck the big elements under the XL
column. Product Owner asked the rest of
the team/experts if all were clear for them.
 Split the column XL in XXL (extra extra Large)
and XL
 Placed all the elements in a Theme to
prioritise in front of everyone.

The elements that were considered huge
were moved from the XL column to the XXL
column
 Split the column L in L and M (Medium)
The elements from the L column that were
considered smaller were moved to the M
column

Task Comments

We took the M column and figured out which
ones were more important and placed them
at the top (no two items can be at the same
level)

Items at the top of the M column gave you
the elements that could be implemented first
as they were the ones with the fastest
Return of Investment and biggest
Business Value.

Requirements get to the detail
Checklist 4.3
Version 1.0
DATE: __________
Attendants
Context
The session is organized to get technical details and requirements for one or many features.
Usually, the session is run by Product Owner, when the feature or user-story is about to be
taken into development.

Task Comments
1. Prepare the meeting

The room were booked.

Product Owner/Development Team/Scrum
Master were invited and a detail of the
activities was sent.

Development team was split in 2 or 3
groups.
 Groups were working in parallel on different
Requirements for 30-45 minutes.

The group used cards, post-its, whiteboard
and / or flipcharts to work collaboratively on
the requirements and noted down their
questions, for example, on a flipchart.

Product Owner and other experts in the
subject rotated every few minutes to answer
any questions that the group had.

Task Comments
2. Run the meeting

Groups were synchronized showing and
explaining their work to the rest (15 minutes
per group), which provided feedback and
resolved issues that they were not able to
solve by themselves.
 Part 1 was repeated until they were no
questions from the participants.
 The whole vision was presented to everyone.

AWB - 04 - Agile Requirements

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWB - 04 - Agile Requirements

Similar to AWB - 04 - Agile Requirements (20)

Recently uploaded

Recently uploaded (20)

AWB - 04 - Agile Requirements