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.

http://what-buddha-said.net/


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.

http://business-docs.co.uk/scenario/creating-your-project-roadmap

http://en.wikipedia.org/wiki/Kano_model

http://en.wikipedia.org/wiki/User_story

http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/


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

Leadership & Management