Scrum Framework Explained

SCRUM
FRAMEWORK
15.03.17 / v2.1
Nacho Montoya <imontoya@emergya.com>
Date / Version
By

2 of 62
AGILE BASIS
SCRUM BASIS
PRODUCT BACKLOG
RELEASES AND SPRINTS
MEETINGS
USER STORIES
QA
TABLE OF CONTENT
03
11
23
36
39
46
56
PAGE

4 of 62
Or… what’s wrong with traditional software
development?
AGILE BASIS
Why are we here, talking about AGILE?
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.

5 of 62AGILE BASIS
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.

6 of 62AGILE BASIS
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

7 of 62AGILE BASIS
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

8 of 62AGILE BASIS
Agile and Scrum, Scrum and Agile...
Scrum is one of the existing development agile frameworks.
But certainly, there are others agile frameworks available...
The ‘rational’ zone
Comparison of main agile frameworks in number of ‘rules’ Which one is the best?
Well, that is not the right question. The
right question is: Which one is best
for… ?

9 of 62AGILE BASIS
The Agile Manifesto
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 is more than just a set of frameworks for
development process. It’s a matter of cultural change

10 of 62AGILE 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.
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.

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

13 of 62SCRUM BASIS
SCRUM framework basic terminology
✔ Sprint Planning
✔ Sprint Review
✔ Daily Scrum
✔ Product Owner
✔ Scrum Master
✔ Team
3 Roles (Who)
✔ Product Backlog
✔ Sprint Backlog
✔ Product
increment
3 Artifacts (What) 3 Ceremonies (How)
Scrum framework is as easy as 3 + 3 + 3 in terms of the
main things needed to be managed

14 of 62SCRUM BASIS
SCRUM lifecycle including the 3 roles, 3
ceremonies and 3 artifacts
Source: Wikipedia: Scrum (software development)

15 of 62SCRUM BASIS
SCRUM framework: extended terminology
Source:Rodrigo Paolucci

16 of 62SCRUM BASIS
Scrum roles
Product Owner Scrum Master Team
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.
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.
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
There are three main roles according to pure SCRUM
framework

17 of 62SCRUM BASIS
Extended roles
Product Owner Scrum Master
Team
User
Sponsor QA Architect Visual Designer
DeveloperSysAdminUX DesignerDigital Consultant
Manager / Director
But in the practice, there are much more involved roles in
a project for a product development

18 of 62SCRUM BASIS
The Chicken and Pig Cartoon Metaphor
Source: Michael Vizdos
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

19 of 62SCRUM BASIS
The revised Chicken and Pig Cartoon Metaphor
Source:Jake Calabrese
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”

20 of 62SCRUM BASIS
Pigs & Chickens roles
Product Owner
Scrum Master
Team
User
Sponsor QA Architect Visual Designer
DeveloperSysAdminUX DesignerDigital Consultant
Manager / Director
In Agile, most of the roles are expected to be committed
with the project, not just involved - or informed
The ‘client’ zone

21 of 62SCRUM BASIS
The Product Owner: A key role
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
Assists the team,
resolving questions
related to the product,
removing potential
stoppers coming from
stakeholders and
reaching in real-time
agreements if necessary
Demo and “sells” the
product increments to “the
chickens”
He/she is the first end-user
of the product increment,
validating each iteration
(sprint and release)
Product owner needs to be fully engaged and dedicated all
over the whole project lifecycle

22 of 62SCRUM BASIS
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

24 of 62PRODUCT BACKLOG
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 ?

25 of 62
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.
PRODUCT BACKLOG
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.
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.

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.

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...
Product Owner Scrum Master QA Architect Visual DesignerUX DesignerDigital Consultant
Involved Roles in “Product Backlog Definition Team”
Lifecycle of the Product backlog definition Vs Scrum development
Sprint 0 (inception) Sprint 1 Sprint N
Readiness of Backlog
Items for Sprint 1
Items for Sprint N
Items for Sprint N+1
Development of Items
for Sprint 1
Development of Items
for Sprint N

Product Backlog definition is not just a
set of documents….
Source: Jeff Patton
This is what usually happens
when our work is based just on
shared documents
Collaborative work with all the team promotes
shared understanding and alignment
The reason for having broad discussions defining the
product backlog is not just because every opinion
counts. We are looking for shared understanding
Failure Success

Stories (User Stories) are not just
documents but conversation starters
Source: Jeff Patton

The Product Backlog definition must not
only be incremental
Source: Jeff Patton
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

The Product Backlog definition must not
only be iterative
Source: Jeff Patton
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.

The way to success must be both,
iterative but also incremental
Source: Jeff Patton
Good Agile definition teams combine Iterative
and Incremental approaches.
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.
“Art is never finished,
only abandoned.”
Leonardo DaVinci

Product Backlog Iceberg
Source: ScrumAlliance.org
Incremental and Iterative approaches conduct us to
something called the Backlog Iceberg

Product Backlog Iceberg and Definition of Ready
Source: ScrumAlliance.org
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

Building the Product Backlog with
Story Mapping
Source: ThoughtWorks
Story mapping is a top-down approach of
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
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.
Story Map structure like this:
User > Goals > Activities > Tasks > Stories
Story mapping is a technique initially developed by Jeff Patton
and is probably the most reliable way to build a product backlog
Goal
Activity
Tasks Stories
User

RELEASES
AND
SPRINTS
PREV
NEXT
TOC

37 of 62RELEASES AND SPRINTS
Planning horizons - Releases and Sprints
US #1
US #2
US #3
US #4
...
US #1
US #2
US #3
US #4
...
...
...
...
...
...
...
...
...
US #1
US #2
US #3
US #4
[ .... ]
Product
Backlog
Release
Backlog
Sprint 1
Backlog
Task #1.1
Task #1.2
Task #1.3
Release
Plan
Sprint
Plan
✔ Release: 3-4 Months period, divided into several
sprints, with a medium-accurate scope in terms of user
stories definition
✔ Release Plan: Sprints duration and dates are
established, and the first approach of planned target
US for each sprint is made
✔ Sprint: 1-3 Weeks period, with a high-accurate
scope in terms of user stories definition
✔ Sprint Plan: User stories are totally defined and
estimated for a specific sprint
A major product release will usually need several
sprints to be achieved
Sprint 1 Sprint 2 Sprint 3

38 of 62RELEASES AND SPRINTS
Release roadmap
Sprint 1
- 10 working days -
Stabilisation
- 5 working days -
Release
(deploy to pro)
Example of the schedule for an entire Release, divided into 3
development Sprints, of 2 weeks each
Release
3 sprints + stabilisation
- 38 working days -
Working Day
Sprint 2
- 10 working days -
Sprint 3
- 10 working days -

40 of 62MEETINGS
Release meetings
Release Planning Sprint Planning
Sprint Review
Retrospective
Sprint 1 Sprint 2 Sprint 3 Stabilisation
Release
(deploy to pro)
Release
Daily Scrum

41 of 62
Attendees
- Required: Product Owner, Scrum Master, UX, Tech Architects
- Optional: Rest of the Team, Stakeholders
When
At the beginning of each Release
Duration
4 - 6 hours (one or two sessions)
Outcomes
- A high-level plan of which specific US should be delivered in the
different sprints of the Release
- A high-level estimation, in story points, for each US to be completed
during the Release
- Insights about what are the most complicated items to be achieved
during the release, potential risks, dependencies and potential
blocking agents
Description
The goal of initial release planning is to estimate roughly which features
will be delivered by the release deadline. First, the PO presents the
prioritised items to be delivered. Ideally, the developers have already
devised rough estimates of how much work is required to implement each
of those features, but it can be done during the Release planning as a first
non-accurate estimation. Using the developers’ estimates and the
customer’s feature priorities, the team members lays out a release plan,
mapping features very roughly to each iteration.
Tips
- If the development team’s velocity on a previous release is already
known, dividing total estimated points for all required US by team’s velocity
allow us to address US to Sprints in a more accurate manner.
- Developers may find that fairly low-priority features that pose design or
architectural risks, and may, therefore, ask customers to consider assigning
them to earlier iterations in order to address those potential risks as early
as possible.
MEETINGS
Release Planning

42 of 62
Attendees
- Required: Product Owner, Scrum Master, Team (complete)
- Optional: Stakeholders
When
At the beginning of each Sprint
Duration
2- 4 hours
Outcomes
- Detailed planning for Sprint Backlog, with all the User Stories in
state of Readiness with related tasks to be done identified and
groomed
- Insights into detailed technical aspects of what is involved during
Sprint
Description
The Product Owner (PO) presents the target User Stories (US) for the
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,
assumptions will be uncovered; a high-level technical approach is also
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
Story Points. The PO can also re-prioritize work to get the most business
value based on re-estimated effort. Everyone is expected to provide input
and everyone’s voice is taken into account when determining the actual
level of effort.
This is the most intense of the Scrum ceremonies, but in a few hours, the
team is ready to begin developing the highest priority work.
Tips
- 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
Sprint Planning

43 of 62
Attendees
- Required: Scrum Master, Team (complete)
- Optional: Product Owner (recommended once per week, at least)
When
Once per day-with-no-other-meetings, typically in the morning
Duration
15 min
Outcomes
- Shared knowledge of work done and work remains in the short term
- 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
Daily Scrum
Description
Stand-up is designed to quickly inform everyone of what's going on across
the team. The tone should be light and fun, but informative. Each team
member must answer the following questions:
What did I complete yesterday?
What will I work on today?
Am I blocked by anything?
There's an implicit accountability in reporting what work you completed the
previous day in front of your peers. No one wants to be the team member
who is constantly doing the same thing and not making any progress.

44 of 62
Tips
- Remember, work should be fully demonstrable and meet Definition of
Done to be considered complete and ready to showcase in the review.
Duration
1 - 2 hours
Outcomes
- Demo of the functionality delivered during Sprint
- 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.
MEETINGS
Sprint Review
When
At the end of each Sprint
Attendees
Description
A Sprint Review/Demo meeting is held at the end of the Sprint to inspect
the Increment. The Team demonstrates the Increment with the focus on
the Sprint Goal according to the Definition of Done. The Product Owner
reviews and accepts the delivered Increment. This meeting should not have
Slides with the presentation of the results but should have a working
demonstration of the work planned in sprint planning.
After the demonstration the Product Owner and other relevant stakeholders
tell their impressions and clarify their requirements (user stories) if a
requirement was not implemented right. The Product Owner identifies what
has and hasn’t been done (according to the Definition of Done). The
Product Owner accepts the user stories that have been done.

45 of 62MEETINGS
Release Retrospective
Tips
- In Scrum, retrospective meetings are meant to be done after each iteration
(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”.
Description
Scrum Team revises their way of work in the past in order to make it more
efficient and effective in the future. The Scrum Master encourages the
Scrum Team to search for best practices and to identify improvement
measures that it will implement in the next Release. Whereas the Review is
about the product, the Retrospective is about the process – the way in
which the Scrum team works. In the Retrospective meeting, the Scrum
Master encourages the Development Team to inspect, within the Scrum
framework and practices, how the last Release went in regards to people,
relationships, process and tools. The Team should identify and prioritise
the major items that went well, and those items that, if done differently,
could make things even better.
When
At the end of each Release
Duration
2 - 4 hours
Outcomes
- Findings of what's working, so the team can continue to focus on
those areas, and also findings on what's not working, so the team can
try to find creative solutions
- Action plan, that is, a list of actionable improvements that will be
implemented for the next iterations
Attendees

47 of 62USER STORY
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

48 of 62USER STORY
Statuses & Workflow
New
Ready
To-Do
Resolved
Done
Closed
Blocked Rejected
PO + QA
Team
In
Progress
Team
Team
QA
PO
PO
PO
Team Team
< Assigned >
Definition
Development
Testing
Deployment
QA
Team
Review
New
Ready
To-Do
Resolved
Verified
Blocked Rejected
In
Progress
Sprint / Release
✔ New: US is added to the backlog.
✔ Ready: US is defined and ready to be planned, meaning that it meets
criteria in Definition of Ready
✔ To-Do: US is planned within a Sprint and a Release, and is not still in
development process
✔ Blocked: US development can’t be finished because of external
dependencies or lack of information. Assigned person needs to solve
dependencies
✔ In Progress: US is in development process
✔ Resolved: US development is finished, and it is ready to be validated by QA
team
✔ 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)
✔ Done: US meets criteria in Definition of Done, and PO has validated it
✔ Closed: US has been successfully deployed in live environment
Lifecycle of a User Story, in terms of its Workflow
Statuses, must cover the whole Scrum lifecycle
US Statuses:

49 of 62USER STORY
Break up examples
US#1
US#1.1: UI & Visual
US#1.2: Tech design
US#1.3: Development
US#1.1: UI & Visual
US#1.2: Tech design
US#1.3: Development
US#1.4: Automatic
tests development
US#1.1: UI & Visual US#1.3: Front development US#1.4: Back development I
Approach #1
Approach #2
Approach #3
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Stabilization….
US#1.2: Tech design
Approach #1
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
Approach #2
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
Approach #3
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
US#1.5: Back development II

50 of 62USER STORY
Definition of Ready
✔ 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
Definition of Ready is something that need to be agreed
among the PO and the team

51 of 62USER STORY
Definition of Done
✔ 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
Definition of Done is something that need to be agreed

53 of 62QA
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

54 of 62QA
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?

55 of 62QA
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
QA
Team
Acceptance
agreement
Document
guidelines
Coding
guidelines
Continuous
testing
Teams
Scrum
Master
QA
Team
Product
Owner
Ready for
Next Release
QA
Team
QA
Team
Product
Owner
QA
Team
Test Plan
management
Product
stabilisation
QA
Team

56 of 62QA
Steps for QA adoption
1) Basic - Manual testing
- 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:
2) Advanced - Half Automated Testing
- 1 QA per pipeline & per 5 developers
- Coding guidelines defined
- Performance testing defined - Manual run
- Basic CI - Packaging and Releasing
Tools:
3) Pro - Continuous Integration
- 1 QA per pipeline & per 3 Developers
- Coding guidelines defined and tested
- Performance testing defined - Auto run
- Complete CI - Automatic Deploy & Testing
Tools:
The first step for a minimum and successful QA adoption
is to have a dedicated and experienced QA person / team

57 of 62QA
The main test suites
Definition of Ready is something that need to be agreed
✔ 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

58 of 62QA
An example of test plan: Test Cases tab

59 of 62QA
An example of test plan: Coverage tab

60 of 62QA
Git flow
master
qa-hf-1.x
hf-1.x
qa-rel-2.0
rel-2.0
qa-hf-2.x
hf-2.x
qa-rel-3.0
rel-3.0
1.1-beta1 1.1-beta2
1.1 1.2
1.2-beta1
2.0-beta1 2.0-beta2 2.0-beta3 2.0-beta4
2.01.0
X
X
X
X
x.x
XX
Tag
Branch from….
Pull request
(merge to)
Merge from
(cherry picks)
Commit
Branch name
Team 1
Maintenance
Team 2
New Release
Gitflow organization example for two different teams, working in
parallel on two pipelines: Maintenance and New Releases
Direct push (commit) to
master, qa-rel and qa-hf is
absolutely prohibited.
Merges from master to rel-xx will need in most of
the cases specific stabilisation and decision
making, as long as they can include code or even
whole features deprecated for the new release
Although they are not explicitly included in the diagram,
personal - feature - branches can be created to work
from hf-X or rel-y, but always between two tags (major
or minor) to avoid “merge crisis”

61 of 62QA
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
hotfix
hf-1.x
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
release
rel-2.x
Demo Release X Demo environment for new major release X PO, stakeholders and key
end-users
qa-rel-2.0
(tag depending on what we want to
demo)
Local Release X Local environment for a specific developer or team in
Release (feature based)
Devel team / developer rel-2.x-featureY
or
rel-2.x-personY

www.emergya.comNacho Montoya
imontoya@emergya.com

Scrum Framework Explained

Recommended

More Related Content

What's hot (20)

Similar to Scrum Framework Explained (20)

Recently uploaded (20)

Scrum Framework Explained