scrum framework explained
TRANSCRIPT
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
AGILE BASIS
PREV
NEXT
TOC
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 UncertaintyThe 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 fashionAttempting 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 Software1. 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.
SCRUM BASIS
PREV
NEXT
TOC
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 howbest 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
TeamUser
Sponsor QA Architect Visual Designer
DeveloperSysAdminUX DesignerDigital ConsultantManager / 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
TeamUser
Sponsor QA Architect Visual Designer
DeveloperSysAdminUX DesignerDigital ConsultantManager / 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
Source: The Scrum Handbook by Jeff Sutherland
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….
Source: The Scrum Handbook by Jeff Sutherland
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
PRODUCT BACKLOG
PREV
NEXT
TOC
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 ProductOwner 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 definitionThe 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.
Source: The Scrum Handbook by Jeff Sutherland
26 of 62PRODUCT BACKLOG
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.
27 of 62PRODUCT BACKLOG
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
Readiness of Backlog Items for Sprint N
Readiness of Backlog Items for Sprint N+1
Development of Items for Sprint 1
Development of Items for Sprint N
28 of 62PRODUCT BACKLOG
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
29 of 62PRODUCT BACKLOG
Stories (User Stories) are not just documents but conversation starters
Source: Jeff Patton
30 of 62PRODUCT BACKLOG
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
31 of 62PRODUCT BACKLOG
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.
32 of 62PRODUCT BACKLOG
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
33 of 62PRODUCT BACKLOG
Product Backlog Iceberg
Source: ScrumAlliance.org
Incremental and Iterative approaches conduct us to something called the Backlog Iceberg
34 of 62PRODUCT BACKLOG
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
35 of 62PRODUCT BACKLOG
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 #1US #2US #3US #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 -
MEETINGS
PREV
NEXT
TOC
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
Duration4 - 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
DescriptionStand-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 - Required: Product Owner, Scrum Master, Team (complete) - Optional: Stakeholders
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 - Required: Product Owner, Scrum Master, Team (complete) - Optional: Stakeholders
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 designUS#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 among the PO and the team
QA
PREV
NEXT
TOC
53 of 62QA
Why QA is so a great investment all aroundIf 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 productrelease
54 of 62QA
What it meansQuality 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 ScrumQA 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
QATeam
Acceptanceagreement
Documentguidelines
Codingguidelines
Continuoustesting
Teams
ScrumMaster
QATeam
Product Owner
Ready for Next Release
QATeam
QATeam
Product Owner
QATeam
Test Planmanagement
Productstabilisation
QATeam
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
- 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:
3) Pro - Continuous Integration
- 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:
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 suitesDefinition 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
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 1Maintenance
Team 2New 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 orrel-2.x-personY
