What Is the SDLC?

• Definition from Computer World

•
The software/system development
life cycle (SDLC) is the overall
process of developing information
systems through a multi-step process
from investigation of initial
requirements through analysis,
design, implementation and
maintenance.

• There are many different models and

methodologies, but each generally
consists of a series of similar defined
steps or stages.
Phase of SDLC?

Phases of SDLC

1- Analysis
2- Design
3- Implementation
4- Testing
5- Evaluation
Methodologies
What is a Methodology?

A system of broad principles

or rules from which specific
methods or procedures may
be derived to interpret or
solve different problems
within the scope of a
particular discipline.

Unlike an algorithm, a
methodology is not a formula
but a set of practices.
SDLC Methodologies

There are number of methodologies

available to work with SDLC.
Waterfall
Agile
Spiral
 Evolutionary Prototyping
 Iterative and Incremental
V-Shaped
Most commonly used methodologies
Now we will take a look at most
commonly used methodologies.

Waterfall
Agile
Waterfall
Waterfall
• The waterfall Model is a linear
sequential flow.
• In which progress is seen as
flowing steadily downwards (like a
waterfall) through the phases of
software implementation. This
means that any phase in the
development process begins only
if the previous phase is complete.
• The waterfall approach does not
define the process to go back to
the previous phase to handle
changes in requirement.
• The waterfall approach is the
earliest approach that was used
for software development.
Advantages of Waterfall

• Easy to explain to the user

• Structures approach.

• Stages and activities are well defined·

• Helps to plan and schedule the project

• Verification at each stage ensures early

detection of errors / misunderstanding
•
• Each phase has specific deliverables
Disadvantages of Waterfall

• Assumes that the requirements of a

system can be frozen

• Very difficult to go back to any stage

after it finished

• Little flexibility and adjusting scope is

difficult and expensive

• Costly and required more time, in

addition to detailed plan
When to use Waterfall

• This model is used only when the

requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required
expertise are available freely
• The project is short
Agile
Brief History of Agile
 Introduction to Agile
Agile software development refers to a group of software development
methodologies that are based on similar principles. Agile methodologies generally
promote:
A project management process that
encourages frequent inspection and
adaptation

A leadership philosophy that encourages

team work, self-organization and
accountability

A set of engineering best practices that allow

for rapid delivery of high-quality
software

A business approach that aligns development

with customer needs and
company goals.
 Agile Journey
Benefits: The following are some of the industry cited benefits in agile
development:
• Evolves requirements and solutions through collaboration between self-
organizing, cross functional teams
• Promotes adaptive planning, evolutionary development, early delivery,
continuous improvement
• Encourages rapid and flexible response to change

Agile Journey Overview:

• Improved time to market

• Ability to respond to changes
• Increase in productivity
• Increase in employee engagement and satisfaction
 Myths
No documentation

Undisciplined

Agile is a process
Agile Manifesto

Individuals and
over Process and tools
interactions

Comprehensive
Working software over
documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Note: Although the agile manifesto places a higher
value on the left, that doesn’t mean that items on the
right are ignored.

Agile Manifesto Meanings

The meanings of the manifesto items on the left are:
• Individuals and interactions: self-organization and motivation are
important, as are interactions like co-location.
• Working software: working software is more useful and welcome
than just presenting documents to clients in meetings.
• Customer collaboration: requirements cannot be fully collected at
the beginning of the software development cycle, therefore
continuous customer or stakeholder involvement is very important.
• Responding to change: agile methods are focused on quick
responses to change and continuous development.
 Principles of Agile
The agile manifesto is based on the following 12 principles:

1. Customer satisfaction by early and continuous delivery of useful software

2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstance
Why the move?
• Projects too long to estimate accurately
• Increase short-term predictability
• Transparency
• Flexibility
• Agile builds empowered, motivated and
self organizing teams
Clear expectations are set and
communicated
• Customers communicate directly with
the team and provide timely feedback
• Teams feel a sense of accomplishment
and recognition
Agile Approach

In Agile the SDLC methodology we

can use three different approaches
to complete the SDLC

•Scrum

•Kanban

•XP
Scrum Origins

• Scrum’s rich history can be traced back to a 1986 Harvard Business Review
article, “The New Product Development Game” (Takeuchi and Nonaka 1986).
This article describes how companies such as Honda, Canon, and Fuji-Xerox
produced world-class results using a scalable, team-based approach to
all-at-once product development. It also emphasizes the importance of
empowered, self-organizing teams and outlines management’s role in the
development process.

• The 1986 article was influential in weaving together many of the concepts that
gave rise to what today we call Scrum. Scrum is not an acronym, but rather a term
borrowed from the sport of rugby, where it refers to a way of restarting a game
after an accidental infringement or when the ball has gone out of play. Even if you
are not a rugby aficionado, you have probably seen a scrum where the two sets of
forwards mass together around the ball with locked arms and, with their heads
down, struggle to gain possession of the ball.
• Takeuchi and Nonaka used the metaphors of rugby and the scrum to
describe product development:
• The . . . “relay race” approach to product development . . . may conflict
with the goals of maximum speed and flexibility. Instead a holistic or
“rugby” approach—where a team tries to go the distance as a unit, passing
the ball back and forth—may better serve today’s competitive requirements.

• In 1993, Jeff Sutherland and his team at Easel Corporation created the
Scrum process for use on a software development effort by combining
concepts from the 1986 article with concepts from object-oriented
development, empirical process control, iterative and incremental
development, software process and productivity research, and complex
adaptive systems.
The Creators
 What is SCRUM
Scrum is a lightweight agile project management framework mainly used for
software development. It describes an iterative and incremental approach for
project work. Scrum emphasizes collaboration, functioning software, team self-
organization and the flexibility to adapt to emerging business realities.
Scrum Roles?
What is Scrum?

Scrum Master Product Owner

Scrum defines
only three roles

1- Product Owner
2- Scrum Master
3- Development Team

Development Team
Scrum Roles – Product Owner

• The Scrum product owner is typically a project's

key stakeholder.
• Part of the product owner responsibilities is to
have a vision of what he or she wishes to build,
and convey that vision to the scrum team.
• This is key to successfully starting any agile
software development project.
• There can be one Product Owner for Multiple
Projects.
• Product Owner can be a Full time / Part time roll
• Can be influenced by a committee, however
committee can not be a product owner they will
nominate some-one to be a product owner.
• Product Owner has the final say about the product.
Scrum Roles – Product Owner

• 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.
Qualities
The Product Owner role is unique to the Scrum lifecycle and is crucial
to its success. These are the qualities/behaviors expected from the
Product Owners:

• Empowered to make critical decisions quickly for the team

• A leader within their functional area
• A dedicated and reliable advocate for the Scrum Team
• Voice of the stakeholders
• Holds the vision of the product/feature
• Able to quantify the business value of the product/feature
• Stays accountable to clarify and/or review the user stories for the
Scrum team in a timely fashion
Mandatory Meetings
Backlog Grooming
Release Planning
Sprint Planning
Daily Stand up
Sprint Review and Demo
Sprint Retrospective
Product Owner – This is not you
The Product Owner should avoid the following unfavorable behaviors:
Lack of product vision
Failure to prioritize
Requesting late change requests mid-sprint
Lack of leadership and planning
Micromanaging
Failure to meet deadlines
Absenteeism
Scrum Roles – Scrum Master

Responsibilities • The Scrum Master is responsible for making sure

a Scrum team lives by the values and practices of
Scrum.
• The Scrum Master is the Servant Leader and is
often considered a coach for the team, helping the
team do the best work it possibly can.
• It’s a Management Position.
• Scrum Master facilitates the Scrum events.
• keeps the team away from external distractions.
• Scrum Master advise rather than order.
• One Scrum Master can Manage Multiple
Products / Teams
• Scrum Master can be a Full time / Part time
Position.
• Scrum Master can delegate its duties to
Development Team (However its not advised)
Scrum Roles – Scrum Master Service to
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.
Scrum Roles – Scrum Master Service to
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 ScrumMasters to increase the
effectiveness of the application of Scrum in the
organization.
Scrum Roles – Scrum Master Service to
the 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.
Qualities
The Scrum Master role is unique to the Scrum lifecycle and is crucial to the
release success. These are the qualities/behaviors expected from the
Scrum Masters:
• Servant leader
• Advocate of the agile framework
• Chief facilitator of the release
• High level of communication
• Protector of the scrum team
• Reliable and dependable
• Focused on moving the team forward
• Empowers the team to make decisions quickly
• Focused on the deliverables requested by Stakeholders
• Clearly understands the Scrum Team’s status at any point in the release
• Encourages collaboration and communication
• Challenges the team to improve
Mandatory Meetings
Sprint Backlog Grooming
Release Planning
Sprint Planning
Daily Stand-ups
Sprint Review and Demo
Sprint Retrospective
Scrum of Scrums
Scrum Master – This is not you
The Scrum Master should avoid the following unfavorable behaviors:
Fails to adhere to agile framework. Example: Accommodating late change
requests during a sprint when the team is not positioned to do so
Lack of leadership and planning
Micromanaging
Poor organization
Inconsistent communication
Failure to meet deadlines
Absenteeism
Scrum Roles – Development Team

 Help the PO break down the user stories, fill in acceptance criteria
and research open items
 Develop and unit test scheduled user stories in the sprint
 Respond/Resolve defects opened by the testing team(s)
 Give clear, concise, and accurate stand-up updates daily to the
team
 Responsible for providing story points and task estimates during
sprint planning
 Attend and participate in routine Sprint backlog grooming sessions
 Clearly understanding the scope of each user story and how to
break down those user stories into small, independent work
products (tasks)
Scrum Roles – Development Team

 Participate in sprint planning and tasking exercises before each sprint

 Help facilitate the sprint demo and participate in the Sprint Retrospective
 Responsible for delivering user stories early to drive early acceptance in the
sprint
 Updates to tasks in Rally daily (both “State” field and number of hours left “to-
do”)
 Ensure all tasks are reflected accurately in Rally at any point in the Sprint
 Take part in the component testing and code review process
 Ensures all user stories meet the team’s Definition of Done (DoD)
 Create design and release documents as needed
 Participate in the production install and validation
Qualities
Here are some of the key characteristics of a great developer:
• High sense of urgency and participation
• Proactive
• High level of communication
• Willing to be flexible and adapt
• Comfortable with uncertainty and making educated guesses
• Solution-oriented
• Collaborates well with designers, the Product Owner, and testers
• Committed to high quality software development
• Embraces development visibility
• Willing to break pieces of work into small, manageable tasks (tasks are ≤ 8
hours each)
• Focused on producing the deliverables requested by Stakeholders
• Committed to continuous integration
• Voice any concerns about sprint commitment
Mandatory Meetings
• Release planning
• Sprint planning
• Sprint Backlog Grooming
• Daily Stand-ups
• Sprint Review and Demo
• Sprint Retrospective

Developers – This is not you

• Lack of open and honest communication to the Scrum Team
• Inconsistent communication of work status
• Absenteeism
• Not breaking tasks into small enough pieces
• Not updating tasks daily in Rally
• Working on too many stories at once
• Lack of participation
Testers
Responsibilities
• Understand user stories and if in doubt seek clarifications from PO
• Help the PO break down user stories and fill in acceptance criteria
• Prepare/update the artifacts for testing the applications
• Give clear, concise and accurate updates to the team during the daily stand
ups
• Attend and participate in routine sprint backlog grooming sessions as
needed
• Participate in sprint backlog grooming and release planning
• Participate in sprint planning and tasking exercises before each sprint
• Clearly understand the scope of each user story and break down those user
stories into small independent work products (tasks)
• Write, execute and update test cases in Quality Center
• Organize and set up test data
• Responsible for delivering user stories early to drive early acceptance in the
sprint
• Participate in Sprint Review and Demo and Sprint Retrospective
• Updates to tasks in Rally daily (both “State” field and number of hours left
“to-do”)
• Ensure all tasks are reflected accurately in Rally at any point in the Sprint
• Validate during production installs as needed
Qualities
• Here are some of the key characteristics of a great tester:
• High sense of urgency and participation
• Proactive and has a high level of communication
• Willing to be flexible and adapt
• Comfortable with making informed decisions
• Solution-Oriented
• Adhere to quality standards
• Willing to break pieces of work into small, manageable tasks (tasks are ≤ 8
hours each)
• Voice any concerns about sprint commitment
 Mandatory Meetings Testers
• Release planning
• Backlog grooming
• Sprint planning
• Daily Stand-ups
• Sprint Review and Demo
• Sprint Retrospective

Testers – This is not you

• Lack of open and honest communication to the Scrum Team
• Inconsistent communication of work status
• Absenteeism and lack of participation
• Not breaking tasks into small enough pieces
• Not updating tasks daily in Rally
Scrum – Stakeholders

• Stakeholders are not part of SCRUM Team

• They can not communicate directory to Scrum
Team.
• Product Owner is the person who interacts with
Stakeholders.
Scrum practices
Scrum – Events / Ceremonies
Scrum – Events / Ceremonies

Scrum Process Framework can be viewed by means

of a sequence of events or ceremonies and the
corresponding artifacts. The Scrum events are time-
boxed events. That means, in a project, every scrum
event has a predefined maximum duration. These
events enable transparency on the project progress to
all who are involved in the project. The vital events
of scrum are-

•The Sprint
•Sprint Release Planning Meeting
•Sprint Planning Meeting
•Daily Scrum Meetings AKA Daily Standup
•The Sprint Review
•The Sprint Retrospective
Events - Sprint
• During a Sprint, a working product Increment is
developed.
• It is usually of duration two weeks to a 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.
Remember: Only • Thus, each Sprint is associated with it, a definition of what
Product Owner can is to be built, a design, and the flexible plan that will guide
cancel a Sprint building it, the development work, and the resultant
product increment.
Events - Sprint
• A Sprint should be cancelled if the Sprint Goal becomes
obsolete.
• This might occur if the organization changes direction or
if market or technology conditions change.
• A sprint can be cancelled only by product owner ONLY,
though others have an influence on the same.
• Due to the short duration nature of Sprints, cancellation
during a sprint rarely makes sense. As the sprint
cancellations consume resources, for getting re-organized
into another Sprint, they are very uncommon.
• If a Sprint is cancelled, and part of the work produced
during the sprint is potentially releasable, the Product
Owner typically accepts it.
• All the incomplete Sprint Backlog Items are put back into
the Product Backlog.
Remember: Only
Product Owner can
cancel a Sprint
Release Planning Meeting

Purpose
• The purpose of the Release Planning meeting is to determine the
scope for the next release which will be built from the highest
ranking Product/Program Backlog items. The release plan will be
dictated by the team’s velocity, capacity and external dependencies.
Participants
• Scrum Master – to facilitate the meeting
• Product Owner
• Cross Functional Team
• Technical Architect
• Other SMEs
Preparation
• Before beginning the Release planning meeting, the Scrum Master
should ensure that the following items are verified:
• Prioritized Product/Program Backlog
• Backlog items all meet the Feature/User Story level Definition of
Ready (DoR)
• Identify dependencies and risks
• Adjusted velocity (from previous release and adjusted for capacity
changes)

Frequency/Timing
• Must take place for every release
• Typically occurs at a regular cadence depending on the number of
sprints per release
• For about 2 hours
• The team should revisit and update the release plan regularly
Steps to Follow
• The Scrum Master establishes the team member availability so that
adjusted velocity can be predicted
• Once the adjusted velocity is known, the plan is built starting with
the highest priority backlog item
• The cross functional team and Technical Architect will take into
account dependencies, internal and external to make decisions on
items that can be built, tested and delivered
• Any external dependencies will be identified and communicated to
the appropriate person for action

Outcome/Next Steps
• Release Plan – selected Product/Program Backlog items in priority
order (which may be adjusted along the way)
• Identify number of sprints
• Resolve external team dependencies so sprints are loaded with user
stories appropriately
 Events – Sprint Planning Meeting

• 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.

Sprint Planning focuses on the following two questions –

• What needs to be and can be delivered in the Sprint

Increment?
• How will the work needed for the execution of Sprint be
achieved?

Remember : All Scrum Events are time boxed

 Sprint Planning Meeting

Purpose
• The purpose of the Sprint Planning meeting is for the entire scrum team to
agree to complete a set of user stories. This agreement will define the sprint
backlog and is based on the team’s velocity (and capacity).

Participants
• Scrum Master – to facilitate the meeting
• Product Owner – to clarify the details of the Product Backlog Items and their
respective acceptance criteria
• Cross Functional Team – to define the work and effort necessary to meet
their commitment to complete Product Backlog Items. Developers and
Testers are mandatory.
Preparation: Before beginning the Sprint planning meeting, the Scrum Master
should ensure that the following items are verified:
• All user stories to be discussed during Sprint Planning meeting should meet
the scrum team’s Definition of Ready (DoR) (Especially, ensure that the
dependencies are ROAM (Resolved, Owned, Accepted, Mitigated),
acceptance criteria is clearly defined, story point estimate is assigned and
test data set up has been completed, etc.)
• Be aware of the sprint adjusted velocity (number of available story points for
the Sprint) and account for changes in the team’s capacity
• Release Plan updated
• Prioritized Product/Program Backlog

Frequency/Timing
• Must take place before each sprint in a release
• Typically occurs in the week before sprint starts or the morning of the first
day of the sprint
• Depending on the number of developers and user stories scheduled for a
sprint, which can range between 4-8 hours
Steps to Follow

• The Product Owner describes the highest ordered sprint backlog item(s)
• The scrum team determines that the user story is Ready and review the
acceptance criteria
• The scrum team reviews the story point estimate
• Developers volunteer to own the work
• Developers and Testers finalize tasks
• Review the set of standard (default) tasks and add those as relevant
• Planning continues while the team does not exceed the team’s determined
adjusted velocity
• Team determines the stories that will be committed to the sprint and updates
Rally or JIRA
Daily Stand-Up / Huddle

Purpose
• The purpose of the daily stand-up is for each team member to discuss the
goal and priorities for that day. Daily stand-ups provide visibility and
transparency to all stakeholders and help the team identify
problems/issues early.

Participants
• Scrum Master as facilitator
• Product Owner
• Cross Functional Team (Developers and Testers are mandatory and
optional roles, if any)
• SMEs as needed
Preparation
• Team members should be ready to give their status of the team
• Team should understand the importance of the meeting and commit
to starting on time
• Developers and Testers must have tasks updated in Rally/JIRA to
reflect their progress
• Team members should understand the state of the Sprint board and
be able to ask relevant questions if needed

Frequency/Timing
• Daily
• Not to exceed 15 minutes
• Can be followed by a meeting for discussion items, blockers, and/or
housekeeping items
Steps to Follow
• Each person should take turn to talk and answer the following
questions for the entire team and not providing answers to the
Scrum master only:

• What was accomplished yesterday?

• What is the plan (goals/priorities to accomplish) today?
• Any blockers or discussion items?
• Does the sprint board still reflect reality?

Each update should be precise and concise

• Avoid long discussions – discussion items should be identified
and the team will discuss those items after the daily stand up is
complete
• After the Daily Stand up, the team should reflect on whether or
not they are going to hit their weekly milestones and/or Sprint
goals to ensure that everyone is on the same page
Outcome/Next Steps
• All team members should have a clear understanding of the status
• Any blockers should be addressed as soon as possible after the daily
stand up
• Scrum Master should set up meetings with all parties (including the
cross functional team members, if any) to resolve the blockers the
same day if possible; If not, be prepared to highlight the impacts/
risks in completing the sprint successfully for PO and stakeholders
• Any stories in “completed” state should have a plan for when PO can
accept
• If there are any major blockers, plan a working session (meeting)
with the necessary people
Sprint Review and Demo
Purpose
• The purpose of the Sprint Review and Demo is to provide an opportunity to
demonstrate the team’s performance for the current sprint against the
sprint’s plan. In this way, it serves as a governance meeting. The Sprint
Review and Demo allows the team to show case their hard work,
accomplishments and share learning's.

Participants
• Scrum Master
• Product Owner
• Cross Functional Team (Developers and Testers are mandatory and optional
roles, if any)
• Dev Manager (Optional)
• Technical Architect (Optional)
• Other Stakeholders (Optional)
Preparation

• Only accepted user stories are demonstrated

• A plan for the demo (cases to demonstrate) and technical/data set up
required to demonstrate the functionality
• Conduct a dry run to vet out any issues if possible

Frequency/Timing
• Every Sprint should have one Sprint Review and Demo
• Usually held during the last day of the sprint
• About an hour or less
Steps to Follow
• Scrum master presents the sprint plan and the team’s
performance; potential agenda items are:
• Sprint objectives and process against objectives
• Metrics (i.e. burn-down and burn-up chart, velocity, etc.)
• Demo of accepted user stories
• For each accepted user story the team member will carry out
a demonstration to prove that the Acceptance Criteria have
been met
• Any failures to meet the Acceptance Criteria will be
documented and steps for remediation will be agreed or the
sprint Backlog item will be rescheduled to for the next
practical release. Note: These user stories are not demoed as
part of the Sprint Review
Sprint Retrospective
Purpose
• The purpose of the Sprint Retrospective is to provide an opportunity for the
scrum team to speak openly about how they felt about the sprint. It allows
only the contributors of the sprint team who were actively involved in daily
activities to discuss things that are going well and areas of improvement. It
serves as a forum for open honest, feedback in order to achieve continuous
improvement.
Participants
• Scrum Master
• Product Owner
• Cross Functional Team (Developers and Testers are mandatory and optional
roles, if any)
Preparation
• Review the activities and performance of the current sprint
• Host in a safe environment
• The team should be aware that none of the outputs documented will be
directly attributed to any particular scrum team member
Frequency/Timing
• Every Sprint should have one Sprint Retrospective
• Usually held on the last day of the sprint
• About an hour or two

Steps to Follow
• Each member of the scrum team will be asked for their input in the
following three areas – always start and end on a positive note
• Activities which went well and should be repeated – what does the scrum team want
to continue doing?
• Activities which did not go well and should be avoided in the next and subsequent
sprints?
• Action items for the next sprint
• Show appreciation to each other
• Iron out any differences or problems
• Build team camaraderie
 Events – Sprint Planning Meeting

The inputs to this meeting are –

1.The Product Backlog

2.The latest product Increment
3.Projected capacity of the Team during the Sprint
4.Past performance of the Team

The Scrum Team discusses the functionality that can be

developed during the Sprint.
Product Owner provides clarifications on the Product
Backlog items.
The team selects the items from the Product Backlog for the
Sprint, as they are the best to assess what they can
accomplish in the Sprint.
The Team comprises of analysts, designers, developers, and
testers. The work is carried out in a collaborative fashion,
thus minimizing re-work.

Remember : All Scrum Events are time boxed

 Events – Sprint Planning Meeting

• Work during a sprint is estimated during sprint planning

and may be of varying size and/or effort.
• By the end of the Sprint Planning meeting, the work is
divided into tasks of duration of one day or less. This is
to enable the ease of work allocation, and tracking the
completion.
• If the Team realizes that it has too much or too little
work, it can renegotiate the selected Product Backlog
items with the Product Owner.

The Team may also invite others (not part of Scrum Team)
to attend the Sprint Planning meeting to obtain technical
or domain advice or help in estimation

Remember : All Scrum Events are time boxed

Outcome/Next Steps

• Activities which went well and should be repeated

• Activities which did not go well and the lessons learned
• Action plan to improve performance for the next and subsequent sprints
• Scrum Master to share the details on action plan with the team
• Scrum master to share details of items that other scrum teams or the
program might benefit with the Release Train Engineer and/or the PMO
 Events – Daily SCRUM Meeting
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.

SCRUM MASTER IS NOT RESPONSIBLE TO ATTEND

/ CONDUCT DAILY SCRUM, HE/SHE NEEDS TO
MAKE SURE DEVELOPMENT TEAM DO DAILY
SCRUM

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 –

1.What did he do yesterday that helped the Team meet the

Sprint Goal?
Remember : All Scrum 2.What will he do today to help the Team meet the Sprint Goal?
Events are time boxed 3.Does he see any impediments that prevent him or the Team
from meeting the Sprint Goal?
Events – Daily SCRUM Meeting

Though the Scrum Master coordinates the Daily Scrum

Meeting and ensures that the objectives of the meeting are
met, the Meeting is the responsibility of the Team.

If necessary, the Team may meet immediately after the

Daily Scrum Meeting, for any detailed discussions, or to re-
plan the rest of the Sprint’s work.
Following are the benefits of Daily Scrum Meetings –

•Improve communication within the Team.

•Identify impediments, if any, in order to facilitate an early
removal of the same, so as to minimize impact on the
Sprint.
•Highlight and promote quick decision-making.
•Improve the Team’s level of knowledge.

Remember : Only Development team is required to attend daily SCRUM

 Product Increment – Not an Event

• Purpose of each sprint is to produce a working increment

of the product.
• The Product Owner decides when to RELEASE the
Increment
• A product Increment should be based on Definition of
Done.
• After the Sprint Expires Development Team should have
a working Increment of the product.

Remember: The purpose of the sprint is to produce a working Increment not

RELEASE an increment.
 Events – Sprint Review Meeting
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 Sprint Review is normally held for two hours for two
week sprints and for four hours for one month sprints.

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.

Remember : All Scrum Events are time boxed

 Events – Sprint Review Meeting
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 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.

Remember : All Scrum Events are time boxed

 Events – Sprint Retrospective
Meeting
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.
•The Sprint Retrospective is an opportunity for the Scrum
Team to introspect and improve within the Scrum process
framework so as to make the next Sprint outcome more
effective.

Remember : All Scrum Events are time boxed

Scrum - Artifacts
 Scrum – Artifacts (Metrics)
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. The following artifacts are defined in Scrum Process
Framework –

1.Product Backlog
2.Sprint Backlog
3.Burn-Down Chart
4.Increment

These are the minimum required artifacts in a scrum project and project
artifacts are not limited by these.

Remember : All Scrum Events are time boxed

Artifacts – Product Backlog

The Product Backlog is an ordered list of features that are

needed as part of the end product and it is the single
source of requirements for any changes to be made to the
product.

The Product Backlog lists all features, functions,

requirements, enhancements, and fixes that constitute the
changes to be made to the product in future releases.

Product Backlog items have the attributes of a

description, order, estimate, and value. These items are
normally termed as User Stories. The Product Owner is
responsible for the Product Backlog, including its
content, availability, and ordering.

Remember : Product Owner owns the product backlog only he can change it.
 Artifacts – Product Backlog
The Product Backlog is, in essence, an incredibly detailed analysis,
which outlines every requirement for a system, project, or product. In
simpler terms, it could be described as a comprehensive to-do list,
expressed in priority order based on the business value each piece of
work will generate. In the agile development tool, Product Backlog is
broken down and defined by a set of Features. Each Feature has a
defined business value and can be prioritized against other features in
the Product Backlog.

•Product Backlog refinement means adding detail, estimates, and

priority order to the Product Backlog items. This is an ongoing
process performed by the Product Owner and the Team. The Scrum
Team decides how and when refinement is to be done.

•Product Backlog items can be updated at any time by the Product

Owner or at the Product Owner’s discretion.

Remember : Product Owner is responsible for managing / Prioritizing Product backlog

Artifacts – Product Backlog

Features are usually sized by the team using t-shirt sizes.

T-shirt sizes help determine how many features the scrum
teams can possibly take into consideration within a defined
Release cycle.

Remember : Product
backlog is a living artifact,
which evolves with time
Artifacts – Sprint Backlog

The Sprint Backlog is the set of Product Backlog items

selected for the Sprint, plus a plan for delivering the
product Increment and realizing the Sprint Goal.
Development Team is responsible for Spring Backlog.

• The Sprint Backlog is a forecast by the Development

Team about what functionality will be made available
in the next Increment and the work needed to deliver
that functionality as a working product Increment.

• The Sprint Backlog is a plan with enough detail that

can be understood but the Team to track in the Daily
Scrum. The Team modifies the Sprint Backlog
Remember : Sprint backlog throughout the Sprint, and the Sprint Backlog emerges
have Items & Task. during the Sprint. This emergence occurs as the Team
works through the plan and learns more about the
work needed to achieve the Sprint Goal.
Artifacts – Sprint
Backlog
During the Sprint planning meeting, the team selects some
number of Product Backlog Items (PBIs), usually in the
form of user stories and identifies the tasks necessary to
complete each user story. The team only brings into the
sprint the work that they can commit to completing within
the sprint, and nothing more. If the scrum team completes
the planned user stories before the sprint is complete, then
they can take the next prioritized user story and work that. It
is important that the scrum team commits to what they are
confident they can complete within the sprint timebox.

The Sprint Backlog can address just about anything,

including new functionality, defects and risks. For the
Remember : Development purpose of sprint planning, user stories must be small
team is responsible for enough to be completed (developed, tested and documented)
Sprint Backlog during the sprint and can be verified that they were
implemented to the satisfaction of the Product Owner.
 Artifacts – Sprint Backlog

• If multiple teams are working on One products there will be multiple

Sprint backlog i.e. one for each team, however there will be just one
Product Backlog
• Development Team chooses the items from Product backlog since they
have the combined technical skills to estimate how much work can be
done in a sprint.
• Every sprint Item is owned by whole development team where as Tasks
can be owned / assigned to any member of development team.

Remember : Sprint backlog can only be changed by Development team i.e.

Tasks can be changed, Items can never be changed during the sprint
Scrum –Planning & Estimation
• A burndown chart is a graph that shows
how much work the team has left in
What is Burndown Charts their current iteration in order to meet
their iteration goal.

• At the start of an iteration the team

estimates the work for all the tasks they
commit to.

• The sum of all the hours estimated for

all the tasks is the starting point for the
graph.

• Every day the team members work on

tasks and the work should reduce every
day.

• Every day you can plot the remaining

amount of work, and the graph displays
a downward trend. Here are some
examples:
 Scrum –Planning & Estimation
What is Burndown Charts
The burn-down chart is a real time graph of where the team is at during a build sprint. At
any given point in time, the burn-down chart will always reflect how many hours are left
“to-do” in the sprint compared to an ideal trend line. A quick analysis of the burn-down will
highlight whether the team is on track or at risk of not meeting their Sprint goal. Example:

If the bars are consistently above the trend line, the team may be spending more time than
anticipated on the scheduled user stories, or are over-allocated in general. If the bars are
consistently below the trend line, this means the team may have capacity to take more user
stories into the sprint without extending the timeline.

As a best practice, all scrum masters are required to check the burn-down charts of their
respective teams during daily stand-ups to ensure whether the team is on track or needs
assistance. The team can also review the Burndown chart in their Sprint Retrospective to
discuss on how things went and if there is room for improvements.
 Burn-Up Chart
• The burn-up chart is a graphical representation where the green bars show how
much work has been accepted. The scope line (black diagonal line) indicates any
change in scope. The amount of accepted work (user stories that are developed,
tested, and meet acceptance criteria) starts at zero at the beginning of the sprint
and continues to grow until it reaches 100% acceptance at the end of the sprint.
• The burn-up chart should show a steady flow of accepted user stories. If there
are sharp increases, then user stories were waiting for the PO to accept and
review them. This may indicate that there is a communication breakdown on the
team, the PO is over allocated, or another issue that the scrum team should
address.
• The burn-up chart shows more information than a burn-down chart because it
also has a line showing how much work is in the project as a whole (the scope as
workload) and this can change.
Team Velocity
• The team velocity predicts how many user story points a scrum team
can successfully complete within a sprint.
• The velocity of a team is derived by adding the story point estimates of
all accepted work from the previous sprint. Stories that have not been
accepted are not included in velocity. This becomes the target velocity
for the sprint.
• By tracking team velocity over time, teams focus less on utilization and
more on throughput.
• As a best practice:
• Never use the velocity of another team to calculate a team’s velocity.
• Velocity for a cohesive scrum team becomes stable over time -
Velocity is not ever increasing!
• Scrum teams should consider reducing velocity anytime a team
member changes. No matter how strong the team is, it is always
disruptive to the team’s velocity when people are added and removed
from the group
• Many factors are assessed while adjusting the velocity, including (but
not limited to)
• Holidays
• Team PTO
• Standard meeting times
• Administrative overhead
• Production Support
• Downtime (i.e. environment related issues)
• Allocation (in case, if the resource is not 100% allocated to the team)
• For new teams to determine velocity:
• Start with the prioritized and sized Product backlog item
• Take the first story and get the scrum team’s confidence level that they can complete
that user story within the sprint
• When they agree, move it into the Sprint Backlog
• Then take the next user story and assess the team’s confidence they can complete that
user story, along with the previous, within the sprint
• Continue until the team no longer feels confident that they can complete additional user
stories within the Sprint
• Record this as the Sprint 1 target velocity
• For existing teams to determine velocity:
• Take an average of the actual velocity from the last 3 sprints (Only accepted stories
count toward velocity)
• Incomplete user stories do not count
• This average is the starting or target velocity
• Reduce velocity for holidays, vacations, town halls, etc., that will take time away from
the scrum team
• The adjusted velocity is the scrum team’s velocity for that sprint
Sprint Capacity
• Sprint Capacity is calculated in hours. It is usually calculated at the start of each
sprint for the development team. It verifies that the team’s Sprint Backlog is
reasonable and realistic. Sprint Capacity helps to see if any team:
• Just at Capacity : All developers are right at or within a few hours of their available
hours. The team should stop tasking user stories at this point and be set for the
Sprint to start.
• Over Capacity : Total tasks exceeds the available hours per developer. If this
happens, some user story needs to be taken out of the sprint backlog based on
scrum team agreement
• Under Capacity: The team still has available capacity for the sprint. In this case, the
team can pull prioritized user stories starting at the top of the prioritized backlog,
and continue tasking.
Scrum – what is a user story

User Stories are a Conversation

•User or customer need
•Product description
•Used for planning
•A conversation piece
User Story

• A User Story is used to capture a description of the work from an end-user

perspective. The user story describes the type of user (persona), what they
want and why. A user story is different from requirements because it starts
with the “why”, not just “what”.

• As a best practice, anytime a Product Owner thinks about a new

idea/feature, they should enter a User Story into the agile management
tool. The Product Owner should get into the practice of directly updating
agile development tool at the appropriate location within the tool.
 Characteristics of User Story
• User Stories typically follow a simple template:
• As a <type of user>, I want to <perform a function> so that <some reason
or benefit>.
• Characteristics of a good user story can be represented by the INVEST
model:
• I – Independent – Story is self-contained and not dependent on another
user story
• N – Negotiable – Can be changed and re-written prior to planning
sessions
• V – Valuable – Must deliver value to the user
• E – Estimatable – Must be able to estimate the size. Usually estimated in
User story points
• S – Sizable – Must be able to plan, task and prioritize with a level of
uncertainty
• T – Testable – Provides the necessary information to allow testing
Scrum – User Stories
MoSCoW Method

• M – MUST have (Critical for success)

• S – SHOULD have if possible (If not time critical)
• C – COULD have if it does not affect anything
else (Include if little development cost)
• W – WON’T have this time, but WOULD like in
future
Scrum – User Stories
M & S of MoSCoW

• M – MUST have (Critical for success)

• Essential - key stakeholders needs will not be satisfied if this requirement is not
delivered and the timebox will be considered to have failed

• S – SHOULD have if possible (If not time critical)

• Important - but if not delivered within the current timebox, there is an
acceptable workaround until it is delivered during the next sprint
Scrum – User Stories
C & W of MoSCoW

• C – COULD have if it does not affect anything else

(Include if little development cost)
• “Nice to have” – this is estimated to be possible to complete in the timebox but
will be de-scoped if an underestimation has occurred

• W – WON’T have this time, but WOULD like in future

• Will not be delivered within the timebox
User Story Grooming
• While grooming user stories, the team should ensure that the following 5
Ws are present and clear in the user story, and that the “how” is not.

• Each scrum team will groom a user story to assure that it meets the scrum
team’s definition of ready. The scrum master should ensure the grooming is
time-boxed to assure that the team stays on point and does not “spin” on
items that cannot be answered in the room.
Story Points

• Once a story is deemed ready, then the team will use story points to assess the
size, instead of hours. Story points area combination of the following three
variables - CUE:
• Complexity
• Uncertainty
• Effort
• The core benefits of estimating user story using story points instead of hours
are:
• Point estimation are easier, faster and ultimately becomes more accurate as
the team evolves
• Points are relative, not related to days or hours
 Story Point
Estimation

• For User Stories, story points are estimated using the Fibonacci sequence
as follows:
• 1 + 0 = 1 XS
•1+1=2S
•2+1=3M
•3+2=5L
• 5 +3 = 8 XL
• 8 + 5 = 13 XXL
• Since story points do not correlate to actual hours, it makes it easy for the Scrum
teams to think in more abstract terms about the effort required to complete a
story. Scrum teams that have stories with a point value equal to or greater than
8 story points, will most likely want to break that story down into smaller stories.
As a best practice,
• The Product or Program Backlog Grooming Team will provide “T-Shirt” sizing
estimates for Features prior to the user story sizing. After the user story sizing is
completed by the scrum team(s), then the Feature will be sized by adding
together all the story points. Over time the Product or Program Backlog
Grooming Team will be able to provide user story point estimates prior to the
scrum team(s) user story grooming and estimating
• Teams are required to follow “Fibonacci” sequence for user story point
estimation
• Teams are encouraged to try to size stories so that they can be completed
(design, development, test and acceptance) in about 4 business days or fewer.
This will help assure that the scrum team can complete the story within the
sprint. This will help the team work towards early acceptance
• If a user story is too large, then it should be broken down into multiple user
stories
Acceptance Criteria
Purpose
• Every User Story must contain “Acceptance Criteria”, or justification
for when a story is “complete”. Acceptance Criteria are essentially
tests specified by the user which can be used as a minimum measure
of whether a User Story is functioning as expected. Acceptance
Criteria details should include the following:
• Outline all the functional tests needed for the story
• Have enough details for test scripts to be written
• Be present in all user stories, and serve as a document of the
requirement details
• Include Functional and Non-Functional criteria
• Contribute to the Definition of Done
• Be formatted in business terms so business contacts can confirm
Definition of Done (DoD)

Purpose

• The Definition of Done (DoD) defines the criteria for Scrum Teams to
understand when a user story can be called “Done”. The DoD provides
transparency to the work a Scrum Team is performing. The DoD is related
more to the quality of the user story, rather than just its functionality. As a
Scrum Team works to develop a product, it is important for stakeholders and
Scrum Teams to understand when a product increment can be called “Done”.
This means that before a piece of functionality is in a potentially releasable
state, it must adhere to a common understanding of completion by those
working on the increment.
Benefits
• Having a clear DoD help Scrum Teams to:
• Work together more collaboratively
• Increases transparency
• Results in a development of consistently higher quality software
• Provides a baseline progress on work items
• Expose work items that need attention
• Determine when an increment is ready for release
 
User Story Level Definition of Done
• Every scrum team at Discover should have the following User Story Level
DoD:
• All acceptance criteria within the user stories is met
• Defects are resolved, accepted or deferred
• Demo should have been completed
• PO should have accepted the user stories
• Team update task to do hours to zero
Managing Unfinished Work & Splitting User Stories
• The main goal of Scrum is to deliver potentially shippable product at the end of
each sprint. All committed stories should be accepted by the end of the Sprint. A
pattern of rolling stories is not ideal. The team should find the root cause and
adjust sprint commitment.

Impact/Consequences of Unfinished work

• Not delivering value
• Impacts Velocity – Actual Velocity is based on Accepted stories
• Unfinished work moving to future sprints
• Cannot Demo or Accept stories
• Requires adjustments to the Release Plan
• Predictability is a challenge when teams roll stories
• Unhappy customers/stakeholders
• Demoralizing for the team
Common Root Causes

• Newly formed team or program

• Changes to the team or program
• Over-committing
• Estimation or tasking
• Incomplete Acceptance Criteria
• Incomplete wireframes
• Test data setup, unavailable or inadequate
• Test environment issues (unscheduled outages, dependencies, etc)
• Capacity Planning
• Adjust for holiday, PTO, Installs, training, etc
• Account for Environment Refreshes
• Team members that are not fully committed
• Distraction by outside commitments
• Dependencies not ready
• Test cases and/or defects not closed
• PO change of requirement, direction or priority

The Team needs to

• Analyze the root cause of the incomplete sprint
• What factors prevented the story from being completed/accepted?
• What can the team do differently in the next Sprint?
• What does the team need that it currently does not have?
• Look into the options for managing unfinished work
• Modify the plan for following Sprints as necessary
Options for Unfinished Work
• Continue the Story
• If a story is does not meet DoD, split the story in Rally or JIRA
• Decide whether to move the Continued story to a future sprint or
backlog
• Adjust Plan
• It is just a plan, not a commitment
• Reflect the team’s new reality
• Metrics are a valuable Information Radiator
• The goal is to show that the commitment was not met
• It opens up discussions for improvement
• Do Not Continue the Story
• Leave the story in the unfinished state
(Defined/In-Progress/Complete) forever
• Do not Accept the story because it will count toward your Velocity
Steps to Split a User Story in Rally
•Click into the User Story, click on the gear (top Right) and choose Split

•Below is a story that needs to be split because of partially completed work

Below is a story that needs to be split because of partially completed
work
PDP Compliance with Agile

• All agile releases are required to be compliant with the Product

Development Process (PDP). Similar to Waterfall, the PDP
compliance guide for Agile SDLC initiatives provides the guidelines for
obtaining the necessary documentation and approvals to ensure
organization SDLC risk is mitigated. All PDP SDLC Documentation
must be archived and approved in Discover SDLC Docs and must be
viewable for 5 years from the close date in Clarity. The Rally agile
tool is not the system of record for SDLC documentation.
• To see the PDP Compliance guide for Agile managed projects, click
this link:  https://dlife.discoverfinancial.com/docs/DOC-70206
Reminder:
EIS Requests
If the initial responses to the questions on the ISS Pre-Assessment or Control
Gate forms change during the project, then the appropriate person needs to re-
engage those SMEs as applicable.
Scrum Roles – Every scrum team should have resources identified for the following
roles
Role Name Role Responsibilities
Product Owner  Has good understanding of Scrum
 Responsible for defining and
prioritizing the Team Backlog
 Available to Team, attends the Scrum
meetings, responds quickly to Team
requests
Scrum Master  Dedicated SM with a good
understanding of Scrum
 Coaches/Mentors the team towards
successful completion of sprints
 Protects the team from distractions
 Removes impediments
 Servant Leader to the team
Cross Functional Scrum Team  Team size with 5 -9 people. Not to
exceed 9 people within one scrum
team
 Team should contain resources with
skill set needed to design, build, test
and deploy the software
Scrum Meetings – Every scrum team should meet as defined below and fulfill the expectations
Meeting Name Meeting Expectations
Daily Stand up  All Scrum teams should have daily stands up every day.
 Participants include Product Owners, Scrum Master and Cross Functional Scrum Team
 Daily Stands up are time boxed to 15 minutes or less. Daily Stands are not traditional status
meetings, hence cannot exceed more than 15 minutes
 Address the “three questions” that should be asked during every Daily Stand up:
1. What was accomplished yesterday?
2. What is the plan (goals/priorities to accomplish) today?
3. Any blockers or discussion items?
 Participants are required to make daily updates to Rally prior to daily stand ups

Sprint Planning  Must be held at the beginning of every sprint

 Sprint planning meetings are time boxed between 4-8 hours
 Product Owner, Scrum Master and the Cross Functional team should attend the meeting
 All user stories should have estimates prior to sprint planning
 Team should create the sprint backlog with user stories committed to work on during the
sprint

Sprint Demo  Held at the end of every Sprint

 Stakeholders are invited to attend
 All accepted user stories should be demoed
Sprint Retro  Held at the end of every Sprint
 Participants include Scrum Master, Product Owner and the cross functional Team
 Team members take responsibility for enacting any agreed-upon changes
Scrum Artifacts – Every scrum team should maintain the following artifacts
Artifact Name Artifact Description
Program Backlog  A list of features that describes the capabilities of a product
 Should be maintained in Rally by the Product Manager or
Product Management team.
 Should include both the functional and technical features
required to support the product development

Sprint Backlog  A list of user stories selected and committed by the team to
work on during the sprint
 Once the user stories are committed, no further changes will
be encouraged unless the cross functional team agrees

Burndown chart  A graphical representation of work left to do versus sprint time

 Scrum Master to review the chart during daily stand ups
 Cross Functional team members are required to update their
“to do” hours in Rally on a daily basis
Scrum Activities – Every Scrum team should adhere to the following activities
Activity Name Activity Description
Backlog Prioritization  Two levels – User story Level & Feature level
 User Story level prioritization – Forced ranking by POs with inputs
from team
 Feature level prioritization – Done by the Product Manager or Product
Management team.
Definition of Ready  A set of criteria (or conditions) that user stories should meet before it
can be picked up for sprint
 Should be maintained at the Feature and user story level

Definition of Done  A set of criteria (or conditions) that user stories should meet in order
to say it is “done”
 Should be maintained at the Feature and user story level

Defining Sprint Schedule  Sprint Duration should be no longer than 3 weeks (Longer the sprint,
risk is higher)
Release Planning  Create the release plan
 Identify # of sprints, risks, assumptions and dependencies
 Identify milestone(s) and a timeframe for release(s).
Term Description

Acceptance The detailed requirements for each user story; includes both the "what" and the "how" of
Criteria the feature. The "what" is defined by the Product Owner and the "how" is defined by the
Scrum team.
Sprint Work is confined to a regular, repeatable work cycle, known as sprint (also known as
iteration in the industry). A typical sprint is 2 or 3 weeks in length and cannot exceed 3
weeks.
Burn-down Chart The burn-down chart is a real-time graph of where the team is at during a sprint. At any
given point in time, the burn-down chart will always reflect how many hours are left "to-do"
in the sprint compared to an ideal trend line. A quick analysis of the burn-down will highlight
whether the team is on track or needs assistance. If the bars are consistently above the
trend line, the team may be spending more time than anticipated on the scheduled
features, or are over-allocated in general. If the bars are consistently below the trend line,
this means the team may have capacity to take more features into the sprint without
extending the timeline.
Daily stand-up The daily stand-up is a 15-minute meeting between the Scrum Team members. This
meeting is facilitated by the Scrum Master but is not a status meeting for the Scrum
Master. Each team member is responsible for answering 3+1 questions to the team as a
way of providing an understanding of team priorities and issues. Once the team has
concluded the ceremonies, the Scrum Master can then recap the issues presented (if any),
and begin addressing them in priority order.
3+1 Questions:
1.What did I do yesterday?

2.What am I doing today?

3.What are my issues/blockers?

+1: Does the sprint board still reflect reality?

 Definition of “Done” Each Scrum Team (with the Product Owner) is responsible for agreeing to a definition of
“done.” This exercise helps the team to understand what it means to call a user story
completed. While the definition of “done” can change over time, the Scrum Team should
strive to reach “done” with every user story.
Example of “done:” Code completed, Unit tests passed, system test passed, integration
  tests passed, code review completed, requirements signed off, and Product Owner reviewed

Product Backlog The list of requirements that are being developed continuously.  

Product Owner The Product Owner is chief representative of the business interests on the team. They are
empowered to make decisions in real-time for the team to keep moving forward. Product
Owners are expected to be dedicated to the release to ensure timely decisions are made.
 

Release Planning The objective of the Release Planning is to determine the hi-level scope, goal, timeline and
target sprints of the Release. We use adjusted velocity (user story points) provided by the  

development team to help forecast the release plan.

Sprint Retrospective This task is done at the end of the each sprint, usually in conjunction with the Sprint Review
meeting, to reflect on what we need to start working on, what could be improved upon and
what we need to keep up. The three groups, respectively, are "Start", "Stop", and
 

"Continue."

Scrum Master The Scrum Master is the chief facilitator/framework referee/team defender. The SM helps
the Product Owner and Cross-Functional team to produce the product. Their most
important jobs are to remove impediments for the team to keep them moving forward and
 

protect the team from outside "noise."

Sprint Planning The purpose of sprint planning is to prepare for the upcoming sprint,
and level-set on the features scheduled for the team. This meeting is a
chance for the development team to determine if the planned scope for
the sprint still is realistic and then identify any remaining open questions
in the sprint’s user stories.
Sprint Review The goal of the Sprint Review is to showcase what was completed
throughout the course of the sprint. Reviews take place at the end of
the each sprint, usually in conjunction with the retrospective meeting, to
show all team members what the developers have been working on.
The developers will walk through the specific user stories for this sprint.
The yes/no question to keep in mind during the Review is, "did we
implement what we said we were going to?"
Task These are the smaller parts of a User Story that a developer
determines. They are small pieces of work that need to be completed
for the User Story as a whole to be done. Tasks should be no more
than 8 hours in length.
User Story A user story is essentially a "requirement" that is an independent piece
of the release. User Story should contain just enough information that a
developer can pick it up and start working on it.