Dr.

Rupali Kalekar
Contents
3.1 Introduction and Definition Agile, Agile Project Life Cycle
3.2 Agile Manifesto: History of Agile and Agile Principles
3.3 Key Agile Concepts:
3.3.1 User stories, Story points
3.3.2 Product Backlog
3.3.3 Sprint Backlog,
3.3.4 Sprint Velocity
3.3.5 Swim lanes
3.3.6 Minimum Viable Product (MVP)
3.3.7 Version and Release
3.4 Agile Project Management v/s Traditional Project Management

Note: Case studies based on agile vs. traditional project

Extra Reading: Study Scrum Agile Framework, Agile project
management delivery & methodology framework, Software project
team management and different team structures
Dr. Rupali Kalekar
3.1 Introduction and Definition
Agile, Agile Project Life Cycle

Dr. Rupali Kalekar

Evolution of Project Management
Simple Comparison
Traditional Project Management Modern Project Management (Agile)
Elements impacting execution of a
project:
Elements impacting execution of a project:
a) Competitive environment
a) Planning
b) Creativity and Innovation
b) Control
c) Planning
d) Control
Project Success is measured by:
a) Delivery of Business Value (what does
Project Success is measured by having: customer want)

a) Well defined requirements Less important are:

b) Approved budget a) Having well defined requirements
c) On-Time Delivery b) Budget constraints
c) Set Schedule

Project Manager Role is distributed

among:
Requires a Project Manager a) Product Owner
b) Scrum Master
c) Project Team

Dr. Rupali Kalekar

History
 In 2001, this new management paradigm began to pick
up momentum, agile was formalized when 17 pioneers
of the agile methodology met at the Snowbird Ski
Resort in Utah and issued the Agile Manifesto.

Dr. Rupali Kalekar

What Is agile?

 Agile is a time boxed, iterative approach to software

delivery that builds software incrementally from the start
of the project, instead of trying to deliver it all at once near
the end.
 It works by breaking projects down into little bits of user
functionality called user stories, prioritizing them, and
then continuously delivering them in short two week cycles
called iterations.
Dr. Rupali Kalekar
 Agile model believes that every project needs to be
handled differently and the existing methods need to
be tailored to best suit the project requirements.
 In Agile, the tasks are divided to time boxes (small
time frames) to deliver specific features for a release.

 Iterative approach is taken and working software build

is delivered after each iteration.

 Each build is incremental in terms of features; the final

build holds all the features required by the customer.

Dr. Rupali Kalekar

How does it work?
You make a list:
 Sitting down with your customer you make a list of features
they would like to see in their software. We call these things user
stories and they become the To Do list for your project.

You size things up:

 You size(estimate) your stories relatively to each other,
coming up with a guess as to how long you think each user story
will take.

You set some priorities:

 Like most lists, there always seems to be more to do than time
allows. So you ask your customer to prioritize their list so you
get the most important stuff done first, and save the least
important for last.

Dr. Rupali Kalekar

You start executing:
 Then you start delivering some value.
 You start at the top.
 Work your way to the bottom.
 Building, iterating, and getting feedback from your customer
as you go.
 You update the plan as you go : Then as you and your customer
starting delivering one of two things is going to happen.

You'll discover:
 You're going fast enough. All is good. Or,
 You have too much to do and not enough time.
 At this point you have two choices.
 You can either a) do less and cut scope (recommended). Or you
can
 b) push out the date and ask for more money.

Dr. Rupali Kalekar

 Agile is a project management approach developed as
a more flexible and efficient way to get products to
market.

 The word ‘agile’ refers to the ability to move quickly

and easily.
 Therefore, an Agile approach enables project teams to
adapt faster and easier compared to other project
methodologies

Dr. Rupali Kalekar

Why Use Agile Methods
 Improve Customer Involvement
 Increase Quality
 Simplify Releases
 Drive Down Risk

Dr. Rupali Kalekar

Advantages of Agile model:
 Customer satisfaction by rapid, continuous delivery of
useful software.
 People and interactions are emphasized rather than
process and tools. Customers, developers and testers
constantly interact with each other.
 Working software is delivered frequently (weeks rather
than months).
 Face-to-face conversation is the best form of
communication.
 Close, daily cooperation between business people and
developers.
 Continuous attention to technical excellence and good
design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Dr. Rupali Kalekar

Disadvantages of Agile model:
● In case of some software deliverables, especially the
large ones, it is difficult to assess the effort required at
the beginning of the software development life cycle.
● The project can easily get taken off track if the
customer representative is not clear what final outcome
that they want.
● Only senior programmers are capable of taking the
kind of decisions required during the development
process.
Hence it has no place for newbie programmers, unless
combined with experienced resources.

Dr. Rupali Kalekar

 Understanding Agile
Agile is a time boxed, iterative approach to software delivery that builds
software incrementally from the start of the project, instead of trying to
deliver it all at once near the end.
It works by breaking projects down into little bits of user functionality called
User Stories, prioritizing them, and then continuously delivering them in
short two week cycles called Iteration

Dr. Rupali Kalekar

Agile Project Life Cycle
Key Principals : Change is inevitable. The project needs to adapt to it rather than
ignore it;
Delivering results is more important than established processes and tools;
Real customer’s needs take priority over the requirements in the development
plans.

Dr. Rupali Kalekar

1. Project Initiation
 The first stage in the life cycle of agile software
development.
 Often referred to as the inception or envision phase,
this initial stage is about discussing the project vision.
 This is high-level feasibility discussion and does not
delve into the specific details.
 During this step, you should identify team members
and determine the time and work resources are
required to complete the project.
 Taking stock of resources is crucial to determining
economic feasibility for project approval.

Dr. Rupali Kalekar

2. Planning:
 This phase is when the Agile lifecycle really takes shape for the
team.
 Release planning is where the team gets together with their
sponsor or product owner and identifies exactly what they are
looking for.
 They discuss how this will be made possible by building the
backlog at the story level.
 A good way to think about stories is how the end-user might
describe the feature or product.
 A story should include the type of user, what they want from
the product and why.
 The business opportunity in a wider context should be considered
here.
 This will impact how viable the project is in a functional and
financial sense
 You should be estimating the risks and developing milestones
with an initial release plan.
 Planning is only complete when your backlog is complete and you
have prioritized the items based on business value and
dependency.
Dr. Rupali Kalekar
3. Development:
 Once the requirements have been defined based on feedback
from the product owners and stakeholders, the actual work
begins.
 Agile product development delivers high quality working
products in incremental phases, sprints, or iterations.
 Developers start building the first iteration of the product with
the aim of having a working, usable product at the end of the
sprint.
 This is far from the final version and will undergo a number of
revisions so it should only include minimum functionality.
 This functionality can be expanded on in future iterations of the
Agile lifecycle.
 Teams can deliver in these sprints by:
 Ensuring Collaboration with their team and stakeholders.
 Maintaining quality by following coding conventions and style
guidelines.

Dr. Rupali Kalekar

 Adhering to priorities set by stakeholders who are given total control of
the scope, budget, and schedule of the project.
 Delivering working products however limited, at the end of every
cycle.
 Testing all the time!
 After as many sprints are needed to progress from a minimal viable
product in early sprints to be a fully functioning solution, it is now ready
to be released into production.
 At this point in the Agile lifecycle, you will have gone through several
iterations and hopefully conducted testing after each cycle. This is not
always the case though so you will need to allow for Final Testing.
 Final testing and acceptance should be carried out by quality assurance
(QA) to detect bugs. Unlike iteration testing, you might want to involve a
subset of end users for this testing.
 Following testing, there will almost definitely be some rework to address
defects that arise, so it’s important that this is accounted for in the
schedule.
 You might also want to train end-users or support staff but your main
goal is to deploy your solution into production.

Dr. Rupali Kalekar

4. Production:
 Your product has now been deployed and is being used
by final end-users.
 It is important to closely monitor these early stages for
bugs or defects missed in testing.
 A handover with relevant training should take place
between the production and support teams.
 These final processes and handovers are can vary
depending on the type of product you are outputting.
 The production phase typically ends when the product
is ready to be retired.

Dr. Rupali Kalekar

5. Retirement:
 The final stage of the Agile lifecycle.
 The product is now at the ‘end of life’ stage and will be
pulled from production and decommissioned
(sometimes referred to as ‘sunsetting’).
 Customers are notified and informed about migration to
newer releases or alternative options.
 Products are retired for a number of reasons.
 In most cases, it is because a newer release is being
deployed and (or) the older release is no longer being
supported. In this case, some final, minor software
updates may be made to the newer system.
 It could also be retired because the product is not cost-
effective within the current business model and
therefore phased out.

Dr. Rupali Kalekar

3.2 Agile Manifesto: History of
Agile and Agile Principles

Dr. Rupali Kalekar

History of the Agile Manifesto
 Although various agile principles have been around since the
1970s, the manifesto itself — and the full definition of the agile
philosophy — was created at the dawn of the new millennium.
 In early 2001, a group of 17 developers held two meetings — the
first in Oregon, the second in Snowbird, Utah — to discuss
issues and solutions in software development, which is how the
manifesto was firstborn.
 Put simply, the manifesto was written as a response to major
frustration with the traditional development processes of the
1990s.
 The explosion of personal computing meant that product and
software development had undergone significant changes, and
developers at the meetings — and indeed, across the wider
industry — felt that the status quo was no longer working.
 The lag time between business needs and solutions being
developed as an average of three years, and the standard processes
at this point were unwieldy, unsatisfactory and overburdened with
documentation and oversight.
Dr. Rupali Kalekar
 The 17 developers who met in Oregon and Utah named
themselves ‘The Agile Alliance’, and proposed a new way of
working based around a set of values and principles that
would “restore credibility to the word ‘methodology’”.
 The manifesto was designed to empower developers, to
speed up processes and to help encourage working
practices that focus more directly on the user.
 The values and principles allow teams to be adaptive, to
respond quickly and effectively to change, and to be in a
state of constant imagination underpinned by frequent
customer feedback.
 Published in February 2001, the manifesto has since formed
the basis of a vast array of frameworks, methodologies and
different ways of working.

Dr. Rupali Kalekar

This manifesto laid out four key values:
 Individuals and interactions over processes and tools.
 Working software over comprehensive documentation.
 Customer collaboration over contract negotiation.
 Responding to change over following a plan.

Dr. Rupali Kalekar

Dr. Rupali Kalekar
What Does The Agile Manifesto Say?
The Agile Manifesto outlines a set of 4 values and 12
principles for agile software development.
 The 4 Agile Values:
The agile mentality has 4 overarching values
differentiating it from traditional software
development processes.

Dr. Rupali Kalekar

What Is the History of the Agile
Manifesto?
 In February 2001, 17 software development practitioners gathered at a
ski resort in Utah. Of course, they were there to ski, relax, and eat and
drink. But most importantly, they were there to lament, pontificate,
and solve problems.
 Despite having widely varying opinions on the right way to approach
software development, the crew agreed on at least one thing: the status
quo was not working. There was an increasing need for an alternative to
documentation-driven and heavyweight software development
processes.
 The group named themselves “The Agile Alliance.” Out of their
gathering in Utah that winter came The Agile Manifesto, a brief
document built on 4 values and 12 principles for agile software
development.
 It’s important to note that agile in itself wasn’t born then. Before this,
its creators and many other software development practitioners had
long been applying various agile values and principles piecemeal. But
The Agile Manifesto made concrete the ideas that had been
permeating the software development world for the last decade or so.

Dr. Rupali Kalekar

Who Created the Agile Manifesto?
software practitioners from various backgrounds gathered to form the Agile Alliance who created The
Agile Manifesto. But who exactly were they? Here’s who signed the original Agile Manifesto back in 2001:

 Kent Beck, who co-created eXtreme Programming (XP)

 Mike Beedle, co-author of Agile Software Development with Scrum
 Arie van Bennekum, owner of Integrated Agile
 Alistair Cockburn, IT strategist and creator of the Crystal Agile Methodology
 Ward Cunningham, inventor of wiki and first to coin term technical debt
 Martin Fowler, software practitioner, and partner at Thought works
 James Grenning, author of Test-Driven Development
 Jim Highsmith, creator of Adaptive Software Development (ASD)
 Andrew Hunt, co-author of The Pragmatic Programmer
 Ron Jeffries, co-creator of eXtreme Programming (XP)
 Jon Kern, who still helps organizations with agile today
 Brian Marick, a computer scientist and author of several books on programming
 Robert C. Martin, also known as “Uncle Bob,” who consults via Clean Coding
 Steve Mellor, a computer scientist also credited with inventing Object-Oriented System
Analysis (OOSA)
 Ken Schwaber, who co-created Scrum with Jeff Sutherland
 Jeff Sutherland, the inventor, and co-creator of Scrum
 Dave Thomas, programmer, and co-author of The Pragmatic Programmer

Dr. Rupali Kalekar

The Twelve Principle of Agile Manifesto
 Customer Satisfaction: Manifesto provides high priority
to satisfy the costumer's requirements. This is done
through early and continuous delivery of valuable software.

How it looks in practice:

 Product teams use minimum viable products and rapid
experimentation to test hypothesis and validate ideas.
 Frequent releases help fuel a continuous feedback cycle
between customer and product.
 Shipped and done are not the same thing. Instead of
releasing a “finished” product, iterations continue to make
incremental improvements to product based on customer
and market feedback.
Dr. Rupali Kalekar
 Welcome Change: Making changes during software development
is common and inevitable. Every changing requirement should be
welcome, even in the late development phase. Agile process works
to increase the customers' competitive advantage.

How it looks in practice:

 Product teams are guided by high-level strategic goals and
perhaps even themes below those goals. The product department’s
success is measured against progress toward those strategic goals
rather than by delivery of a predefined feature set.
 Product constantly has its ear to the ground monitoring the
market, customer feedback, and other factors which could
influence product direction. When actionable insight is
uncovered, plans are adjusted to better serve customer and
business needs.
 Product strategy and tactical plans are reviewed, adjusted, and
shared on a regular cadence to reflect changes and new findings.
As such, product needs to manage the expectations of executive
stakeholders appropriately and ensure they understand
the why behind changes.

Dr. Rupali Kalekar

Deliver the Working Software: Deliver the working
software frequently, ranging from a few weeks to a few
months with considering the shortest time period.

How it looks in practice:

 Agile development cycles, often called “sprints” or
“iterations” break down product initiatives into smaller
chunks that can be completed in a set timeframe.
 Often this timeframe is between 2 and 4 weeks which truly
is a sprint if you consider the marathon-like development
cycles waterfall teams often follow.
 Another popular alternative to agile sprints is continuous
deployment.
 This method of shipping software frequently works less in
terms of predetermined time boxes and more in terms of
simply deciding what to do and doing it.

Dr. Rupali Kalekar

Collaboration: Business people (Scrum Master and
Project Owner) and developers must work together
during the entire life of a project development phase.

How it looks in practice:

 Cross-functional agile product development teams
include product people. This means that product is
represented on the development team and bridges the
gap between technical and business aspects of the
product.
 Daily update meetings, or standups, are one technique
many agile shops use to put this principle in practice
and keep everyone connected.

Dr. Rupali Kalekar

Motivation: Projects should be build around motivated team
members. Provide such environment that supports individual
team members and trust them. It makes them feel responsible for
getting the job done thoroughly.

How it looks in practice:

 Product must clearly ensure engineering understands strategy
and requirements before development starts. This means not
only sharing user stories with the cross-functional team but
also the bigger picture outlined in the product roadmap.
 Product is not responsible for explaining “how” something
should be built. They need to share what and why, but it’s the
delivery team’s job to determine the how. Furthermore, during
sprints product does not micromanage outcome, instead they
make themselves available to answer questions and provide
support as needed.

Dr. Rupali Kalekar

Face-to-face Conversation: Face-to-face conversation
between Scrum Master and development team and
between the Scrum Master and customers for the most
efficient and effective method of conveying information
to and within a development team.

How it looks in practice:

 Daily standup meetings
 Collaborative backlog grooming sessions
 Sprint planning meetings
 Frequent demos
 Pair-programming

Dr. Rupali Kalekar

Measure the Progress as per the Working
Software: The working software is the key and primary
measure of the progress.

How it looks in practice:

 Designing and releasing “Minimum Viable Features”
rather than fully-developed feature sets means
thinking first and foremost about the smallest things
we can ship to start getting customer feedback and
validate as we continue to build software.
 A fail fast mentality means moving forward even in
times of uncertainty and testing ideas rapidly.
 Ship software often: a useful product now is better
than a perfect one later.

Dr. Rupali Kalekar

Maintain Constant Pace(Bound): The aim of agile development
is sustainable development. All the businesses and users should be
able to maintain a constant pace with the project.

How it looks in practice:

 Before every sprint, careful consideration of the amount of work
that can be committed to is made. Development teams don’t over
promise on what they can and cannot deliver. Effort estimations
are a common practice in setting output expectations for
development teams.
 Everyone agrees on what will get done during a sprint. Once a
sprint has begun, no additional tasks are to be added except in
rare cases.
 Product managers should act as gatekeepers to reduce the noise
from other stakeholders and to avoid squeezing in additional
unplanned work during an ongoing sprint.
 Product people should do their part in promoting a sense of
psychological safety across the cross-functional team that
encourages open communication and freely flowing feedback.

Dr. Rupali Kalekar

Monitoring: Pay regular attention to technical
excellence and good design to maximize agility.

How it looks in practice:

 The team needs to be aware of technical debt and the
technical debt implications of any new features or
initiatives added to the backlog. Developers and
product need to work together to understand if and
when technical debt is acceptable.
 On a regular basis, product will need to allocate
development resources to refactoring efforts.
Refactoring cannot be an afterthought, it needs to be
an ongoing consideration.
Dr. Rupali Kalekar
Simplicity: Keep things simple and use simple terms to measure
the work that is not completed.

How it looks in practice:

 Product managers need to make very focused product decisions
and closely align product strategy with organizational goals
while being extremely picky about what user stories and features
actually make the cut. Using prioritization techniques to
prioritize initiatives by effort and predicted impact is one way
product teams can apply this agile principle to product
development.

 The short sprints that agile is characterized by present many

opportunities for rapid testing and experimentation which can
help reduce uncertainty around whether initiatives will truly
have the predicted impact. Using experiments to validate ideas
before building them up to spec is a great way to weed out bad
ideas and identify good ones.

Dr. Rupali Kalekar

Self-organized Teams: The Agile team should be self-
organized. They should not be depending heavily on
other teams because the best architectures,
requirements, and designs emerge from self-organized
teams.

How it looks in practice:

 Self-organizing teams are autonomous groups within
the organization who take control and responsibility
over their respective projects and have ownership of
those areas. Different organizations practice this
principle differently. Spotify, for example uses “product
squads” to practice this.
Dr. Rupali Kalekar
Review the Work Regularly: The work should be reviewed at regular
intervals, so that the team can reflect on how to become more productive
and adjust its behavior accordingly.

How it looks in practice:

 Experimentation and testing is not limited to the product only. Agile
teams are encouraged to experiment with their processes. You may
think you’re already doing something well only to experiment with a
revised version of the process and discover an even more effective
method. Experimenting with your process and team is just as
important as experimenting with the software you’re building.
 Regular retrospectives are opportunities for the team to discuss what
went well, what didn’t go so well, and where the process can be tweaked
to improve things in the future. They’re an excellent place for product
managers and product owners to learn if they are communicating
effectively with developers and giving them the support they need
before, during, and after sprints.
 Another consideration to make regarding this agile principle is that in
order to practice it effectively you need to create a culture of trust and
transparency that encourages openness and frequent sharing of
feedback

Dr. Rupali Kalekar

3.3 Key Agile Concepts:

3.3.1 User stories, Story points

3.3.2 Product Backlog
3.3.3 Sprint Backlog,
3.3.4 Sprint Velocity
3.3.5 Swim lanes
3.3.6 Minimum Viable Product (MVP)
3.3.7 Version and Release

Dr. Rupali Kalekar

3.3.1 User stories, Story points
 A user story is an informal, general explanation of a
software feature written from the perspective of the end
user.
 Its purpose is to articulate how a software feature will
provide value to the customer.

User stories typically follow the role-feature-benefit pattern

(or template):
As a [type of user],
I want [an action]
so that [a benefit/value]

Dr. Rupali Kalekar

 A key component of agile software development is
putting people first, and a user story puts end users
at the center of the conversation.
 These stories use non-technical language to provide
context for the development team and their efforts.
 After reading a user story, the team knows why they
are building, what they're building, and what value
it creates.
 User stories are one of the core components of an
agile program.
 They help provide a user-focused framework for
daily work — which drives collaboration, creativity,
and a better product overall.
Dr. Rupali Kalekar
What are agile user stories?
 A user story is the smallest unit of work in an agile
framework. It’s an end goal, not a feature, expressed
from the software user’s perspective.
 The purpose of a user story is to articulate how a piece
of work will deliver a particular value back to the
customer.
 User stories are a few sentences in simple language
that outline the desired outcome.
 They don't go into detail.
 Requirements are added later, once agreed upon by the
team.

Dr. Rupali Kalekar

Dr. Rupali Kalekar
Why create user stories?

EPIC Def:
An epic is a big idea or feature that can be broken down
into smaller user stories.

 For development teams new to agile, user stories

sometimes seem like an added step. Why not just break
the big project (the epic) into a series of steps and get on
with it? But stories give the team important context and
associate tasks with the value those tasks bring.
 User stories provide the essence needed to prioritize
them.

Dr. Rupali Kalekar

User stories serve a number of key
benefits:
 Stories keep the focus on the user. A To Do list keeps the team
focused on tasks that need checked off, but a collection of
stories keeps the team focused on solving problems for real
users.

 Stories enable collaboration: With the end goal defined, the

team can work together to decide how best to serve the user and
meet that goal.

 Stories drive creative solutions: Stories encourage the team to

think critically and creatively about how to best solve for an
end goal.

 Stories create momentum: With each passing story the

development team enjoys a small challenges and a small win,
driving momentum.

Dr. Rupali Kalekar

Story Points
 Story points are units of measure for expressing an
estimate of the overall effort required to fully
implement a product backlog item or any other
piece of work.

 Teams assign story points relative to work complexity,

the amount of work, and risk or uncertainty.

Dr. Rupali Kalekar

Why use Story Points?

 Story Points are intended to make team estimating

easier.
 Instead of looking at a product backlog item and
estimating it in hours, teams consider only how much
effort a product backlog item will require, relative
to other product backlog items.

Dr. Rupali Kalekar

reasons to use story points:
 Dates don’t account for the non-project related work that
inevitably creeps into our days: emails, meetings, and
interviews that a team member may be involved in.
 Dates have an emotional attachment to them. Relative
estimation removes the emotional attachment.
 Each team will estimate work on a slightly different
scale, which means their velocity (measured in points) will
naturally be different. This, in turn, makes it impossible to
play politics using velocity as a weapon.
 Once you agree on the relative effort of each story point
value, you can assign points quickly without much debate.
 Story points reward team members for solving problems
based on difficulty, not time spent. This keeps team
members focused on shipping value, not spending time.

Dr. Rupali Kalekar

What could include:
 The amount of work to do.
 The complexity of the work.
 Any risk or uncertainty in doing the work.

Dr. Rupali Kalekar

How to estimate user story points
When calculating story points, you're looking at the total
effort involved in making that feature or functionality live so
that it can deliver value to the customer. Your team will need
to discuss questions like:

 How complex is the work?

 How much work is needed?
 What are the technical abilities of the team?
 What are the risks?
 What parts are we unsure about?
 What do we need in place before we can start or finish?
 What could go wrong?

Dr. Rupali Kalekar

scales for sizing:

 1,2,4,8,16
 X-Small, Small, Medium, Large, Extra-Large
 Fibonacci sequence: 1,2,3,5,8,13,21

Dr. Rupali Kalekar

3.3.2 Product Backlog
In Agile development, a product backlog is a prioritized list of deliverables (such as
new features) that should be implemented as part of a project or product development.

Definition: A product backlog is the list of requirements requested by the customer.

The product backlog is not a ‘to-do’ list; rather, it is a list of all the features the
customer has requested be included in the project. The Scrum team uses the product
backlog to prioritize features and decide which ones to implement in upcoming sprints.

How It’s Used: The product owner is responsible for prioritizing Items in the
product backlog, referred to as Product Backlog Items (PBIs). The development team
pulls the highest-priority PBIs from the product backlog to complete during each sprint.
The product owner changes and re-prioritizes the backlog throughout the project
development process as needed.

Also Known As: backlog

Project Management Benefits:

 Communicates the priority of Product Backlog Items.
 Allows for longer term planning.
 Ensures the customer needs are being heard.
 Allows team membersDr.toRupali
pullKalekar
highest-priority items as needed.
 It is made up of all the Development Team’s ideas,
Product Owners, Stakeholders, etc.
 It acts as a source of requirements for the changes
that have to occur in the product.
 A Product Owner is a professional that handles the
Product Backlog and is solely responsible for
updating the Product Backlog.
 The Product Backlog is created whenever a product is
made.
 A Product Backlog is always an incomplete
document and continually changes as per the
necessity, needs, and the current demand.
3.3.3 Sprint Backlog
Sprint - sprint is a set period of time during which
specific work has to be completed and made ready for
review.

Definition
 The Sprint Backlog is a Scrum Artifact which
contains the Product Backlog items pulled into a
single Sprint, as well as the plan for the work needed
to deliver a usable product Increment.

Dr. Rupali Kalekar

 Sprint Backlog is a set of Product Backlog items
selected for the current Sprint, plus plans for
delivering product increments for achieving Sprint
goals.
 Sprint Backlog is the development team’s
expectation of what functions will be included in the
next increment and what work will be required to
deliver those functions.

 The Sprint Backlog defines what the development

team needs to do to convert the Product Backlog
Items into increments of “done”.
 The Sprint Backlog clarifies the work required by the
development team to achieve the Sprint goals.

Dr. Rupali Kalekar

Dr. Rupali Kalekar
What is the main purpose of the Sprint Backlog?
 The main purpose of the Sprint Backlog is to provide
the Scrum Team (and other stakeholders) with full
transparency of the work being done during the
Sprint.
 This transparency, in turn, allows for continuous
inspection and timely adaptation, as well as for
tracking the progress of the Sprint and estimating
whether the Increment will be “Done” by the end of
the Sprint.

Dr. Rupali Kalekar

What is included in the Sprint Backlog?

 The Sprint Backlog includes the Product Backlog

items that the Development Team agreed to complete
within the Sprint, the plan for doing this (including
discovery work, tasks, improvements, etc.) and at least
one process improvement.

 All new work that is identified as necessary

throughout the Sprint is also added to the Sprint
Backlog.

Dr. Rupali Kalekar

When is the Sprint Backlog created?

 The Sprint Backlog is created at the Sprint

Planning.

 However, it is not created as an exhaustive task list

that is set in stone for the entire Sprint.

 The Sprint Backlog is continuously updated and

modified throughout the Sprint in response to new
circumstances and the work that has already been
done.

Dr. Rupali Kalekar

 Who owns the Sprint Backlog?

 The Development Team owns the Sprint Backlog.

 They create the Sprint Backlog at the Sprint Planning

meeting and they are the only people who can make
changes to it throughout the Sprint.

Dr. Rupali Kalekar

When Applicable?

 The sprint backlog is applicable when a team is using

Scrum and working in timeboxed sprints.

 If a team is working in a flow approach (such

as Kanban) a sprint backlog is not necessary.

Dr. Rupali Kalekar

 The sprint backlog is a list of tasks identified by the
Scrum team to be completed during the Scrum sprint.
 During the sprint planning meeting, the team selects
some number of product backlog items, usually in the
form of user stories, and identifies the tasks necessary
to complete each user story.
 Most teams also estimate how many hours each task
will take someone on the team to complete.
 The sprint backlog is commonly maintained as a
spreadsheet, but it is also possible to use your defect
tracking system or any of a number of software
products designed specifically for Scrum or agile.

Dr. Rupali Kalekar

Sprint Backlog Tempalte

Dr. Rupali Kalekar

Difference Between Product Backlog and Sprint Backlog
Product Backlog
It is the list of all the items that need to be
completed so that the end product can be
developed.
The Product Owner is responsible for
collecting the Product Backlog items and
prioritizes and refines them.
The Product Backlog is specific to the entire
goal of the product.
May have chances to vary based on the vision
of the customer.
Dr. Rupali Kalekar
Sprint Backlog
It is the list of all the items that have been
taken from the Product Backlog and has to be
completed so that the Sprint is completed.
Also includes a plan on how the selected
items will be converted to an Increment.
The Development Team is responsible for
creating the Sprint Backlog and works on
them with a time frame to complete the
Sprint.
The Sprint Backlog is specific only to the
Sprint goal in a particular Sprint.
Sprint Goal will remain the same for the
Sprint while the Sprint Backlog may evolve
during the Sprint subject to the Sprint.
It is the entire set or list of work that
should be completed to develop the
product completely.
It is independent of the Sprint Backlog.
All the product features and story points
are assigned to each User Story
individually
Product Owner is solely responsible for
Product Backlog management.
Until the whole product is developed, the
Product Backlog remains and has to be
maintained.
Dr. Rupali Kalekar
It is a subset of the Product Backlog
and is completed during a Sprint.
It is purely dependent on the Product
Backlog.
The Sprint Backlog acts as a to-do list for
every Sprint. The Development Team
breaks the User Stories into individual
tasks such that the estimated time for the
completion of the task can be calculated.
The Development Team is solely
responsible for the Sprint Backlog
management.
Every new Sprint gets a new Sprint
Backlog which ends as the Sprint ends.
3.3.4 Sprint Velocity
 Velocity is a measure of the amount of work a Team can
tackle during a single Sprint and is the key metric in
Scrum.
 Velocity is calculated at the end of the Sprint by totaling
the Points for all fully completed User Stories.
 Velocity in agile development measures the quantity of
work a team can accomplish in a sprint.
 It can be measured in story points, hours or ideal days.
 Ideally, the higher a team’s velocity, the more software
functionality they are delivering, and the more value is
created for customers.
 Sprint velocity can be used in sprint project management
to evaluate and estimate team productivity.

Dr. Rupali Kalekar

Sprint 5 was exceptionally productive—the team produced almost 40
story points.

Dr. Rupali Kalekar

3.3.5 Swim lanes
 Swimlanes are normally used to separate your
project to-do lists into ordered, actionable, and easily
identifiable ‘faster/more important’ sections for
individual users or project areas.

Dr. Rupali Kalekar

How to Use Swimlane?
 Swimlane allows easy screening of data by classifying
it in different lanes.
 You can choose to view items by different
categories (Responsible, Release, Severity etc.).
 Swimlanes also help you to group data and offer
customized views for efficient analysis of your data.
 Swimlanes are available on different boards including
Scrum/Sprint, Kanban, Release, Issue Tracker (list
view) and Backlog board.

Dr. Rupali Kalekar

3.3.6 Minimum Viable Product (MVP)
Definition:
The smallest working product that can be built and tested
and delivered in a given time that provides value to users.
 A minimum viable product (MVP) is a concept from Lean
Startup that stresses the impact of learning in new product
development.
 the most minimally featured thing you can build that will
address the opportunity well enough for most of your target
customers and validate your market and product.
 A key premise behind the idea of MVP is that you produce an
actual product that you can offer to customers and observe
their actual behavior with the product or service.
 Seeing what people actually do with respect to a product is
much more reliable than asking people what they would do.

Dr. Rupali Kalekar

What is a Minimum Viable Product?
 A minimum viable product, or MVP, is a product with
enough features to attract early-adopter customers
and validate a product idea early in the product
development cycle.
 The MVP can help the product team receive user
feedback as quickly as possible to iterate and
improve the product.
 Because the agile methodology is built on validating
and iterating products based on user input, the MVP
plays a central role in agile development.

Dr. Rupali Kalekar

Dr. Rupali Kalekar
https://www.spaceo.ca/minimum-viable-product/

Dr. Rupali Kalekar

Expected Benefits
 The primary benefit of an MVP is you can gain
understanding about your customers’ interest in
your product without fully developing the product.

 The sooner you can find out whether your product will
appeal to customers, the less effort and expense you
spend on a product that will not succeed in the
market.

Dr. Rupali Kalekar

The Business Benefits of MVP

Dr. Rupali Kalekar

 Top 5 Examples of Minimum Viable Product
Sr. No. MVP examples How did they launch? Result

•An MVP was done just to connect students of schools and colleges all
together via messaging. Now it has over 2.6
1. Facebook •It was built on the basic model. billion monthly active
•Facebook was initially available only to students at Harvard University users.
who tested it and provided the user feedback.

•It opted for a unique software approach. It is now the 2nd largest
2. Twitter •It was initially known as “twttr” as an SMS based platform. social media site after
•It was for internal use only before it was released in 2006. Facebook.

•Originally the focus was on only selling online books. It is now the largest E-
3. Amazon •It launched in 1994 with the viable product development among the commerce site in the
users at a low price. world.

Afterward, it built its

•It initially came into being utilizing WordPress, where daily PDFs were voucher system and
4. Groupon sent to already registered customers with an idea of sharing and backend. Now it is
socializing. among the largest e-
commerce marketplace.

Dropbox received 70K

emails address from
•They used No product M.V.P meaning they created a video to explain potential users in a single
5. Dropbox
how it functions. day. Now it is among the
largest cloud storage
companies.

Dr. Rupali Kalekar

3.3.7 Version and Release
What is a version?
 A version is a set of features and fixes released
together as a single update to your product.

Versions in Scrum projects

 Assigning issues to versions helps you plan the order
in which new features (stories) for your application
will be released to your customers.

Dr. Rupali Kalekar

Release:
 A release is the distribution of the final version of an
application.
 Release planning is an interesting activity that
allows the development team to define the project
objectives, both interim and final, and to develop
their own release plan for every objective.
 In agile software development, a release is a
deployable software package that is the culmination
of several iterations.
 Releases can be made before the end of an iteration

Dr. Rupali Kalekar

3.4 Agile Project Management v/s
Traditional Project Management

Dr. Rupali Kalekar

Dr. Rupali Kalekar