SCRUM

FRAMEWORK

By Nacho Montoya <imontoya@emergya.com>

Date / Version 15.03.17 / v2.1

TABLE OF CONTENT 2 of 62

PAGE

AGILE BASIS 03
SCRUM BASIS 11
PRODUCT BACKLOG 23
RELEASES AND SPRINTS 36
MEETINGS 39
USER STORIES 46
QA 56
AGILE BASIS

TOC

PREV
NEXT
AGILE BASIS 4 of 62

Why are we here, talking about AGILE?

Or… what’s wrong with traditional software
development?

The traditional way to build software used by many companies is

a project based on a sequential life cycle of phases (requirements,
analysis, design, implementation, testing, deployment and
maintenance) of which there are many variants (such as the
V-Model). Commonly, it is known as “The Waterfall”.

This approach has strengths and weaknesses. Its great strength

is that it is supremely logical – think before you build, write it all
down, follow a plan and keep everything as organised as possible.

It has just one great weakness: Humans and software are involved
in the process. Guessing today how you will be in eight months
time is part of a fantasy. Trying to have a fixed plan today for the
next months, it is like trying to predict the future: Worthless.
AGILE BASIS 5 of 62

Agile calls for a new way of approaching

software development

Rather than doing all of one thing at a time...

… Agile teams do a little of everything all the time.

AGILE BASIS 6 of 62

Don’t let ourselves to be fooled by the

Cone of Uncertainty
The Cone of Uncertainty, described by Steve McConnell, shows
what any experienced software professional knows. Which is at
the beginning of any project we don’t know exactly how long a
project is going to take.

Software organisations inadvertently sabotage their own

projects by making commitments too early in the Cone of
Uncertainty. If an organisation commits at Initial Concept or
Product Definition time, it has a factor of 2x to 4x error in its
estimates. Commitments made too early in a project undermine
predictability, increase risk, develop project inefficiencies, and
impair the ability to manage a project to a successful
conclusion.

That’s why trying to have a reliable Gantt chart based on a

Product Requirements Document at the early stages of a project
sounds like trying to select the right feed for a Unicorn. For sure
you can select a lot of possible feed combinations, but the
problem is not in the feed. Source: The Cone of Uncertainty
AGILE BASIS 7 of 62

Reducing uncertainty in Agile fashion

Attempting to remove all end uncertainty before beginning the true development work of a project is
a classic mistake of teams using a waterfall process. Teams that choose to work iteratively
(including but not limited to agile teams) attempt to concurrently reduce both end and means
uncertainty. These teams understand that it is impossible at the start of a project to eliminate all
uncertainty about what the product is to be. Parts of the product need to be developed and shown to
customers, feedback needs to be collected, opinions refined, and plans adjusted. This takes time.
While this is occurring, the team will be learning more about how it will develop the system.

The best way to deal with uncertainty is to iterate. To reduce uncertainty about what the product
should be, work in short iterations and show (or, ideally give) working software to users every few
weeks. Uncertainty about how to develop the product is similarly reduced by iterating. For example,
missing tasks can be added to plans, inadequate designs can be corrected sooner rather than later,
bad estimates can be amended, and so on.

Agile projects concentrate on the early creation of functioning software. Only this can contribute
value to a company. An integrated requirements engineering and development process reduces risks
because the results are regularly evaluated and a continuous creation of value takes place.

Source: Mike Cohn

AGILE BASIS 8 of 62

Agile and Scrum, Scrum and Agile...

Scrum is one of the existing development agile frameworks.
But certainly, there are others agile frameworks available...

Comparison of main agile frameworks in number of ‘rules’ Which one is the best?

The ‘rational’ zone

Well, that is not the right question. The
right question is: Which one is best
for… ?
AGILE BASIS 9 of 62

The Agile Manifesto

Agile is more than just a set of frameworks for
development process. It’s a matter of cultural change

We are uncovering better ways of developing software by doing it and helping others do it.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Source: www.agilemanifesto.org
AGILE BASIS
12 practicable principles of Agile Software
1. Our highest priority is to satisfy the customer through
an early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals. Provide
them with the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is a
face-to-face conversation.
10 of 62
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity the art of maximising the amount of work
not done -- is essential.
11. The best architectures, requirements and designs
emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behaviour accordingly.
SCRUM BASIS

TOC

PREV
NEXT
SCRUM BASIS 12 of 62

SCRUM lifecycle at a glance

1 2 3 4

Based on a digital product vision 1 (new or improved one: website, app, etc…) we create a product backlog of stories
describing that product 2 and we launch a set of iterative implementation cycles 3 called sprints and grouped in releases,
each of them resulting in a new product increment that provides
4 added value to users and/or business
SCRUM BASIS 13 of 62

SCRUM framework basic terminology

Scrum framework is as easy as 3 + 3 + 3 in terms of the
main things needed to be managed

3 Roles (Who) 3 Artifacts (What) 3 Ceremonies (How)

✔ Product Owner ✔ Product Backlog ✔ Sprint Planning

✔ Scrum Master ✔ Sprint Backlog ✔ Sprint Review
✔ Team ✔ Product ✔ Daily Scrum
increment
SCRUM BASIS 14 of 62

SCRUM lifecycle including the 3 roles, 3

ceremonies and 3 artifacts

Source: Wikipedia: Scrum (software development)

SCRUM BASIS 15 of 62

SCRUM framework: extended terminology

Source:Rodrigo Paolucci
SCRUM BASIS
Scrum roles
There are three main roles according to pure SCRUM
framework
Product Owner
The Product Owner has profit and loss
responsibility for the product. She/he
is responsible for maximising ROI in
the sense of selecting, for each
product development iteration, the
highest - business - value Vs lowest -
cost items to be released. He/She
actively and frequently interact with
the team, personally offering the
priorities and reviewing the results
each two- or four-week iteration, rather
than delegating development
decisions to a project manager.
Scrum Master
The ScrumMaster is not the manager
of the team or a project manager;
instead, the ScrumMaster serves the
team, protects them from outside
interference, and educates and guides
the Product Owner and the team in the
skilful use of Scrum. The ScrumMaster
makes sure everyone on the team
(including the Product Owner, and
those in management) understands
and follows the practices of Scrum.
16 of 62
Team
The Team builds the product that the
customer is going to use. The team in
Scrum is cross-functional and includes
all the expertise necessary to deliver
the potentially shippable product each
iteration. It is also self-managing, with
a very high degree of autonomy and
accountability. Hence, there is no team
manager or project manager in Scrum.
Instead, the Team members decide
what to commit to, and how
best to accomplish that commitment.
Source: The Scrum Handbook by Jeff Sutherland
SCRUM BASIS 17 of 62

Extended roles
But in the practice, there are much more involved roles in
a project for a product development
Team
User

Sponsor Product Owner Scrum Master QA Architect Visual Designer

Manager / Director
Digital Consultant UX Designer SysAdmin Developer
SCRUM BASIS 18 of 62

The Chicken and Pig Cartoon Metaphor

Pig role is considered a core team member. Performer. Someone who “DOES” the
work. In classic Waterfall approaches, this role has been attached to somehow
called ‘the provider’ - external agency, external IT provider, internal IT area, etc

A Chicken is someone who has something to gain by the Pigs performing, but in
the end, really do not contribute day to day to “getting things DONE.” In classic
Waterfall approaches, this role has been attached to somehow called ‘the client’ -
sponsor, manager, project director, etc

Source: Michael Vizdos

SCRUM BASIS 19 of 62

The revised Chicken and Pig Cartoon Metaphor

In Agile, client and provider (internal or external) are both committed to the project
and to the product, getting things done together. The key figures to drive this cultural
and operational change are the Product Owner and The Scrum Master.

Remember this Agile principle: ”Business people and developers must work together
daily throughout the project”

Source:Jake Calabrese
SCRUM BASIS 20 of 62

Pigs & Chickens roles

In Agile, most of the roles are expected to be committed
with the project, not just involved - or informed
Team
User

Sponsor Scrum Master QA Architect Visual Designer

Product Owner

Manager / Director
Digital Consultant UX Designer SysAdmin Developer

The ‘client’ zone

SCRUM BASIS 21 of 62

The Product Owner: A key role

Product owner needs to be fully engaged and dedicated all
over the whole project lifecycle

Assists the team,

Understands and shares
the vision, goals, the
business insights and
priorities with stakeholders
Owns the product backlog
and its prioritisation. I.e:
He/She is the unique
responsible for the
product backlog building
and grooming, and for the
release scoping
resolving questions He/she is the first end-user
related to the product,
of the product increment,
removing potential validating each iteration
stoppers coming from
(sprint and release) Demo and “sells” the
stakeholders and
product increments to “the
reaching in real-time
chickens”
agreements if necessary

Source: The Scrum Handbook by Jeff Sutherland

SCRUM BASIS 22 of 62

The Product Owner needs to be someone….

100% dedicated, committed to the work and engaged fully with it during the entire
development process

Authorised and empowered by sponsors and managers to make his own decisions about the
product

Available to the team as much as possible

Knowledgeable about business domain, product envision and goals

Decisive not wasting too much time in making decisions

Collaborative and proactive as a normal mode of interacting with people

Negotiating trying always to achieve mutual agreements

Responsible for the outcome

Source: The Scrum Handbook by Jeff Sutherland

PRODUCT BACKLOG

TOC

PREV
NEXT
PRODUCT BACKLOG 24 of 62

Starting from the beginning: building the

product backlog

Hey, everything in the lifecycle

begins from here, it looks really
important yes, but…. What is this ?
PRODUCT BACKLOG 25 of 62

Product Backlog definition

The first step in Scrum is for the Product Owner to
articulate the product vision. Eventually, this evolves into
a refined and prioritised list of features called the
Product Backlog.
This backlog exists and evolves over the lifetime of the
product; it is the product road map. At any point, the
Product Backlog is the single, definitive view of
“everything that could be done by the team ever, in order
of priority”. Only a single Product Backlog exists; this
means the Product Owner is required to make
prioritisation decisions across the entire spectrum.
The Product Backlog is continuously updated by the Product
Owner to reflect changes in the needs of the customer, new
ideas or insights, moves by the competition, technical hurdles
that appear, and so forth. The team provides the Product
Owner with estimations of the effort required for each item on
the Product Backlog. In addition, the Product Owner is
responsible for assigning a business value estimate to each
individual item.

Many people like to articulate the requirements in terms

of “user stories” - concise, clear descriptions of the
functionality in terms of its value to the end user of the
product. In more demanding environments, such as FDA
life critical applications, Use Cases are often used.

Source: The Scrum Handbook by Jeff Sutherland

PRODUCT BACKLOG 26 of 62

Product Backlog common pitfalls

✔ The Product Backlog should not be confused with a "requirements document".

✔ There isn't a mandated format to represent the backlog: it can be an Excel document linking to other documents
(user flows, wiki pages describing tech designs, sketches and/or wireframes), custom views in a project management
tool like Jira, physical board with stories attached to their detailed descriptions, etc…. Whatever allows to have two
different visions: global one and detailed one. Physical form (scrum board) is one of the most common among little
Agile teams, but that’s not a useful form for teams whose members are distributed among different locations.

✔ Product Backlog is live in terms of a continuous evolution. Trying to have a completely defined and fixed product
backlog before starting development cycles is a waterfall approach disguised as an Agile one.

✔ On the other hand, set of stories (features, tasks, etc….) expected to be developed by the team in the next Sprint need
to be totally defined and understood by everyone to accomplish the sprint planning (See definition of ready).

✔ The backlog should not describe every item at the same level of detail, or "granularity". Features and tasks which are
expected to be delivered in the near future must be broken down into fine-grained items and accompanied with details
such as acceptance tests, UI sketches, etc.; whereas items planned for a more distant future can be described at a more
macroscopic level.

✔ A unique backlog mitigates the risk of creating multiple, conflicting versions, which would be a dire mistake given the
backlog function as a "single trusted source" of the work to be done.
PRODUCT BACKLOG 27 of 62

How do product backlog get ready?

Product Backlog grooming (in deep definition) can be treated as
a part of Scrum lifecycle, having its own sprints, stories, tasks...

Involved Roles in “Product Backlog Definition Team”

Product Owner Scrum Master Digital Consultant QA UX Designer Architect Visual Designer

Lifecycle of the Product backlog definition Vs Scrum development

Readiness of Backlog Readiness of Backlog Readiness of Backlog

Items for Sprint 1 Items for Sprint N Items for Sprint N+1

Development of Items Development of Items

for Sprint 1 for Sprint N

Sprint 0 (inception) Sprint 1 Sprint N

PRODUCT BACKLOG 28 of 62

Product Backlog definition is not just a

set of documents….
The reason for having broad discussions defining the
product backlog is not just because every opinion
counts. We are looking for shared understanding Collaborative work with all the team promotes
shared understanding and alignment

This is what usually happens

when our work is based just on
shared documents

Failure Success
Source: Jeff Patton
PRODUCT BACKLOG 29 of 62

Stories (User Stories) are not just

documents but conversation starters

Source: Jeff Patton

PRODUCT BACKLOG 30 of 62

The Product Backlog definition must not

only be incremental
Incrementing calls for a fully formed idea. Doing it on time requires
dead accurate estimation. It is not an iteration if you only do it once -
no matter if you divide it into parts, and do each part only once

This is not iterate

Source: Jeff Patton

PRODUCT BACKLOG 31 of 62

The Product Backlog definition must not

only be iterative
Iterating allows you to move from vague idea to realisation “iterating”
builds a rough version, validates it, then slowly builds up quality.

But iteration alone does not promote the desired divide & conquer
strategies.

Source: Jeff Patton

PRODUCT BACKLOG 32 of 62

The way to success must be both,

iterative but also incremental
“Art is never finished,
Good Agile definition teams combine Iterative
only abandoned.”
and Incremental approaches.
Leonardo DaVinci
An Agile team will conduct an Iteration (sprint)
and produce a product Increment. The
Increment adds completely new features,
based on new user stories, hence expanding
the scope of the functionality offered – that
makes it Incremental.

But each Increment is also likely to refine

existing functionality, adding users stories that
complete existing ones - that makes it
Iterative.

Source: Jeff Patton

PRODUCT BACKLOG 33 of 62

Product Backlog Iceberg

Incremental and Iterative approaches conduct us to
something called the Backlog Iceberg

Source: ScrumAlliance.org
PRODUCT BACKLOG 34 of 62

Product Backlog Iceberg and Definition of Ready

Definition of Ready is a checklist of conditions that must be true before a product
backlog item is considered ready to pull into a sprint during sprint planning.

Accurate estimation - and that

implies accurate delivery
commitment - is impossible
until this point!

There is a ”barrier” here, usually called

the State of Readiness of a backlog
item, that basically means that if an
item does not accomplish with
committed “Definition of Ready”, then
it can’t float to the top

Source: ScrumAlliance.org
PRODUCT BACKLOG 35 of 62

Building the Product Backlog with

Story Mapping
Story mapping is a technique initially developed by Jeff Patton
and is probably the most reliable way to build a product backlog

Story mapping is a top-down approach of User

requirement gathering and product backlog building
represented as a tree. Story mapping starts from an
overarching vision of a value for a user (persona in Goal

UX). A vision is achieved via goals. Goals are

reached by completing activities. And to complete
an activity, users needs to perform tasks. And these
tasks can be transformed into user stories for
software development. Activity

Story Map structure like this:

User > Goals > Activities > Tasks > Stories Tasks Stories
Source: ThoughtWorks
RELEASES
AND
SPRINTS

TOC

PREV
NEXT
RELEASES AND SPRINTS 37 of 62

Planning horizons - Releases and Sprints

A major product release will usually need several
sprints to be achieved

Product Release Sprint 1

Backlog Backlog Backlog

Release Sprint
US #1 US #1 ... ... Plan US #1 Task #1.1
Plan
US #2 US #2 ... ... US #2 Task #1.2
US #3 US #3 ... ... US #3
Task #1.3
US #4 US #4 ... ... US #4
...
Sprint 1 Sprint 2 Sprint 3
[ .... ]
...

✔ Release: 3-4 Months period, divided into several ✔ Sprint: 1-3 Weeks period, with a high-accurate
sprints, with a medium-accurate scope in terms of user scope in terms of user stories definition
stories definition
✔ Sprint Plan: User stories are totally defined and
✔ Release Plan: Sprints duration and dates are estimated for a specific sprint
established, and the first approach of planned target
US for each sprint is made
RELEASES AND SPRINTS 38 of 62

Release roadmap
Example of the schedule for an entire Release, divided into 3
development Sprints, of 2 weeks each

Release
3 sprints + stabilisation
- 38 working days -

Release
(deploy to pro)
Sprint 1 Sprint 2 Sprint 3 Stabilisation
- 10 working days - - 10 working days - - 10 working days - - 5 working days -

Working Day
MEETINGS

TOC

PREV
NEXT
MEETINGS 40 of 62

Release meetings

Release

Release
(deploy to pro)

Sprint 1 Sprint 2 Sprint 3 Stabilisation

Release Planning Sprint Planning Retrospective

Daily Scrum Sprint Review

MEETINGS 41 of 62

Release Planning
Attendees Description
- Required: Product Owner, Scrum Master, UX, Tech Architects The goal of initial release planning is to estimate roughly which features
- Optional: Rest of the Team, Stakeholders will be delivered by the release deadline. First, the PO presents the
prioritised items to be delivered. Ideally, the developers have already
When devised rough estimates of how much work is required to implement each
At the beginning of each Release of those features, but it can be done during the Release planning as a first
non-accurate estimation. Using the developers’ estimates and the
Duration
customer’s feature priorities, the team members lays out a release plan,
4 - 6 hours (one or two sessions)
mapping features very roughly to each iteration.

Outcomes
- A high-level plan of which specific US should be delivered in the
Tips
different sprints of the Release
- If the development team’s velocity on a previous release is already
- A high-level estimation, in story points, for each US to be completed
known, dividing total estimated points for all required US by team’s velocity
during the Release
allow us to address US to Sprints in a more accurate manner.
- Insights about what are the most complicated items to be achieved
- Developers may find that fairly low-priority features that pose design or
during the release, potential risks, dependencies and potential
architectural risks, and may, therefore, ask customers to consider assigning
blocking agents
them to earlier iterations in order to address those potential risks as early
as possible.
MEETINGS 42 of 62

Sprint Planning
Attendees Description
- Required: Product Owner, Scrum Master, Team (complete) The Product Owner (PO) presents the target User Stories (US) for the
- Optional: Stakeholders Sprint, one by one. The team discuss each item, identifying and sizing tasks
needed to complete the US. The PO can clarify requirements on-the-spot,
When assumptions will be uncovered; a high-level technical approach is also
At the beginning of each Sprint discussed so that developers are in alignment and this gives the PO a
better understanding of the level of complexity. US are sized (estimated) in
Duration
Story Points. The PO can also re-prioritize work to get the most business
2- 4 hours
value based on re-estimated effort. Everyone is expected to provide input
and everyone’s voice is taken into account when determining the actual
Outcomes
level of effort.
- Detailed planning for Sprint Backlog, with all the User Stories in
This is the most intense of the Scrum ceremonies, but in a few hours, the
state of Readiness with related tasks to be done identified and
team is ready to begin developing the highest priority work.
groomed
- Insights into detailed technical aspects of what is involved during
Tips
Sprint
- Use the sprint planning meeting to flesh out intimate details of the work
that needs to get done. Include PO in technical aspects of that work.
- With proper review of the requirements, conversations should flesh out
ambiguities up-front, enabling developers to develop the “right” thing for the
first time.
MEETINGS 43 of 62

Daily Scrum
Attendees Description
- Required: Scrum Master, Team (complete) Stand-up is designed to quickly inform everyone of what's going on across
- Optional: Product Owner (recommended once per week, at least) the team. The tone should be light and fun, but informative. Each team
member must answer the following questions:
When
Once per day-with-no-other-meetings, typically in the morning What did I complete yesterday?
What will I work on today?
Duration
Am I blocked by anything?
15 min
There's an implicit accountability in reporting what work you completed the
Outcomes
previous day in front of your peers. No one wants to be the team member
- Shared knowledge of work done and work remains in the short term
who is constantly doing the same thing and not making any progress.
- Insights of potential “blockers” and issues that need further
discussion
- Team’s mood tracking Tips
- Don’t use Daily Scrum for different meeting purposes, no matter if
attendees are the same. Schedule a different meeting for that.
- The Daily Scrum meeting is a problem-solving or issues resolution
meeting. Any issue pointed out by anyone during its intervention that needs
further discussion must be covered with involved people after the meeting.
Avoid getting stuck with details.
MEETINGS 44 of 62

Sprint Review
Attendees Description
- Required: Product Owner, Scrum Master, Team (complete) A Sprint Review/Demo meeting is held at the end of the Sprint to inspect
- Optional: Stakeholders the Increment. The Team demonstrates the Increment with the focus on
the Sprint Goal according to the Definition of Done. The Product Owner
When reviews and accepts the delivered Increment. This meeting should not have
At the end of each Sprint Slides with the presentation of the results but should have a working
demonstration of the work planned in sprint planning.
Duration After the demonstration the Product Owner and other relevant stakeholders
1 - 2 hours tell their impressions and clarify their requirements (user stories) if a
requirement was not implemented right. The Product Owner identifies what
Outcomes
has and hasn’t been done (according to the Definition of Done). The
- Demo of the functionality delivered during Sprint
Product Owner accepts the user stories that have been done.
- Acceptation of Users Stories that meet Definition of Done
- New Items in the Product / Release / Next Sprint Backlog and
potentially a new prioritisation of existing Product Backlog items. Tips
- Remember, work should be fully demonstrable and meet Definition of
Done to be considered complete and ready to showcase in the review.
MEETINGS 45 of 62

Release Retrospective
Attendees Description
- Required: Product Owner, Scrum Master, Team (complete) Scrum Team revises their way of work in the past in order to make it more
- Optional: Stakeholders efficient and effective in the future. The Scrum Master encourages the
Scrum Team to search for best practices and to identify improvement
When measures that it will implement in the next Release. Whereas the Review is
At the end of each Release about the product, the Retrospective is about the process – the way in
which the Scrum team works. In the Retrospective meeting, the Scrum
Duration
Master encourages the Development Team to inspect, within the Scrum
2 - 4 hours
framework and practices, how the last Release went in regards to people,
relationships, process and tools. The Team should identify and prioritise
Outcomes
the major items that went well, and those items that, if done differently,
- Findings of what's working, so the team can continue to focus on
could make things even better.
those areas, and also findings on what's not working, so the team can
try to find creative solutions
Tips
- Action plan, that is, a list of actionable improvements that will be
- In Scrum, retrospective meetings are meant to be done after each iteration
implemented for the next iterations
(ie, sprint). In practice, sprint retrospective usually happens as part of sprint
reviews, so it is a really good idea to schedule a specific retrospective
meeting just after the Release is finished - so the pressure over the team is
lower and the team can focus better, and issues addressed during last
sprints are still “fresh”.
USER STORY

TOC

PREV
NEXT
USER STORY 47 of 62

User Story Fields

✔ Title: As < user who requires the feature > I want <do something> so that < my goals >
✔ ID: User story unique identifier
✔ Description: A detailed description of the user story
✔ UX/UI Artifacts: Link to UX/UI-related stuff like personas, flows, wireframes, visual resources, etc…
✔ Tech design: Link to Tech related stuff like E/R diagrams, a picture of an architecture draw, etc…
✔ Acceptance: Clear steps to test and validate the user story
✔ Priority – Business priority
✔ Status: Check User Story Statuses and Workflow
✔ Estimate: Estimated size in points
✔ Assignee: Person owning this User Story. The owner of the user story is responsible for having the user story
advancing to the next step of the statuses workflow
✔ Fix Version/s: Release / Version for this User Story
✔ Epic Link: Link to its Epic
✔ Issue Links: Link to other related stories: blocking, blocked by, duplicating, causing, etc….
✔ Sub-Tasks: Link to sub-tasks needed to complete the US
USER STORY 48 of 62

Statuses & Workflow

Lifecycle of a User Story, in terms of its Workflow
Statuses, must cover the whole Scrum lifecycle New

PO + QA

US Statuses: Definition
Ready
✔ New: US is added to the backlog.
Sprint / Release
✔ Ready: US is defined and ready to be planned, meaning that it meets < Assigned >
Team
criteria in Definition of Ready Team Team
Blocked To-Do Rejected
✔ To-Do: US is planned within a Sprint and a Release, and is not still in Development
Team
development process In
Team Progress
✔ Blocked: US development can’t be finished because of external Team
QA
dependencies or lack of information. Assigned person needs to solve Resolved
Testing
dependencies QA

✔ In Progress: US is in development process PO

Verified Review
✔ Resolved: US development is finished, and it is ready to be validated by QA
PO
team
Done
✔ Rejected: QA has not validated US, so it needs to be reviewed by the team
✔ Verified: QA has verified that US meets acceptance criteria (tests passed) PO Deployment
✔ Done: US meets criteria in Definition of Done, and PO has validated it Closed

✔ Closed: US has been successfully deployed in live environment

 USER STORY 49 of 62

Break up examples
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Stabilization….

US#1.1: UI & Visual US#1.3: Development

Approach #1
US#1.2: Tech design

US#1.1: UI & Visual US#1.4: Automatic

US#1.3: Development
US#1 Approach #2 tests development
US#1.2: Tech design

US#1.1: UI & Visual US#1.3: Front development US#1.4: Back development I US#1.5: Back development II
Approach #3

US#1.2: Tech design

Approach #1 Approach #2 Approach #3

In Sprint 1 we achieve the visual and technical
design in US#1.1 and US#1.2. US#1.3 will not
be ready until US#1.1 and US#1.2 are done. If
US#1.1 or US#1.2 suffers a delay, they will be
moved to Sprint 2 and US#1.3 will be moved to
Sprint 3
Tech design -US#1.2 - needs UI and visual -
US#1.1 - to be totally completed and validated,
so we plan them into different sprints. We are
developing automatic testing with selenium -
US#1.4, that depends on final development
details - US#1.3, so we need a Sprint 4
Once we have UI designed - US#1.1, we can
develop front-end - US#1.3 at the same time
that we design backend solution - US#1.2 during
Sprint 2. Backend will finally be developed
during Sprint 3 - US#1.4 - and Sprint 4 - US#1.5
USER STORY 50 of 62

Definition of Ready
Definition of Ready is something that need to be agreed
among the PO and the team

✔ User Story is defined, it has been explained by PO, and expected result are clear for the team
✔ Acceptance criteria is defined, i.e detailed steps to test it with expected results
✔ Tasks needed to complete the US have been identified and defined by the team
✔ User Story has been sized by delivery team
✔ The US can be completed in one single sprint - if that’s not the case, the US should be broken down
✔ The US is not blocked from the beginning by any internal or external dependency
✔ Expected Demo for the User Story when appropriate is understood and committed by the Team
✔ Person who will validate the User Story is identified
✔ Team has all the user experience or visual artefacts needed for the User Story if needed
✔ Performance criteria is defined if needed
USER STORY 51 of 62

Definition of Done
Definition of Done is something that need to be agreed
among the PO and the team

✔ All the needed code has been written

✔ All the needed code and related files have been pushed to control version system
✔ Code and related configuration have been deployed into QA and Demo environments
✔ Acceptance criteria has been properly and successfully tested in QA and Demo environments
✔ US demo has been “signed off” by the person who was identified during Definition of Ready as the
one that should validate the US (PO by default)
✔ Deployment guide for the release has been updated with all the required information to properly
deploy the User Story into any target system, if needed
✔ Relevant technical documentation has been produced and/or updated, if needed
✔ Relevant end-user documentation has been produced and/or updated, if needed
✔ Code, security and usability guidelines has been checked and passed, if needed
QA

TOC

PREV
NEXT
QA 53 of 62

Why QA is so a great investment all around

If you ask experienced Product Owners about having or not having QA
system for live products maintenance and evolution, they could probably
explain you a lot of points. But the feeling is basically this….

WITH QA WITHOUT QA

Road to
product
release
QA 54 of 62

What it means
Quality Assurance means much more than just functional
or non-functional testing

✔ Commitment
✔ Continuous improvement processes
✔ Definition - Definition of Ready, Definition of Done,
Workflows, Guidelines
✔ Standards compliance - Code style, Documentation
✔ Testing - not only to identify, but to prevent defects
✔ Delivering - Properly and Successfully
✔ Validation - Expectations meeting: Have we done what we
were expected to?
QA 55 of 62

QA integration with Scrum

QA team participates in the whole scrum process, ensuring not
only the quality of the final released product but the quality of the
overall process itself

Product
Owner Product
Scrum Owner
Master
Ready for
Next Release

Teams

Acceptance Test Plan Document Coding Continuous Product

agreement management guidelines guidelines testing stabilisation

QA QA QA QA QA QA
Team Team Team Team Team Team
 QA 56 of 62

Steps for QA adoption

The first step for a minimum and successful QA adoption
is to have a dedicated and experienced QA person / team

1) Basic - Manual testing 2) Advanced - Half Automated Testing 3) Pro - Continuous Integration

- 1 QA per pipeline
- Acceptance is defined for each user story
- Test plan defined: Overall coverage > 30%
- Testing: Manual 100% Vs Auto 0%
- Non-Coding guidelines
- Non-Performance testing
- Non-Continuous integration (CI)
Tools:
- 1 QA per pipeline & per 5 developers
- Acceptance is defined for each user story
- Test plan defined: Overall coverage > 70%
- Testing: Manual 50% Vs Auto 50%
- Coding guidelines defined
- Performance testing defined - Manual run
- Basic CI - Packaging and Releasing
Tools:
- 1 QA per pipeline & per 3 Developers
- Acceptance is defined for each user story
- Test plan defined: Overall coverage > 95%
- Testing: Manual 10% Vs Auto 90%
- Coding guidelines defined and tested
- Performance testing defined - Auto run
- Complete CI - Automatic Deploy & Testing
Tools:
QA 57 of 62

The main test suites

Definition of Ready is something that need to be agreed
among the PO and the team

✔ Unit Testing guarantees the quality of isolated pieces

✔ Integration testing is split into different test suites:
✔ Acceptance/Smoke: Guarantees the quality of the core of the project
✔ Regression: Guarantees the quality of the entire app
✔ Progression: Guarantees the quality of the current development (release)
✔ Performance testing guarantees the system response capacity under low and high loads
✔ Responsive testing guarantees the defined responsive rules of the app
✔ Coding Standards testing guarantees that code is written following coding quality guidelines
QA 58 of 62

An example of test plan: Test Cases tab

QA 59 of 62

An example of test plan: Coverage tab

 QA 60 of 62

Git flow
Gitflow organization example for two different teams, working in
parallel on two pipelines: Maintenance and New Releases

master

1.0 1.1 1.2 2.0

Tag
x.x
qa-hf-1.x X qa-hf-2.x
Branch from….
Team 1 1.1-beta1 1.1-beta2 1.2-beta1
Maintenance
Pull request
hf-1.x X hf-2.x (merge to)

Merge from
(cherry picks)

qa-rel-2.0 X qa-rel-3.0 Commit

Team 2 2.0-beta1 2.0-beta2 2.0-beta3 2.0-beta4

XX Branch name
New Release
rel-2.0 X rel-3.0

Direct push (commit) to Merges from master to rel-xx will need in most of Although they are not explicitly included in the diagram,
master, qa-rel and qa-hf is the cases specific stabilisation and decision personal - feature - branches can be created to work
absolutely prohibited. making, as long as they can include code or even from hf-X or rel-y, but always between two tags (major
whole features deprecated for the new release or minor) to avoid “merge crisis”
QA 61 of 62

Environments example
Name Description Users Git Branches

Production Live environment End-Users master

(eg: tags 1.1)

QA Hotfix Staging environment for bugfix & I/R (minor releases) QA team hotfix and PO qa-hf-1.x
(eg: tags 1.2-betaX)

Dev Hotfix Integration environment for hotfix development Devel team hotfix and QA team hf-1.x
hotfix

QA Release X Staging environment for new major release X QA team release and PO qa-rel-2.0
(eg: tags 2.0-betaY)

Dev Release X Integration environment for new major release X Devel team release and QA team rel-2.x
release

Demo Release X Demo environment for new major release X PO, stakeholders and key qa-rel-2.0
end-users (tag depending on what we want to
demo)

Local Release X Local environment for a specific developer or team in Devel team / developer rel-2.x-featureY
Release (feature based) or
rel-2.x-personY
Nacho Montoya www.emergya.com
imontoya@emergya.com