Intrd to Scrum and Agile

technologies
Agile has become one of the big buzzwords in the software
development industry.

agile development is a different way of executing software

development teams and projects.

Scrum is an efficient framework within which you can develop

software with teamwork. It is based on agile principles.
Waterfall Model
Iterative Incremental Model

In the iterative incremental model, the development starts with a

limited number of finalized and prioritized requirements. The
deliverable is a working increment of the product.

A set of activities ranging from requirements to code development is

called an iteration. Based on the functionality of the increment and
any or all of the new, modified, pending requirements, the next lot
of requirements is given to the subsequent iteration.

The outcome of the subsequent iteration is an enhanced working

increment of the product. This is repeated till the product
accomplishes the required functionalities.
Agile Development

Agile development is based on iterative incremental development, in

which requirements and solutions evolve through team
collaboration. It recommends a time-boxed iterative approach, and
encourages rapid and flexible response to change. It is a theoretical
framework and does not specify any particular practice that a
development team should follow. Scrum is a specific agile process
framework that defines the practices required to be followed.
Key Principles of Agile
Scrum is a framework for developing and sustaining complex products.

Ken Schwaber and Jeff Sutherland developed Scrum

Scrum is a process framework that has been used to manage complex product development
since the early 1990s. Scrum is not a process or a technique for building products; rather, it
is a framework within which you can employ various processes and techniques. Scrum
makes clear the relative efficacy of your product management and development practices so
that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts,
and rules. Each component within the framework serves a specific purpose and is essential
to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships
and interaction between them.
Sprint

The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a
potentially releasable product increment is created.

A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints consist of the Sprint planning, daily scrums, the development work, the Sprint
review, and the Sprint retrospective.
 Scrum - Roles

The Scrum Team consists of three roles,

a ScrumMaster, a Product Owner, and the Team.

ScrumMaster
● making the process run smoothly
● removing obstacles that impact productivity
● organizing and facilitating the critical meetings

Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the Team. The
Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management
includes-
Expressing Product Backlog items clearly.
Ordering the Product Backlog items to best achieve goals and missions.
Optimizing the value of the work the Team performs.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Team will work
on further.
Ensuring that the Team understands items in the Product Backlog to the level needed.
The Team

The Team is self-organizing and cross-functional. That means the team comprises
of analysts, designers, developers, testers, etc. as appropriate and as relevant to the
project.
The scrum team works together closely, on a daily basis, to ensure the smooth flow
of information and the quick resolution of issues. The scrum team delivers product
iteratively and incrementally, maximizing opportunities for feedback.
ScrumMaster Services to the Product Owner

● Finding techniques for effective Product Backlog management.

● Helping the Scrum Team understand the need for clear and concise Product Backlog items.
● Understanding product planning in an empirical environment.
● Ensuring that the Product Owner knows how to arrange the Product Backlog to maximize value.
● Understanding and practicing agility.
● Facilitating Scrum events as needed.
ScrumMaster Services to the Scrum Team

● Coaching the Scrum Team in self-organization and cross-functionality.

● Helping the Scrum Team to create high-value products.
● Removing impediments to the Scrum Team’s progress.
● Facilitating Scrum events as requested or needed.
● Coaching the Scrum Team in organizational environments in which Scrum is not yet fully adopted and
understood.
ScrumMaster Services to the Organization

● Leading and coaching the organization in its Scrum adoption.

● Planning Scrum implementations within the organization.
● Helping employees and stakeholders understand and enact Scrum and empirical product
development.
● Causing change that increases the productivity of the Scrum Team.
● Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the
organization.
Events
Scrum Process Framework can be viewed by means of a sequence of events and the corresponding
artifacts.

The Sprint
Sprint Planning
Daily Scrum Meetings
The Sprint Review
The Sprint Retrospective
The Sprint

During a Sprint, a working product Increment is developed. It is usually of duration

two weeks or one month, and this duration remains constant for all the sprints in the
project. We cannot have varying durations for the different sprints in a project. A new
Sprint starts immediately after the conclusion of the previous Sprint.

The Sprint Goal is an objective set for the Sprint. It provides guidance to the Team on
why it is building the Increment. It is created during the Sprint Planning meeting. The
scope of the sprint is clarified and re-negotiated between the Product Owner and the
Team as more about the requirements is learned.
Sprint Planning

The work to be performed in the Sprint is planned in the Sprint Planning Meeting.
Sprint Planning Meeting is of duration of maximum of four hours for two weeks
sprints and eight hours for one month Sprints. It is the responsibility of the Scrum
Master to ensure that the meeting takes place and that all the required attendees
are present and understand the purpose of the scheduled meeting. The Scrum
Master moderates the meeting to monitor the sustenance of discussion and
closure on time.
The inputs to this meeting are -

The Product Backlog

The latest product Increment
Projected capacity of the Team during the Sprint
Past performance of the Team
Daily Scrum Meetings

The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily to quickly understand the
work since the last Daily Scrum Meeting and create a plan for the next 24 hours. This meeting is also
referred to as Daily Stand up Meeting.

The Daily Scrum Meeting is held at the same time and same place every day to reduce complexity.

During the meeting, each Team member explains -

What did he do yesterday that helped the Team meet the Sprint Goal?
What will he do today to help the Team meet the Sprint Goal?
Does he see any impediments that prevent him or the Team from meeting the Sprint Goal?
Sprint Review

A Sprint Review is held at the end of every Sprint. During the Sprint Review,
a presentation of the increment that is getting released is reviewed. In this
meeting, the Scrum Team and the stakeholders collaborate to understand what
was done in the Sprint. Based on that, and any changes to the Product
Backlog during the Sprint, the attendees arrive at the next steps required that
could optimize value. Thus, the objective of Sprint Review is to obtain
feedback and progress unitedly.
The Scrum Master ensures that -
The meeting takes place.
The participants understand the purpose.
The meeting is focused on the required agenda and is completed within the required duration.
The Sprint Review includes the following aspects -
Attendees include the Scrum Team and key stakeholders, as invited by the Product Owner.
The Product Owner explains what Product Backlog items have been completed during the sprint and what has not
been completed.
The Team discusses what went well during the Sprint, what problems it ran into, and how those problems were
solved.
The Team demonstrates the work that it has completed and answers questions, if any, about the Increment.
The entire group then discusses on what to do next. Thus, the Sprint Review provides valuable input to Sprint
Planning of the subsequent Sprint.
The Scrum Team then reviews the timeline, budget, potential capabilities, and marketplace for the next anticipated
release of the product increment.
The outcome of the Sprint Review is an updated Product Backlog, which defines the probable Product Backlog
items for the next Sprint.
Sprint Retrospective

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. This is usually a one hour meeting for two-week duration sprints and a three hour
meeting for one month duration Sprints.

The purpose of the Sprint Retrospective is to -

Combine the learnings from the last Sprint, with regards to people, relationships, process,
and tools.
Identify the major items that went well and potential improvements.
Creation of a plan for implementing improvements to increase product quality.
Scrum Artifacts

Scrum Artifacts provide key information that the Scrum Team and the stakeholders need to
be aware of for understanding the product under development, the activities done, and the
activities being planned in the project.

Product Backlog
Sprint Backlog
Burn-Down Chart
Increment
The Product Backlog is an ordered list of features The Sprint Backlog is the set of Product Backlog
that are needed as part of the end product and it is items selected for the Sprint, plus a plan for
the single source of requirements for any changes delivering the product Increment and realizing the
to be made to the product. Sprint Goal.

The Product Backlog lists all features, functions, The Sprint Backlog is a plan with enough detail
requirements, enhancements, and fixes that that can be understood but the Team to track in
constitute the changes to be made to the product the Daily Scrum. The Team modifies the Sprint
in future releases. Product Backlog items have the Backlog throughout the Sprint, and the Sprint
attributes of a description, order, estimate, and Backlog emerges during the Sprint.
value. These items are normally termed as User
Stories.
The Increment is the sum of all the Product Sprint Burn-Down Chart
Backlog items completed during a Sprint
At any point in time in a Sprint, the total work
combined with the increments of all previous remaining in the Sprint Backlog can be summed.
Sprints. At the end of a Sprint, the new The Team tracks this total work remaining for every
Daily Scrum to project the likelihood of achieving
Increment must be a working product, which
the Sprint Goal. By tracking the remaining work
means it must be in a useable condition. It must throughout the Sprint, the Team can manage its
be in working condition regardless of whether progress.

the Product Owner decides to actually release it. Sprint Burn-Down Chart is a practice for trending
the work expended by the Scrum Team. This has
been proven to be a useful technique in monitoring
the Sprint progress towards the Sprint Goal.
Burn-Down Chart.

The sprint tracking is usually done using Burn-Down Chart. Burn-Down Chart shows the remaining effort in
day-wise number of hours. For example, let us consider a 2-week sprint -

Sprint Duration: 2 Weeks

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

If the=sprint
Hence, total remaining effort at the beginning of sprint is 2*5*6*6 work gets delayed and time
360 hrs.
commitment is not met, the burn-down chart
looks as follows -
User Stories

In software development, the product features play a crucial role. It is the features that the user
ultimately likes to use in the final product. They are known as Requirements in the general
terminology. The software development project success lies in understanding the user
requirements accurately and appropriately, and then implementing them in the final product.
Thus, requirements or product features need to be thoroughly known to the development project
team.

In 1999, Kent Beck came up with a term User Stories for the product features. He described that
a User Story is narrated from user perspective regarding what he or she wants to have rather that
what system can do for him. Thus, the view changed from product to user completely and User
Stories became de facto standard for Requirements in all Agile frameworks.
User Story: Customer’s Cash Withdrawal Acceptance Criterion 2:
As a Customer,
I want to withdraw cash from an ATM,
Given that the account is overdrawn
So that I don't have to wait in line at the Bank
User Story Acceptance Criteria And the card is valid
Each User Story also has Acceptance Criterion When the customer requests the cash
defined, so that correctness of implementation of
the user story is confirmed by passing the
Acceptance Test that is based on the Acceptance Then ensure the rejection message is
Criterion. displayed
Acceptance Criterion 1:
Given that the account is creditworthy And ensure cash is not dispensed
And ensure the card is returned.
And the card is valid
And the dispenser contains cash,
When the customer requests the cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned.
What is a Definition of Done?

The Definition of Done (DoD) represents the organization's formal definition of quality for all
Product Backlog Items (PBIs)

● Environments are prepared for release

● Handover to support is complete
● Review is ready
● Code is complete
● Unit test cases are complete
● Peer reviews are complete
● Testing is complete
https://www.youtube.com/watch?v=9TycLR0TqFA

Questions

● Steps in waterfall
● Disadvantages of waterfall
● What is sprint
● How many sprints conducted accr to video
● What are the three roles
● What are three artifacts
● Template for user story
● What are the 3 ceremonies
● Duration of sprint
Kanban
Kanban is a Japanese word that literally means “visual card”.

Kanban cards were originally used in Toyota to limit the amount of inventory tied up in “work
in progress” on a manufacturing floor.

Kanban not only reduces excess inventory waste, but also the time spent in producing it.

Kanban term came into existence using the flavors of “visual card,” “signboard,” or
“billboard”, “signaling system” to indicate a workflow that limits Work In Progress (WIP).

Kanban is a management method for teams and organizations to visualize their work identify and eliminate
bottlenecks and achieve dramatic operational improvements in terms of throughput and quality.
The core concept of Kanban includes −

Visualize Workflow
Split the entire work into defined segments or states, visualized as named columns on
a wall.
Write each item on a card and put in a column to indicate where the item is in the
workflow.
Limit WIP
Assign explicit limits to how many items can be in progress at each workflow
segment / state. i.e., Work in Progress (WIP) is limited in each workflow state.
Measure the Lead Time
Lead Time, also known as cycle time is the average time to complete one item.
Measure the Lead Time and optimize the process to make the Lead Time as small
and predictable as possible.
Limits Work-In-Progress (WIP)
Explicit limits are assigned to number of items that can be in progress at each workflow state,
indicated by a column.

This allows −

Reducing wait time.

Avoiding stress on resources at a workflow state.
Identifying bottlenecks causing an item to be in a workflow state than the anticipated time
(usually average cycle time) immediately.
Resolving bottlenecks with collaboration of the entire team.
Decreasing dependencies in completing a task by splitting it into sub-tasks, so that the
sub-task is tracked independently.
Pull Approach
When you have two teams and the first one is performing better than the second one,
it is likely that it pushes more work than the other can actually handle. This often
creates friction between the teams. A solution to this is the Pull approach.

In Pull Approach, the next team pulls work only when it is ready for it. Pull Approach
is implemented by adding a buffer with limited capacity between the two teams.

The benefits of Pull Approach are −

Avoids piling-up of work.

Reduces wait time.
Facilitates a team to maintain constant pace and focus on quality.
Provides resource balancing.
Minimize Cycle Time
The cycle time for each task is measured and the process is optimized to reduce
the cycle times.

The bottlenecks are identified immediately and resolved collaboratively by the

entire team.
The correction loops are considered to reduce rework.
Kanban Project Management
Kanban is adapted to software development as a project management
approach. Kanban in software development supports a continuous workflow,
termed as Value Stream.

Value Stream
The Value Stream consists of all actions required to bring a project from creation to completion.

The actions can −

Add Value to the project

Add no Value, but unavoidable
Add no Value, avoidable (termed as waste)
Elimination of Waste
Anything that does not add any value to the project is known as Waste. Kanban
facilitates elimination of waste.

In software development, there are three types of waste −

Waste in code development

Waste in project management
Waste in team potential
Kanban
https://www.youtube.com/watch?v=vU1Qp3dwnQs
Questions based on the video
1. Which year Kanban idea started
2. What is the meaning of Kanban, which Language
3. Who invented Kanban
4. What are the two major groups of kanban
5. List the Principles of kanban
6. Kanban board examples
7. Contents of Kanban cards work items
Answers
1. Which year Kanban idea started 1940
2. What is the meaning of Kanban, which Language: Sign board, Japanese
3. Who invented Kanban: Taiichi own
4. What are the two major groups of kanban : change management and service
delivery principles
5. Principles: Visualise workflow, limit WIP, manage flow,make process policies,
feedback loops,Improve collaboration
6. Examples: walls, boards or digital board comiz
7. Contents of Kanban cards work items: Responsible person and dead line, priority
Kanban and Scrum - Differences
Kanban tools
Kanban Tool
Kanbanery
LeanKit
JIRA Software
Earliz
Targetprocess
 What is Scaled Agile Framework?
SAFe is an open-source knowledge base that enables to apply lean and agile practices at the
enterprise level. It offers simple and lightweight features to develop software. SAFe is a set of
organizations and workflow patterns that guide enterprises in scaling lean and agile practices.

Safe framework helps team in −

Implementing lean and agile processes for software and systems at the enterprise level
Based on lean-agile principles
Guides to work at the enterprise portfolio, value stream, program and team.
Designed to meet the requirements of the stakeholders.
What is Scrum of Scrums?

Scrum of Scrums is designed to be a lightweight solution for scaling agile methods. The main benefit of

the Scrum of Scrums approach is to provide a way to enhance communication by connecting people from

different Scrum teams who need to collaborate and coordinate with each other.

A Scrum of Scrums (SoS) is a meeting between two sprints, where the development team discusses their

inter-team dependencies. The scaled agile framework is run by the development team members, who are

best positioned to discuss inter-team dependencies and find a solution.

Scrum of Scrums helps deploy and deliver complex products by adapting transparency and inspection at

a large scale. It enables scrum teams to work towards common goals and complete the project by

aligning.
How does SOS work?

Scrum of Scrums divides a large team into smaller scrum teams or subteams. Each subteam

will have its daily standups, sprint planning sessions, and other events as part of a Scrum of

Scrums meetings.

The basic idea is to give each subteam the autonomy to plan their work independently while

still coordinating with the rest of the team—just as independent teams do in a traditional scrum.

Here, the large number of people divided into smaller scrum teams can include up to 10

members in each team.

What Scaled Professional Scrum Is
Scaled Professional Scrum is about helping 3+ Scrum teams work together
effectively and efficiently to develop a single product. Most commonly this will be a
software product.

Scaled Professional Scrum and the Nexus framework are designed to help us deal
with the challenges that come with developing software with large numbers of people
and multiple teams.
NEXUS - SPS
Nexus is an exoskeleton that rests on top of multiple scrum teams when they are
combined to create an integrated increment.

Nexus is consistent with scrum and its part will be familiar to those who have worked
on scrum projects.

Nexus consists of the following

Roles:Nexus integration team, exists to coordinate, coach and supervise the

application of Nexus and the operation of scrum so best outcomes are derived.

Nexus team consists of the product owner, scrum master and three to nine developers.
Artifacts:All scrum teams use the same, single product backlog.

Events: Events are appended to placed around or replace regular scrum events to augment them.
They serve both the overall effort to all scrum teams in the nexus and individual team.

Refine the product backlog: Product needs to be decomposed so that dependencies are identified
and removed or minimized.

Nexus sprint planning: scrum team meet to discuss and review the refined product backlog.

Development work: All teams develop software frequently integrating their work into a common
environment that can be tested to ensure the integration is done.

Nexus daily scrum: development team meet daily to indicate whether the any integration issues
exist.

Nexus sprint review: meet appropriate stakeholders to review the integrated increment.

Nexus sprint retrospective: Appropriate representatives from each team meet again to discuss any
action needed on shared challenges to provide bottom up intelligence.