AGILE

Contents
Understanding Users

Understanding Product

User Stories
Product Backlog & Planning

Estimation of Work

Prioritization
Reviewing & Adjusting

Agile Frameworks

Communication
Metrics & Measurements
Agile Transformation

Common Issues
• Primary Users: These are the users who will be using the product most frequently and are the primary focus
of the product design. They are the ones whose needs and goals should be prioritized in the development
process.

• Secondary Users: These are users who may use the product less frequently but are still important to consider
in the development process. They may include support staff, administrators, or other stakeholders who will
interact with the product in some capacity.
• Personas: Personas are fictional representations of your target users based on research
and data. They help to create a shared understanding of who your users are and what
their needs and goals are.

• User segments: User segments are groups of users who share similar characteristics or
needs. Understanding these segments can help you to tailor the product to their specific
needs.

• Non-users: Non-users are people who are not currently using your product but may
become potential users in the future. Understanding their reasons for not using the
product can help you to make improvements to the product that may attract them in the
future.
• User behavior is the set of actions and patterns that
users demonstrate when interacting with our product.
Tracking and analyzing user behavior will help us
evaluate what users find value in, and enable us to
improve their experience.

• User behavior focuses on metrics such as signups,

activation rates, feature usage and impact, funnel
drop-off for in-app purchases, and retention rates.

• User behaviour is definetly needed for the companies

to get promoted and turnover their sales
• Customer experience is everything, and user
behavior helps you understand, prioritize, and
improve the experience. Having this mindset is
essential for creating product-centric companies like
Netflix, Airbnb, Slack, and Peloton.
• These brands entered saturated markets in their
respective categories, but they offered unique
experiences that they kept improving based on user
behavior. As a result, they succeeded in standing out
from the crowd.
• Example :- If you make a transaction, you will win
scratch cards by branding the companies mentioning
discounts on (KFC) with an expiry date. If you get a
discount on KFC, you may prefer KFC than Burger
King.
Margin : Localities
Sales : 50%
Exsiting Customers : 40%
New Customers : less than 5%
Consumers : 5%
Marketing : Advertisements,Giving offers
only after they purchase

Margin : Localities
Sales : 80%
Exsiting Customers : 70%
New Customers : 10%
Consumers : 10%
Marketing : Intergrations with
platforms ,Understanding
market phsycology.
• Feature usage: Knowing what features users want can help you decide what features to build, add, or
remove.
• Element clicks and interactions: The more clicks an element (e.g., a button) gets, the more helpful it is for
users.
• Funnel drop-off during activation: Seeing a clear pattern of people abandoning your product can help you
resolve any issues.
• Stickiness ratio: Stickiness gives you insight into how many of your customers are returning to your product
or feature.
• Sessions per user: The number of instances a user used your product is an indicator of engagement.
• Adoption rate: The percentage of users who make use of a new feature you shipped.
• Activation rate: The rate at which your onboarding is successful in getting new users to perform the first
key actions in your product, such as setting up the first chart in a data visualization tool.
• Activation Rate: The rate at which your onboarding is successful in getting new users to perform
the first key actions in your product, such as setting up the first chart in a data visualization tool.
• Referral Rate: Indicates how well your product or its features are able to motivate users to
introduce it to others.
• Churn Rate: The percentage of users you lost during a time period. Losing users is common, but
can be minimized when managed right.
• MRR and ARR: The monthly and annual revenue your product generates.
• Retention rate: Measures how many users return to your platform—and with the right behavioral
data, also reveals why.
• For Example: the retention rate shows how many people keep paying for your
product. If you combine it with the stickiness of a feature, you may be able to
see which of your features help users want to keep paying you.
• Launching too many new features simultaneously. You end up creating far too much work for yourself.
Monitoring one feature alone takes Launching too much at one time
could muddle the whole picture or make the analysis ineffective.

• Not involving every team in analytics usage. Product analytics is not just for product teams and data
scientists. removes bottlenecks that prevent other teams (UX/UI design, marketing,
sales, support, leadership) from contributing to the user journey. Customer-facing teams, for instance, are
often excluded.

• Initially tracking too many events with your analytics tool. Focus only on key events at the beginning, so
you’ll see which ones make more impact. Our recommendation is to instrument 20 to 30 events in the
initial phase. If more events come up, you can always add them later on.
q Persona is created to help the team visualize and understand an ideal user.

q Agile personas represent fictional characteristics of the people that are most likely to buy your product.

q Personas provide a detailed summary of your ideal customer including demographic traits such as location, age, job
title as well as psychographic traits such as behaviors, feelings, needs, and challenges.
When the team gives a face to this ideal user and write information about him/her

• Team gets to know the ideal user better.

• Team gets to know what motivates the ideal user.

• It helps the team think through and make the right choice about how and what to develop.

• helps make the uses stories more relatable and personal.

• Interview or survey enough users to be able to create a profile and start thinking like them.

• The goal and frustrations should be the common to Several answer before they are entered in the profile

• This exercise help the team think about terri's opinion when they're taking a decision on designing a feature
• Conducting user research in an agile environment can be challenging but is crucial for delivering
successful products. Here are some tips for conducting user research in an agile environment:
• Involve users early and often: In an agile environment, it's important to involve users in the
product development process from the beginning. Inviting them to participate in product design
sessions and testing sessions helps to ensure that their needs are considered throughout the
development process.

• Prioritize research based on product backlog: Prioritizing research activities based on the
product backlog can help ensure that the research is aligned with the goals of the product
development team. This can also help the team to make informed decisions about which
features to include in the product.
• Use lightweight research methods: In an agile environment, it's important to use lightweight
research methods that are quick and easy to conduct. Methods such as online surveys, interviews,
and usability testing can be conducted quickly and provide valuable insights.

• Share research findings frequently: Sharing research findings frequently with the development
team and stakeholders can help ensure that the research is informing the development process.
This can also help the team to make decisions quickly based on user feedback.

• Continuously iterate based on research findings: This means that the development team should
be prepared to make changes to the product based on user feedback and research findings.
 A G I L E

Understanding your
Product
MOHD ABDUL MUQTADIR
PARISMITA PANIGRAHI
Agenda:
a) Product types
b) MVP
c) Difference between MVP and Prototype
d) Product metrics - what to measure
e) A/B testing and product experimentation
Product: In agile development, product is a
software application, tool, or system that is
designed and developed to meet a specific need
or solve a particular problem

It is typically developed in iterative releases,

each of which adds new functionality or
improves existing features. Each release is a
usable product.
Service: In agile development, service is a
capability or function that is provided by a software
application or system

It is also developed in iterative releases, Services

can include functions such as user authentication,
payment processing, data storage, or email
notification.
A product is a complete solution that
addresses a specific need or problem,
while a service is a component or function
that is part of that solution.

• For example, a product could be an e-

commerce website that allows customers
to purchase products online, while a
service within that product could be the
payment processing function that
handles online transactions.
Minimum Viable Product (MVP): This is a product that
contains only the most essential features needed to
meet customer needs. It is designed to be developed
quickly and launched as soon as possible, with the goal
of gathering feedback from customers and using that
feedback to iterate and improve the product.

Incremental Product: This is a product that is developed

in small, incremental stages, with each stage adding new
features or functionality to the product. Each increment
builds on the previous one, and the product is released in
stages as each increment is completed.
Iterative Product: This is a product that is
developed through a series of iterations Each
iteration builds on the previous one, and the
product is refined and improved through each
iteration.

Lean Product: This is a product that is developed

using lean principles, which emphasize reducing
waste and maximizing value. Lean products are
designed to be developed quickly and efficiently,
with a focus on delivering the most value to
customers with the least amount of waste.
MVP is the smallest version of a product
that can be released to the market and still
provide value to the users. The purpose of
an MVP is to test the viability of a product
idea and to gather feedback from real users
as early as possible
The concept of MVP is a key component of
the agile development methodology, which
can add atleast 1 exciting feature to the
product with every release to delight the
customers.
A prototype is a skeleton version that is
made available to the stakeholders for
internal review on the look and feel of the
application
It is to visualize a product and show it to
stakeholders

MVP is a ready-to-launch version of the

product that can be iteratively improved
based on user feedback
It is to provide a short-form functional
version of the product that can be launched
on the market
• Product metrics refer to the quantitative
measurements used to assess the
performance of a product, and make
data-driven decisions to improve the
product.
• Product metrics are data that capture
the ways customers or users interact
with your digital app or product, and
show how those interactions affect your
business. They ’re used by product,
marketing, customer success, and
analytics teams to get insight into the
success of a product or website.
• Customer satisfaction: Feedback from
customers or users about the product,
its usability, and its features. It also
called Qualitative Metrics.
• User engagement: Metrics that
measure how users are interacting
with the product, such as active users,
time spent on the product, and user
retention. It is comes under the
quantitative metrics
Business Metrics
Monthly recurring revenue (MRR)
MRR = Number of customers x amount each
customer pays per month.
Customer Lifetime Value (also known as CLTV, CLV, or
LTV)
Average Order Value x purchase frequency x
customer lifespan
If the average customer makes two $40 purchases
each year, and does this for five years, your CLV is $40 x
2 x 5 = $400.
Customer Acquisition Cost (CAC)
CAC = Total cost (marketing + sales)/Number of new
customers
Churn rate
Churn rate = (Number of users beginning – Number
of users end)/Number of users beginning
Engagement metrics
Adoption rate
Adoption rate = (Number of new users / Total number
of users) x 100
Daily Active User/Monthly Active User (DAU/MAU)
Ratio = (DAU/MAU) x 100
Conversion rate
Conversion rate = number of conversions / the total
number of visitors
Sessions per user
Number of sessions per user = Sessions / Total users
Net Promoter Score (NPS)
Promoters (score 9-10): love your product or feature
Passives (score 7-8) are satisfied but not enthusiastic
Detractors (score 0-6) are actively unhappy with your
product or feature
NPS = Percentage of promoters – Percentage of
detractors
• Acquisition: It tracks the success and costs of your acquisition efforts, these are the strategies in
place to recruit potential customers.
• Activation: It measures the rate at which your customers 'activate', or reach the point where
they understand your product's value and are ready to take action
• Retention: It measure how well your business retains customers and how satisfied those
customers are throughout the entire customer journey
• Referral: This set of metrics tracks the referral actions taken by your customers. It can be share
button or refferal programme.
• Revenue: These metrics result from the actions of your customers and how they affect your
bottom line. It will help to design or redesign the strategy.
• Acquisition:
Acquisition rate = Number of users acquired / specified
time period
• Activation
Activation rate = Number of activated users/ Total number
of users
• Retention:
Retention rate = Number of continuing users / Number of
customers you started with
• Referral:
Referral rate = Number of referred purchases / Number of
total purchases
• Revenue:
Monthly Recurring Revenue (MRR), Average revenue per
user (ARPU),Customer Lifetime Value (CLTV).
• I t ’s a s c i e nt i f i c a p p ro a c h to p ro d u c t
management, geared towards understanding
how customers use your products and
identifying ways to improve them.
• Great products are built on experimentation.
It helps product teams spot specific ways to
improve the user experience (UX) and deliver
small incremental changes that have a big
impact.
• A/B testing: This UX research method implies running two
different versions of a product, website, app, or feature to
determine which performs best.
• Multivariate testing: similar to A/B testing, but with multiple
variables changing at the same time. This methodology is
most useful when you have alternatives with multiple
components, and you're trying to find a combination of
variables to drive the results you’re looking for.
• Funnel testing: Another variation of A/B testing, this method
involves making changes across multiple pages to see how
users flow through various stages of the customer journey.
This is most useful when you have components that need to
stay consistent across pages (like navigation) or are testing the
user journey (like introducing new paths or shortcuts).
• Split testing: similar to A/B testing, except instead of having
the two web pages or website variations competing against
each other, the traffic is equally split between the existing
variations. This methodology is mainly used in instances
where changing all assets at once can be costly, and there are
potential SEO penalties for having multiple versions of the
page.
Understanding User Stories

Suprava Das
Parismitha
 CONTENTS
User stories INVEST criteria

User story mapping Definition of READY and

Definition of DONE

Acceptance criteria Epics and Spikes

Understand the User
Mindset
• To write user stories, you need
to understand the user's
mindset. What are their goals?
What are their pain points?
What would make their
experience better? Keep the
user's perspective in mind when
writing user stories and focus on
delivering features that provide
value to them.
Some sample of user stories
“As a user, I want a new feature added to the product so it can save me more time.”
In this case, we’ve got a faceless user, basically zero context, and a very vague
story. To improve this user story, we could be specific about the user's persona,
add at least the type of feature they’re looking for, and better define their end
goal.

As a product manager, I want an AI-powered to-do list so I can get more done.”
This user story clearly focuses on specific features and not goals. An AI-powered
to-do list may be one way to address this story, but that’s up to the development
team to decide. This user story is also an example of vague acceptance criteria.
What exactly does “get more done” mean?
 What are user stories
• A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.
• The 3-Part User Story Template
• Who : As [persona]
• What : I want [Objective]
• Why : so that I can [Value]
• Examples:
• An online gamer: Persona
• As an online gamer, I want to have a multiplayer option so that I can play online with friends.
• An e-commerce shopper: Persona
• As an e-commerce shopper, I want to filter my searches so I can find products quickly.
 Common Mistakes in writing user stories
Benefits of user • Role not defined – The first part of writing any user story is defining
the role of which this is being written.

stories • Extreme focus on the title or description – User stories are a short
description of features that a customer needs. The title of the user
story should be short around 3 to 10 words and at the same time
should be simple.The purpose of the title is to distinguish a particular
• Easier to Prioritize story from other.
• Simplified format • No appropriate slicing of stories – User stories can incorporate
different levels of details. Some stories are too long that they become
• Increased flexibility vague for the team when understanding and implementing them. It is
recommended to start with Epics, which are normally long format
• Improved collaboration user stories and more detailed. These epics can then be split into
detailed user stories specific to features.
• Acceptance criteria / Condition of Satisfaction – As epics further break
into smaller stories, it is important to add Acceptance criteria to it.
These criteria’s are set of statements, each has a clear pass or fail
result. They specify both functional and non-functional requirements
applicable at the current development lifecycle of the product or
project. Acceptance criteria have conditions of satisfaction and there
is no partial acceptance.
• Writing technology and not features – User stories should be feature-
centric and not talk about the technology in specific.
 Theme vs Epic vs User Story vs Task
Products are typically described by hundreds of
requirements which are organized in the product backlog.
Theme or epics cannot be completed in one sprint so they
are broken into more user stories and subsequently a group
of related tasks. Epics are then delivered in releases.
• Theme/user Feature: A theme provides a convenient way
to indicate that a set of related epics have something in
common, such as being in the same functional area.
• E p i c : An E p i c i s u s ef u l a s p l a c e h o l d e rs fo r l a rge
requirements. It probably won’t fit into a sprint and should
be broken down into stories.
• User Stories: User stories are the smallest units of user
functionality in agile which can be delivered in one agile
sprint.
• Tasks: Tasks are decomposed parts of a story that get into
HOW the story will be completed. Tasks can be hour
estimated if desired. Tasks are usually defined by the
people doing the work (developers, QA, etc), whereas
stories and epics are generally created by the customer or
the product owner on behalf of the customer.
User story mapping
• User story mapping is a visualisation strategy that
agile teams often use to outline the expectations
and strategies to achieve the set goals. It uses
sticky notes or sketches on whiteboards to outline
all the steps in the production process and the
members responsible.

• User story mapping is a useful way to organize and

prioritize your user stories so that you can schedule
your work and design your releases.

• It helps you visualize the customer’s journey through

your product from start to finish, including all the
tasks they’d normally complete along the way.

• The 3-level story map involves three compartments:

Activities > Tasks > Stories
 Acceptance Criteria
• Acceptance criteria s a formal list that fully narrates user
requirements and all the product scenarios put into the
account. It plainly describes conditions under which the
user requirements are desired, thus getting rid of any
uncertainty of the client’s expectations and
misunderstandings.
HOW TO WRITE ACCEPTANCE CRITERIA:
• Scenario -> Given -> When -> Then
• Scenarios: All the actions a user could take
• GIVEN: Sets the context. What page are we on and what
state are we in? Is the user an admin? Signed-in? Has
created a campaign?
• WHEN: What actions the user is performing. What event
occurred?
• THEN: What should the system do in response? What is
the expected outcome?
 INVEST Criteria
• I t u s e fo r eva l u ta i n g t h e u s e rsto r i e s
correctness.
• Under the INVEST criteria, good user stories
are:
Independent
Negotiable
Valuable
Estimable
Small
Testable
Example Scorecard
User story 1 Independent ✔

As Fiona Film-Fan, I want to be able to see what Cinerama is offering, so I can Negotiable ✔
decide if I’ll go there.
Valuable ✔
Acceptance criteria:

homepage is created showing our name, tagline, address, email address and phone Estimable ✔
number (see attachment to the story for these details)
Small ✖
homepage lists the movies that are ‘now playing’

the list includes the title, rating, genres, description, cast and crew, and session times Testable ✔
for each movie (see attachment)

the list can be filtered by title and rating

Max Manager can update the ‘now playing’ movies as they change
Notes on the scorecard
The story is not as small as it could be.

Improving the story: You could split the story and initially do only the first acceptance criteria. A website with
your name, slogan (summing up your point of difference), address and contact details will let Fiona Film-Fan
decide if the theatre is right for her and then get in touch to find out what’s playing. By keeping the story as
small as possible, you make it easier to deliver value in a single Sprint.
 Definition of READY Definition of Done (DOD)
• DOR refers to the Definition of Ready in Agile. In the Agile • The DoD is a contract between the product owner and the team.
Scrum framework, the Definition of Ready describes the
requirements that must be met in order for a story to move
from the backlog to development.
• The definition of done (DoD) is when all conditions, or acceptance
criteria, that a software product must satisfy are met and ready to
• Definition of Ready - that are commonly referred to as the
“INVEST criteria”. be accepted by a user, customer, team, or consuming system.

• DoD can be focus on many level:

• USER STORIES - Unit tests passed, Code reviewed,

Acceptance criteria met, Functional tests passed, Non-
Functional requirements met, Product Owner accepts the
User Story

• FEATURES - Acceptance criteria met, Integrated into a

clean build, Promoted to higher level environment,
Automated regression tests pass, Feature level functional
tests passed, Non-Functional requirements met, Meets
compliance requirements, Functionality documented in
necessary user user documentation

• EPICS - Non-Functional requirements met,End-to-end

integration completed,Regression tests pass, Promoted to
production environment, Meets defined market expectations
 Definition of READY
• I (Independent). The PBI should be self-contained and it
should be possible to bring it into progress without a
dependency upon another PBI or an external resource.
• N (Negotiable). A good PBI should leave room for
discussion regarding its optimal implementation.
• V (Valuable). The value a PBI delivers to stakeholders
should be clear.
• E (Estimable). A PBI must have a size relative to other
PBIs.
• S (Small). PBIs should be small enough to estimate with
reasonable accuracy and to plan into a time-box such as
a Sprint.
• T (Testable). Each PBI should have clear acceptance
criteria which allow its satisfaction to be tested.
Definition of Done (DOD)
• Definition of Done for a feature
( user story or product backlog
item)
• Definition of Done for a sprint
(collection of features developed
within a sprint)
• Definition of Done for a release
(potentially shippable state)
 Epic
As a Online Seller
I can manage my products online
so i can keep my product up to date for customers

Adding Updating Deleting Hiding

As an online seller, As an online seller, As an online seller, As an online seller,
I can add new products, I can update existing I can delete products, I can hide products,
so that customers have products, So i can remove So they could not be
purchase options So i can adjust for products that i don’t sold when out of stock
changes in pricing sell anymore
Spike
Definition of a Spike in Agile
Spike is the name for a timeboxed user story or Task that is created in
order to research a question or resolve a problem. Spikes focus on
gathering information and finding answers to a questions, rather
than producing a shippable product.
Spikes
Use of Spikes:
• A Spike is created when a user story or task cannot be estimated well enough until the team has
done further research or investigation. The result of a spike is an estimate for the original user
story so that the sprint can move forward.
Benefits of Spikes:
• Enable the team to make more accurate and reliable user stories.
• Increase the team’s understanding of a user story or PBI requirement.
• Reduce waste.
- Sudhindra & Pavan Kumar
Contents
• What is Product Backlog?
• Product Backlog Hygiene
• Product Vision & Agile Planning
• Product Roadmap & OKR’s
• Planning Cycles
• Daily Planning & Daily Stand-ups
• Conclusion
 Product backlog and planning

A product backlog is a prioritized list of work for the development team that is derived from the
roadmap and its requirements. The most important items are shown at the top of the product backlog
so the team knows what to deliver first.
It is an essential component of agile software development methodologies, such as Scrum, and is
maintained by the product owner.The items at the top of the list are considered the highest priority and
should be developed first. As the team works on the backlog, the product owner may add, remove,
or re-prioritize items based on user feedback, market changes, or other factors.
Backlog Prioritization
The method is a popular prioritization technique for mananging requirement which frequently used within
Agile Project Management.
The MoSCoW method is used to identify and classify the requirements of a project or product. Each requirement
is assigned to one of the four categories based on its importance to the project's success.

The four categories are defined as follows:

Must have: These are requirements that are essential to the

success of the project. If any of these requirements are not met,
the project will be considered a failure.

Should have: These are important requirements that are not

essential to the success of the project, but are highly desirable.
These requirements should be met if possible.

Could have: These are requirements that would be nice to have,

but are not essential or highly desirable. These requirements may
be postponed or dropped if necessary.

Won't have: These are requirements that are not necessary or

desirable for the project. These requirements will not be included
in the project.
A healthy backlog denotes the level of detail in your product backlog that the development teams and mainly product
owners need for the project to be successful. It is vital to establish a sufficiently detailed backlog.Product backlog hygiene
is the practice of keeping the product backlog in a clean, organized, and manageable state. This is important to ensure that
the backlog remains useful and relevant, and that the development team can efficiently work on the highest-priority items.

DEEP which is very essentail for Product Backlog.

Product vision and Agile Planning:-

In Agile, a product vision is a high-level description of the future state of a product or a service that guides
the product development team in making strategic decisions. It provides a clear picture of what the team
aims to achieve and why it is valuable to the target users or customers.

Product vision statement describes why a product is made, who it's for, and what makes it different.

It is a decision-making artifact that helps you estimate, refine, and prioritize everything you might sometime
in the future want to complete.

It serves as a guiding principle for the development team and provides

direction and clarity for the product owner and stakeholders.

In agile development, the product vision is typically expressed

in the form of a product vision statement. The product vision
statement is a short and concise statement that communicates
the product's purpose, target users, and unique value proposition.
It should be easy to understand and should inspire and motivate
the development team.
Product roadmap and OKRs:-

Objectives and Key Results (OKRs) is a time-bound agile framework for setting goals and KPIs for the
broader organisation and specific teams. A roadmap is a visualisation of your strategic plan to achieve
your objectives.

Agile Product Roadmap

Understand your Product Vision.

Find the right amount of flexibility.

Inspire a discussion around team goals.

Communicate your agile product roadmap at the right

level.

Make the most of your agile product roadmap.

Focus on outcomes over features.

Agile development involves iterative and incremental development cycles, also known as sprints, which
typically last between one to four weeks. Within each sprint, the development team plans, designs, develops,
tests, and delivers a working product increment.

In addition to sprints, Agile methodologies have several planning cycles that help ensure that the development
team remains focused on delivering value and stays aligned with the product vision and business goals.

Planning cycles in Agile are used to plan and prioritize work in a flexible and adaptive manner. Scrum is one of
the most popular Agile frameworks used for software development, which includes specific planning cycles.
A daily stand-up meeting in Agile is an opportunity for the project team to discuss a project's progress at a
high level.These meetings last 15 minutes and allow each contributor to report on their accomplishments
since the last stand-up meeting. It helps ensure everyone is aligned and knows what's going on.

Daily Planning:
Daily planning is a process where the development team reviews the tasks that need to be accomplished
in a day to achieve the sprint goal. The team members collaborate and identify the tasks to be
accomplished during the day. This daily planning helps the team to stay on track and meet the sprint goal.

Daily Stand-ups:
Daily stand-ups, also known as daily stand-up meetings or
daily scrums, are short daily meetings that help the team to
stay aligned and focused on achieving the sprint goal. The
meeting usually lasts for 15 minutes and happens at the
same time every day.
Estimation
Of Work
- Shashikanth
Table Of Contents
What is Estimation Why Do we need Estimation

Types of estimation’s Story points overview

Story points where to Velocity and predictability

start
What is Estimation
Software development estimation is a process by which
one can accurately determine the amount of effort, as
in time and money, necessary to deliver or maintain a
software-based project.

In terms of building a software , Estimation is an

important process where the development team comes
together and estimates the time it would take them to
build a certain feature, release a product etc.
Estimations are usually done in story points, days or
hours.
Estimate

Is relative and Approximate.

Is Not Absolute and Final.

Why Do We Need Estimation

• It provides us a way to calculate how much time a

feature may take to complete

• It allow us to do planning — both short term and

long term planning

• It provides the inputs so as to forecast future

milestones and plan future events.

• It also provides a way for businesses to determine

the cost of building a feature.
Types of Estimation Techniques

1. Planning poker

2. T-shirt sizing

3. The bucket system

4. Affinity mapping

5. Random distribution

6. Dot voting

7. Big, uncertain, small

8. Top-down estimate

9. Bottom-up estimate

10. Three-point method

Planning Poker T-Shirt Sizing
 Planning poker
Planning poker is a card-based system of collaborative
Agile estimation. During a planning poker session, each
member of the team uses a set of cards with different
values for the time, resources or other considerations
when estimating an Agile project. A leader then names a
project or component of a project for the group to discuss
for estimation.
Each member of the discussion chooses one of their cards
that they feel best represents the estimated cost of the
project. Everyone then shares their selected cards and
discusses why they chose them. Through this process, the
team comes to a consensus on the final estimation for the
project or component.
T-shirt sizing
T-shirt sizing is a simple sorting process a team may use for Agile
estimation. In a T-shirt sizing plan, a team assesses each
component for estimation, assigning a designation according to
common T-shirt sizes ranging from extra small to extra large.
Using this system, a team performing an estimation assesses
each project or component under consideration. The group
discusses each item when presented, then decides on a
consensus placement for the item. This allows the team to sort
components or projects by size and provides an overview of the
expected work ahead.
Bucket System
The Bucket system

In this technique, the facilitator creates numerous buckets, or categories, represented by pieces of paper.
Each bucket has a number corresponding to the level of difficulty or the time required for project tasks.
Longer and more challenging tasks go in higher-numbered buckets, while shorter and easier tasks go in
lower-numbered buckets.

The facilitator begins by placing one task, typically written on a sticky note, in a bucket based on the task's
projected time or difficulty. Participants assign tasks to different buckets, with the goal of each bucket
holding similar tasks. Teams may discuss each task during the process or wait until all the tasks are in a
bucket. The assignment concludes when participants place all tasks in the buckets and the team has had
enough time to discuss each one.
Story Points Overview

Story points are units of measurement used to

determine how much effort is required to complete a
product backlog item or any other piece of work. The
team assigns story points based on the work's
• Complexity
• Amount Of Work
• Risk Or Uncertainty.

Story points in Agile are abstract measurements that

developers use instead of hours. Points are relative
values, so a story with a value of three is thrice as
hard as a story with a value of one.
Story Points Matrix
Story Points Where To Start

1. Introduce story points to your team

2. Determine your story point sequence

3. Create a story point matrix

4. Hold a planning poker meeting

5. Plan and execute your sprint

6. Improve your story point estimations based on previous estimations

Velocity and Predictability

Team Velocity

Team velocity refers to the amount of work a team can complete in a given iteration, typically measured in story
points.
It's a measure of the team's productivity and can be used to estimate how much work the team can complete in
future iterations.

Predictability

Predictability, refers to the team's ability to accurately forecast the amount of work they can complete in an
iteration.
A team with high predictability is able to consistently meet their commitments and deliver on time.

To improve predictability, teams should focus on improving their estimation techniques, identifying and
addressing bottlenecks in their process,
and regularly reviewing their performance to identify areas for improvement.
Agile Prioritization
by-bhanu charan
Agenda
What is Prioritization

1. Agile prioritization is the process of determining and ranking the order in

which tasks or features should be completed within an agile project.

2. This is typically done by considering the value that each task or feature brings
to the project and the effort required to complete it, as well as any dependencies
or constraints that may affect the prioritization.
 How to do it
(Prioritization Factors)

The cost of developing The next factor to be

the requirements is considered in prioritization is
another essential factor the amount and significance
to be considered by the of knowledge and
product owner. Value capabilities that the team will
and cost together gain while working on the
indicate the RoI for the requirements.
requirements

Understanding the
level of risks involved
The financial value of the requirements in introducing the new
is a major factor to be considered in features is essential in
prioritizing requirements. The value the process of
could be expressed as new revenue, prioritization.
incremental revenue, or as operational
efficiency.
Value vs. Cost
How to evaluate the value of a feature?

Quantify the opportunity size of an initiative or feature and conduct a qualitative

viability assessment to identify which opportunities are worthwhile to the customer
and to the business long-term.

1. Scale of Impact
2. Exposure
3. Viability
Value of Feature

Quantify Scale of Impact Quantify Exposure Uncover Viability

Value vs. Cost
How to evaluate the cost of a feature?

1. Quantify Engineering Effort

The cost of a feature or initiative is primarily informed by engineering effort in the form
of story points, developer weeks, or developer units. Are there dependencies that will
cost both the PM and the developers time?

2. Consider Tradeoffs

It should also be in some parts influenced by opportunity costs. What must the
business or team give up, in terms of customer deliverables or milestones, in order for
the particular feature in question to be realized?
Cost of Feature

Engineering Effort Trade Offs

 PrioritizationTechniques

• 5 W/ 5 WHY’S
• Weighted Averages
• Kano Method
 5 Whys: The Ultimate Root Cause Analysis Tool

• Use the 5 Whys technique to find the root cause of a problem quickly.
• Unpredicted problems occur in any team or process. However, problems are just symptoms of
deeper issues. Fixing a problem quickly may be a convenient solution; however, it doesn’t protect
your work process from recurring mistakes. This is why your team needs to focus on finding the
root cause and tackling it properly. The good news is that there's a simple yet powerful tool that
can help you get to the bottom of any problem: the Five Whys analysis process.
 Origin of 5 Whys

• The 5 Whys method is part of the Toyota Production System and an essential approach to problem-
solving. Developed by Sakichi Toyoda, a Japanese inventor, and industrialist, the technique became
an integral part of the Lean philosophy.
• "The basis of Toyota’s scientific approach is to ask why five times whenever we find a problem … By
repeating why five times, the nature of the problem as well as its solution becomes clear." Taiichi
Ohno
• The root cause analysis process should include people with practical experience. Logically, they can
give you the most valuable information regarding any problem that appears in their area of
expertise.
 What Is a 5 Why's Example?

• When applying the 5 Whys technique, you

want to get to the problem's essence and
then fix it. Actually, the 5 Whys questions
may show you that the source of the
problem is quite unexpected.

• Often, issues that are considered technical

problems actually turn out to be human
and process problems. This is why finding
and eliminating the root cause is crucial if
you want to avoid iteration of failures.
 Here is an example of applying the 5 Whys.

• Problem: We didn’t send the newsletter about the latest software updates on time.
• Questions:

1. Why didn’t we send the newsletter on time? Updates were not implemented until the deadline.
2. Why were the updates not implemented on time? Because the developers were still working on
the new features.
3. Why were the developers still working on the new features? One of the new developers didn’t
know the procedures.
4. Why was the new developer unfamiliar with all procedures? He was not trained properly.
5. Why was he not trained properly? Because CTO believes that new employees don’t need
thorough training and they should learn while working.
 What Is a Five Why’s Template?

• What is the problem?

• Why did the problem occur?
• Why did the reason in question 2 happen?
• Why did the reason in question 3 happen?
• Why did the reason in question 4 happen?
• Thanks to the iterative nature of the model and by answering these questions in sequence, you
can trace the problem back to its root cause and develop effective solutions to address it. You may
include additional questions or tailor the template to align with specific types of problems and
requirements.
 Kano Model

What is the Kano Model?

• The Kano Model (pronounced “Kah-no”) is an approach to prioritizing features on a product
roadmap based on the degree to which they are likely to satisfy customers.
• Kano can help teams determine which features will satisfy and even delight customers.
• Product managers often use the Kano Model to prioritize potential new features by grouping
them into categories
• These feature categories can range from those that could disappoint customers to those likely to
satisfy or even delight customers.
• The Benefits vs. Cost Model, for example, might use customer satisfaction among its scoring
criteria but might also use different criteria, such as increased revenue. With the Kano Model, the
key consideration for any new feature is how much it will satisfy users.
 How Does the Kano Model Work?

• Using the Kano Model, product teams pull together a list of potential new features vying for
development resources and space on the roadmap. The team will then weigh these features
according to two competing criteria:

1. Their potential to satisfy customers.

2. The investment is needed to implement them.

• You can also think of the Kano Model as the “Customer Delight vs. Implementation Investment”
approach.
 What are the Kano Model Feature Categories?

The Kano Model identifies three types of initiatives product teams will want to develop. We will
discuss those below.
1. Features to Include
2. Features to Avoid
3. When to use Kano
 When Should You Use the Kano Model?

• The Kano Model can be a helpful framework for product teams with limited time and resources
who want to make sure they prioritize the appropriate mix of features to work on next.
 weighted scoring

• Weighted scoring prioritization uses numerical scoring to rank your strategic initiatives against benefit and cost
categories. It is helpful for product teams looking for objective prioritization techniques that factor in multiple
layers of data.

• This prioritization framework helps you decide how to prioritize features and other initiatives on your product
roadmap. With this framework, initiatives are scored according to standard criteria. The criteria are based on a
cost-versus-benefits basis and then ranked by their final scores.

• The goal of the weighted scoring approach is to derive quantitative value for each competing item on your list.
You can then use those values to determine which items your team can prioritize on your roadmap.
 How is weighted scoring used?

• The weighted scoring model can be instrumental in product management, but its utility is not limited to this field.

• For example, if a company wanted to select the right piece of capital equipment among several choices, they might
create a common set of metrics—a combination of both benefits and costs—to score each piece of equipment.

• The “weighted” aspect of the scoring process comes from the fact that the company will deem specific criteria more
important than others and will, therefore, give those criteria a higher potential portion of the overall score. Continuing
with this example, the company might assign more “weight” to the complexity or time to implement a given piece of
equipment than it assigns to the cost of buying it.

• A more straightforward example of weighted scoring—one many of us are familiar with—is its use on school tests.
Teachers who deem the essay portion of their exams more important than multiple-choice sections will give those
essays a more significant percentage of the student’s overall grade than their multiple-choice answers.

• Using this same thinking, students who have a small quiz and a final exam approaching soon in the same class will
intuitively give more attention to preparing for the last. Overall, this is because they understand the final exam will
have a greater weight on their overall grade in the class.
 How do you calculate weighted scoring?

• To do the math, you must first define a few parameters. To begin, determine how you will be evaluating each potential
item. For example, you might use Increase Trial, Increase Usage, and Increase Revenue.

• For each of those, you need to set the “weight then.” Depending on the stage of the business, that may change. An
increasing trial might be most important if it’s early days, while a more mature company would focus on increasing
revenue. In this case, we’ll assume it’s still early on, so we’ll weigh accordingly:
 How do you analyze weighted scoring results?
• The example above shows how significant weighting can be in assessing the strategic value of a given project at this
particular time. In six months or a year, the business might be much more focused on revenue and reverse the ranking.

• Overall, this highlights the importance of weighting potential development items based on the current strategy. Adding a
shopping cart is still a great idea and crucial to the business’s long-term success. But right now, it’s not nearly as important
as signing up more users.

• This extra layer of context lets the product team and executives dig even deeper into connecting the work in the trenches
with the product’s current goals and objectives. You can also group these items into themes, slot them into the roadmap
according to when the business’s priorities align with their weighted scores.
 How can product managers use weighted scoring?

In a product context, weighted scoring prioritization works as follows.

Step 1: Compile a list of the features and other initiatives under consideration.

Step 2: Devise a list of criteria. This includes both costs and benefits, on which you’ll be scoring each of these initiatives.

Step 3: Determine the respective weights of each criterion you’ll use to evaluate your competing initiatives.

For example, let’s say you determine that the benefit “Increase Revenue” should be weighted significantly in the overall
score than the cost “Implementation Effort.” Then you will want to assign a greater percentage of the overall score to
Increase Revenue.
Step 4: Assign individual scores for each potential feature or initiative across all of your cost-and-benefit metrics. Then
calculate these overall scores to determine how to rank your list of items.
 Agile-Reviewing and Adjusting
Segu Chaitanya
Product Review (Demo)
Product Owner Acceptance
Retrospective Meetings
How to get the most out of Retrospective
meetings
 Product Review(Demo)
Product review is a meeting that typically occurs at the end of a product release cycle or a major
product milestone in Agile software development. The purpose of the product review is to evaluate
the product as a whole and to determine if it is ready for release.
Product review is a meeting that typically occurs at the end of a product release cycle or a major product milestone in
Agile software development. The purpose of the product review is to evaluate the product as a whole and to determine
if it is ready for release. The review may cover topics such as marketability, customer satisfaction, and business value.
The attendees at a product review typically include the product owner, stakeholders, and senior management.
The product owner is responsible for presenting the product to the stakeholders and senior management, and for
answering any questions they may have about the product.
During the product review, the product owner will typically present a demo of the product, highlighting the key features
and functionality. The demo may also include a discussion of any issues or challenges that were encountered during the
development process, as well as any plans for future development.
The stakeholders and senior management will then provide feedback on the product, which may include suggestions for
improvement, concerns about marketability, and questions about the product's alignment with business goals.
The product owner will take note of the feedback and use it to guide future product development.
The product review is an important part of the Agile software development process,
as it helps ensure that the product is meeting customer needs and business goals. It also provides an opportunity for
stakeholders and senior management to provide feedback and input into the product development process, which can
help
ensure that the product is aligned with the organization's overall strategy.
In summary, the key aspects of a product review include:

Occurring at the end of a product release cycle or a major product milestone.

Evaluating the product as a whole, including its marketability, customer satisfaction, and business value.
Including the product owner, stakeholders, and senior management.
Presenting a demo of the product and highlighting key features and functionality.
Collecting feedback from stakeholders and senior management, which can be used to guide future product development.

Reference link :

https://producthq.org/agile/product-management/product-review-meetings/
Product Review Cont.,
Attendees: Product owner, Stakeholders, and Senior Management
Conducts By : Product Manager

v Set expectations around how the meeting should work.

v Conduct a quick sneak-peek for a new prototype or show feedback from a recent user test.
v Discuss the roadmap & show progress on current projects.
v Discuss risks and tradeoffs.
v Collecting feedback and suggetions by senior managemnt and stake holder.
Product
Review(Demo)
 Sprint Review
Meeting
A sprint review is an informal meeting held at the end of a
sprint, in which the Scrum team shows what was
accomplished during this period
The sprint review meeting is a key event in the Scrum framework for Agile software development. It occurs at the end of
each sprint and is an opportunity for the development team to showcase the work they completed during the sprint and
gather feedback from stakeholders.

During the sprint review meeting, the development team demonstrates the completed work to the product owner and
other stakeholders. This demonstration can take many forms, such as a live demo, a video recording, or a slide
presentation. The purpose of the demonstration is to show that the work completed during the sprint meets the
acceptance criteria that were defined by the product owner before the sprint began.

After the demonstration, the product owner evaluates each user story or feature against the acceptance criteria and
determines whether it is acceptable for release or whether additional work is needed. If the completed work meets the
acceptance criteria, the product owner accepts it, and it is considered "done" for that sprint. If the work does not meet
the acceptance criteria, the product owner provides feedback to the development team, and the team may need to do
additional work to meet the acceptance criteria.
In addition to the product owner, other stakeholders may also attend the sprint review meeting, such as senior
management, customers, or end-users. These stakeholders provide feedback on the completed work, which can help
guide future development.

The sprint review meeting is also an opportunity for the development team to reflect on their performance during the
sprint and identify areas for improvement. This reflection can help the team continuously improve their processes and
deliver higher quality work in future sprints.

In summary, the sprint review meeting in Scrum is an important event where the development team demonstrates the
completed work to the product owner and other stakeholders, gathers feedback, and evaluates whether the work meets
the acceptance criteria. It is also an opportunity for the development team to reflect on their performance and identify
areas for improvement.
Sprint Review Meeting
Comparison
Product Review
• Product review evaluates the product as a whole
• Product review occurs at the end of
a product release cycle or a major
milestone.
• Product review involves senior
management and other high-level
stakeholders
Sprint Review
• Sprint review evaluates the
completed work for a single sprint.
• Sprint review occurs at the end of
each sprint.
• Sprint review involves the product
owner, development team, and
other stakeholders.(Srum Team)
Product
Owner
Acceptance
Product Owner Acceptance refers to the
process by which a product owner,
typically in Agile or Scrum software
development methodologies, approves
the work completed by the development
team.
 Where PO acceptancy
happance in scrum Process?
 Product Owner Acceptance
1.Define acceptance criteria :

v Understand the user story or requirement

v Identify the stakeholders
v Define the expected outcome
v Consider edge cases
v Use the SMART framework
v Collaborate with the development team

2.Development team completes work

 Product Owner Acceptance
3.Product owner reviews work:

v Review the acceptance criteria

v Test the functionality
v Check for edge cases
v Review the user interface
v Get feedback from stakeholders
v Accept or reject the work

4.Product owner accepts or rejects work

5. Feedback and iteration

Product Owner Acceptance refers to the process by which a product owner, typically in Agile or Scrum software development
methodologies, approves the work completed by the development team.

The acceptance process generally involves the following steps:

v Define acceptance criteria: The product owner and development team agree on the acceptance criteria that must be met
for a product backlog item to be considered complete.
v Understand the user story or requirement: The PO should first understand the user story or requirement that they are
trying to define acceptance criteria for. They should be clear about what the feature is supposed to do and what
problem it is supposed to solve.
v Identify the stakeholders: The PO should identify the stakeholders who will be impacted by the feature. These could
be end-users, customers, other teams, or the organization as a whole. Understanding who the stakeholders are will
help the PO determine what needs to be included in the acceptance criteria.
v Define the expected outcome: The PO should define what the expected outcome or result of the user story or
requirement is. This should be described in clear, specific terms that are measurable and verifiable.
v Consider edge cases: The PO should consider any edge cases that might impact the feature. These could be
unexpected inputs, unexpected user behavior, or other scenarios that might cause the feature to fail. The acceptance
criteria should cover these edge cases.
v Use the SMART framework: The PO can use the SMART framework to ensure that the acceptance criteria are specific,
measurable, achievable, relevant, and time-bound. This will help to ensure that the acceptance criteria are clear and
achievable by the development team.
v Collaborate with the development team: The PO should collaborate with the development team to ensure that the
acceptance criteria are feasible and that the team understands what is expected of them. The PO should also be
available to answer any questions that the development team might have.
v Development team completes work: The development team works on the product backlog item, following the
acceptance criteria and completing any necessary testing.
v Product owner reviews work: The product owner reviews the completed work to ensure that it meets the agreed-upon
acceptance criteria.
v Review the acceptance criteria: The PO should start by reviewing the acceptance criteria that were defined
for the user story or requirement. They should ensure that the completed work meets these criteria and that
all of the expected outcomes have been achieved.
v Test the functionality: The PO can test the functionality of the feature to ensure that it works as expected.
This could involve performing manual tests or using automated testing tools.
v Check for edge cases: The PO should also check for any edge cases that might impact the feature. They should
ensure that the acceptance criteria cover these edge cases and that the feature works correctly in these
scenarios.
v Review the user interface: If the feature includes a user interface, the PO should review it to ensure that it is
consistent with the product vision and is user-friendly. The PO can provide feedback to the development
team if any changes are needed.
v Get feedback from stakeholders: The PO can also get feedback from stakeholders who will be impacted by the
feature. This could include end-users, customers, or other teams. The feedback can be used to refine the
feature and improve its functionality.
v Accept or reject the work: Based on the review, the PO can accept or reject the work. If the work meets the
acceptance criteria and aligns with the product vision, the PO can accept it. If there are any issues or
problems with the work, the PO can reject it and provide feedback to the development team.
v Product owner accepts or rejects work: Based on their review, the product owner accepts the work if it meets the
acceptance criteria or rejects it if it does not.
v Feedback and iteration: If the work is rejected, the development team makes the necessary changes and resubmits it
for acceptance. This process continues until the work is accepted by the product owner.

The product owner acceptance process is important because it ensures that the product owner has control over the
direction of the product development, and that the development team is meeting the expectations and needs of the
stakeholders. It also ensures that the product is developed in a way that is consistent with the product owner's vision and
priorities.
Retrospective
Meetings
“ the Sprint Retrospective is an opportunity for the
Scrum Team to inspect itself and create a plan for
improvements to be enacted during the next
Sprint.”In a sprint retrospective, you'll discuss what
went well during the previous sprint cycle and what
can be improved for the next sprint
 Retrospective Meetings
va safe space for people to share honest feedback
vIt is an opportunity to focus on
inspection and adaptation.
vteam discusses, what went well in the Sprint,
what all can be improved and what actions shall be
undertaken to improve the next Sprint.

Conducted By : ScrumMaster
Attendees: Scrum Master, Product Owner, Development Team
 How to get the most out of Retrospective
meetings
v supportive atmosphere that encourages (but doesn’t force) all team members to contribute.
v a positive, energizing experience for your team. It helps team members share important feedback, let go of frustrations, and work together to come up
with solutions.
v Bring in an outside facilitator.
Vary the list prompts. At the end of the day, the retrospective is meant to uncover what's working and what's not. Consider these different prompts:
•Start / Stop / Continue: What the team should start doing, stop doing, and continue doing. Focus on ways to discontinue items in the "Stop" column.
•More / less: What the team needs to do more and less of. Create a plan around how to tackle the top items in the "do less" list.
•Glad / Sad / Mad: What made the team glad, sad, and mad. You guessed it, focus on the sad and mad lists and how to improve so there are only items in
the glad column next time.
v Engage leadership.
v Follow up on action items: After the retrospective meeting, make sure to follow up on any action items that were identified. Hold team members
accountable for their commitments and ensure that progress is being made towards the identified goals.
v Continuously improve: Retrospective meetings are not a one-time event, but rather an ongoing process of continuous improvement. Encourage your
team to regularly reflect on their work and identify areas for improvement, and make retrospective meetings a regular part of your project cycle.
Add a footer 127
Difference between Sprint review and
Retrospective
AGILE FRAMEWORKS
Sandhya Golluri
1. Scrum Introduction

2.Scrum Process Overview

3.Scrum Values

4.Scrum Roles&Artifacts
why Scrum?. Firstly, why it came into existence and what was the problem with the
traditional methodologies?

 The Waterfall model represents the well-defined stages of software development, and each stage must be
completed before the next stage can start and there should be no overlapping of the stages. In the Waterfall
model, we can only move to the next phase once we fully complete one phase.

 However, in software development, requirements and priorities can change rapidly, and the Waterfall
methodology can be inflexible in accommodating these changes. Moreover, Waterfall often results in long
development cycles, where the team may not be able to see or test the final product until the end of the
development process.

 Scrum was developed to address these issues by providing a more flexible and iterative approach to software
development. Instead of following a linear approach, Scrum breaks down the development process into short,
iterative cycles called sprints.
 Scrum
• Scrum is a light weight framework that helps people,
teams and organizations generate value through
adaptive solutions for complex problems.

• It is an adaptive, fast, flexible, incremental, iterative,

and effective methodology that was designed to
deliver outstanding values quickly throughout a project.
• Simple to Understand.
• Providing quick delivery of software product in short
iterations..
• Updating and reviewing according to the client’s
requirements.
• The project isn't for us, it is for customers. So they
should get what they truly need, and no customer
recognizes what they need at the start of a project.
SCRUM INTRODUCTION

1. Using A Team Approach - One talented player working

alone cannot win the game of rugby.Team members must be
able to pass work along from one team member to another
with as much ease as possible.
2. Each Player Has Specific Roles - Each position on a
rugby team requires a specific set of skills and even a
certain body type that must meld with other players on the
team to function successfully.
3. Sprints are Important - A sprint in rugby describes
short bursts players do when running the ball down the field.
4. Flexibility is a Must - The outcome of each play is
somewhat unpredictable, and the rugby team must be
flexible in determining the best approach to out maneuver
the opposing team.
5. Core Values are Embraced - Players treat one another
with respect, and this creates a powerful group bond.
-The most successful teams, whether in the sport of rugby
or in agile software development, enjoy working hard and
having fun together. They develop solutions to the inevitable
set backs, staying focused on the bigger end goal that is
shared by the entire team.
Journey of Scrum
Scrum Process Overview

It is a framework for handling a project

which focuses on teamwork, accountability,
iterative progress toward achieving a well-
defined goal.
 Scrum Values
1 Focus 2 Respect

3 Openness 4 Commitment

5 Courage
Focus

In scrum we have sprint goal in every sprint and that sprint

goal helps the entire team to remain concentrated on a
common shared goal because that is the only thing for which
every member in the scrum team would be working for so
scrum team generates focus when it creates sprint goal for
itself..
The Scrum Team focuses on the goals of the sprint and works
together to achieve them. They prioritize their work based on
the value it delivers and minimize distractions and
interruptions.

Eg:Daily Scrum
Openness

Talking about challenges very openly within the scrum team

with out any fear its more of you know having a feel safe
envirement.
The Scrum Team is open and transparent about their work,
progress, and challenges. They share information with each
other and with stakeholders to promote understanding and
collaboration.
Eg:sprint retrospective
Respect

Joining the scrum events on time if you do that your

respecting your time as well as your other team members
time also that will helps the finish the meeting within the
time box.
The Scrum Team members respect each other and work
together in a positive and supportive environment. They
value each other's opinions and perspectives, and they treat
each other with professionalism and empathy.
Commitment

When the team starts taking action on the

improvement items that they figure out
during the retrospective so if your team is
taking actions on the improvement items it
means that they are committed towards
continuous improvement.
-Taking responsibilities and action for the
improvement items that they discover.
Scrum Team members commit to achieving
the goals of the sprint and delivering high-
qualit y, wor king s oft war e . T h e y t a k e
ownership of their work and are accountable
for the outcomes.
Courage

When it comes to Scrum, Courage means Scrum Teams

should feel safe and comfortable in saying no, asking for help,
accepting challenges or trying new things. They should be
courageous enough to question the status and if it affects
their ability to succeed.
-The Scrum Team has the courage to take on challenges,
speak up when needed, and make tough decisions. They are
willing to experiment and try new approaches, and they learn
from both successes and failures.
SCRUM ROLES
The Agile Scrum Roles : Scrum has three
roles: product owner, scrum master, and
the development team members.

Product Owner : Figure out all the Requirements for the Project and put it in the Product backlog.
The Product Owner is responsible for defining and prioritizing the product backlog, which is a list of
features, requirements, and other work items that the Scrum Team will work on. The Product Owner
is responsible for ensuring that the product backlog is well-defined, prioritized, and understood by
the Scrum Team and stakeholders.

Scrum Master : The Scrum Master assists the product owner by assisting them in effectively
understanding and communicating purpose, managing the schedule, and planning and
breaking down the task with the team to give the most out of learning outcomes.

The Scrum Master is responsible for ensuring that the Scrum Team is following the Scrum
framework and practices. The Scrum Master facilitates Scrum events such as the Sprint
Planning, Daily Scrum, Sprint Review, and Sprint Retrospective meetings. The Scrum Master
is also responsible for removing impediments and helping the Scrum Team to continuously
improve.
SCRUM ROLES
Development Team : The Development Team is responsible for delivering
a potentially releasable product increment at the end of each sprint.
The Development Team is self-organizing and cross-functional,
meaning that it has all the necessary skills and expertise to complete
the work defined in the sprint backlog. The Development Team works
collaboratively to plan, design, develop, test, and deliver the product
increment.

Ø Each of these roles plays a critical part in the success of Scrum. The
Product Owner ensures that the team is working on the most
valuable work items, the Scrum Master helps to facilitate Scrum
events and remove impediments, and the Development Team is
responsible for delivering high-quality product increments.
Together, they work collaboratively to achieve the goals of the
sprint and deliver valuable software to stakeholders.
Scrum Artifacts

1.Product Backlog
2.Sprint Backlog
3.Increment
 Scrum Artifacts
Product Backlog :

In Scrum, the product backlog is a prioritized list of all the features, requirements, and other work
items that need to be completed to deliver the final product. The product backlog is owned by the
Product Owner, who is responsible for defining and prioritizing the items in the backlog.

The product backlog is dynamic, meaning that it can change and evolve over time as new information
becomes available or priorities change. The Product Owner continuously reviews and updates the
product backlog to ensure that it is up-to-date and reflects the most valuable work items.

Each item in the product backlog is called a backlog item, which can take various forms, such as user
stories, features, bug fixes, or technical tasks. Backlog items are typically brief, high-level descriptions
of a functionality or requirement, and they contain just enough information to communicate the goal
and value of the work item to the Development Team.
 Scrum Artifacts
Sprint Backlog :

committed to completing during the current sprint. The Sprint Backlog is owned by the
Development Team, and it is created during the Sprint Planning meeting, which is held at
the beginning of each sprint.

The Sprint Backlog is a detailed plan that outlines the tasks, activities, and deliverables
that the Development Team will work on during the sprint. The Sprint Backlog is a
dynamic document, and it can change and evolve over time as new information becomes
available or priorities change.

The items in the Sprint Backlog are derived from the product backlog, which is a
prioritized list of all the work items that need to be completed to deliver the final product.
The Development Team selects the highest-priority items from the product backlog and
plans how they will complete them during the sprint.

The Sprint Backlog is time-boxed to the duration of the sprint, which is typically two to
four weeks. The Development Team works collaboratively to complete the items in the
Sprint Backlog and delivers a potentially releasable product increment at the end of the
sprint.
 Scrum Artifacts
Increment :

In Agile methodologies such as Scrum, an increment is a term used to describe a

working piece of the product that has been completed by the Development Team
during a sprint. An increment is a sum of all the completed backlog items that have
been delivered at the end of each sprint.

An increment is a vital part of the iterative and incremental nature of Agile

development. It represents a small, but complete, piece of functionality that can be
potentially shipped or released to customers or stakeholders. Each increment builds
on the previous one, adding new features or improvements, and working towards the
final product.

The increment is also an important artifact in the Scrum framework, as it enables

transparency and provides a tangible measure of progress towards the goal of
delivering the final product. At the end of each sprint, the Development Team
delivers an increment, which is reviewed by stakeholders during the Sprint Review
meeting.
When to use Scrum
Scrum is a popular Agile framework that is widely used in
software development and other industries to manage complex
projects. It is a lightweight and flexible approach to project
management that emphasizes collaboration, iterative
development, and continuous delivery of value to stakeholders.

Scrum is particularly well-suited to projects that involve rapidly

changing requirements, a high degree of uncertainty, and a
need for regular feedback and adaptation. Scrum is also
effective when there is a cross-functional team that is
responsible for the development, testing, and delivery of the
product.

1.Simple Problems: Problem is known and solution is known.

eg: Picnic
2.Complex Problems: Problems goes on changing,where you dont the problem
only.Solution need to be figure out after the problem known.
eg: Car thurnder storm

 When scope is not defined.

 The Product will gradually appear during the project
 Success is mostly measured by customers satisfaction.
 Requirements goes on changing.
 Everyone changes as per there Organisation Requirements.
• Prem Kumar
AGENDA
• Kanban History
• What is Kanban
• Software Development Kanban
• Push vs Pull work allocation
• Flow and the Cumulative Flow Diagram
• Kanban’s Relationship with Lean and Agile
• Please hold questions to the end or talk to me after
MY KANBAN BACKGROUND
Kanban was invented in the 1950s by Taiichi Ohno (1912-1990) a
Toyota Industrial Engineer, and later senior executive at Toyota.
kanban as a scheduling technique existed long before the concept of
lean came into existence. Taiichi ohno, the father of kanban
introduced kanban in the year 1953. Later, lean adopted kanban as
one of its framework in the Year 2007.

THE FIRST KANBAN BOARD

Kanban was initial used as a low cost (non-IT)

mechanism to support the Toyota Production System
(TPS) which was a JIT or Lean manufacturing system
as Japan at the time was resource poor and Toyota
was nearly bankrupt.

151
WHAT IS KANBAN
• FIRSTLY A WORK VISUALISATION TOOL

• Kanban means signboard or billboard in Japanese

• Represents the teams current work and work flow
• Can represent nearly any business workflow, such as
• Software Development
• Change Management
• Others

• Information
• Team and stakeholders can see progress easily at any time
• Easily identify bottlenecks
• Enables process improvement and Agility through Lean practices

152
 KANBAN IS A PULL System
• Work IS pulled into The SYSTEM, NOT PUSH VS PULL
PUSHED

A PULL SYSTEM IS IMPORTANT AND THE SINGLE MAIN REASON IT IS USED IS THAT IT HELPS OPTIMIZE THE AMOUNT OF WORK IN THE SYSTEM AND UNLIKE A
PUSH SYSTEM WHICH FORCES TEAM MEMBERS TO WORK ON MULTIPLE TASKS, A PULL SYSTEM MEMBERS FOCUS ON A SINGLE TASK AT A TIME. THIS IN TURN
ALLOWS THE TEAM MEMBERS
TO RAPIDLY, ADJUST THE CHANGES IN THE WORK PROCESS. SCALE,
153
154
SOFTWARE DEVELOPMENT KANBAN BOARDS

155
EXAMPLE OF A Physical Board

156
USES WORK IN PROGRESS (WIP) LIMITS
• TO INCREASE FLOW

157
Example of A JIRA KANBAN BORAD

158
What is WIP Limits

• WIP stands for Work In Progress. In Kanban, WIP limits represent the number of tasks being worked on by an
individual or team at one time. WIP limits are indicated in a Kanban board and can be set for an entire Kanban
process or per step.
• Implementing Kanban WIP limits is an essential practice in Kanban. This allows teams to stabilize work and
increase predictability which are crucial elements for establishing a pull-based system. The WIP limits are
identified by the team who owns the workflow.

• While there is no hard rule in setting Kanban WIP limits, the basic idea is for each individual to work on one task
at a time.

159
160
Given your Value Stream Map, plot the value-adding (VA) and non value-adding (NVA) times
across your process. For this example, let’s assume the unit of measure is in days.

161
WHY WE NEED TO SET WIP LIMITS
SETTING WIP LIMITS IS A KEY PROPERTY IN KANBAN FOR A NUMBER OF REASONS. KANBAN WIP LIMITS:
TEACH TEAMS TO FOCUS ON GETTING THINGS DONE.
PREVENT TASKS FROM ACCUMULATING AT ANY STEP IN THE PROCESS.
ALLOW TEAMS TO KNOW THEIR TRUE CAPACITY.
EXPOSE BLOCKERS, BOTTLENECKS, AND INEFFICIENCIES.
HELP PREVENT TEAMS FROM BEING OVERBURDENED OR LAX.
SETTING WIP LIMITS ENFORCES TEAMS TO ONLY WORK ON WHAT THEY CAN. THIS HELPS IN MANAGING THE FLOW OF WORK
THROUGH A KANBAN SYSTEM.
As you go on with your Kanban practice, your WIP limits will definitely change. This could be due to a lot of factors including:

Workflow changes (e.g. new steps being added, steps being removed)
Skills, knowledge, and expertise growth
Change in team composition (e.g. members being added to or leaving from the team)
Too Learn more

164
EXTREME PROGRAMMING
By Sekhar
• Extreme programming is one of the most specific
agile development frameworks, with clearly
defined engineering practices.

• It focuses on producing high-quality software that

meets customer expectations improving the
quality of life for the development team.

• XP is based on the principles of simplicity,

communication, feedback, and courage. It is
designed to be a lightweight and flexible
methodology that can be adapted to the needs
of different projects and teams.
Extreme Programming includes set of Engineering Practices :

1. Pair Programming

2.Test driven development

3.Continuous integration
Pair Programming
• Pair programming is a software development practice in
which two programmers work together on a single
computer to write code, review and discuss code changes
in real-time. One person is typically the driver, who writes
the code, and the other is the navigator, who reviews the
code, offers suggestions, and checks for errors. The roles
can be switched at any time.

• Pair programming is often used in agile software

development methodologies such as Extreme
Programming (XP) and is based on the principle of
collaboration and continuous feedback. It is believed to
increase the quality of code, reduce the number of
defects and errors, and accelerate the learning and
transfer of knowledge between team members.
Test driven development
1)Write a failing test: The first step in TDD is to
write a test that will initially fail because there is
no code that satisfies it. This test is a
specification for the functionality that needs to
be implemented.

2)Write minimal code to pass the test: The next

step is to write the minimum amount of code
required to pass the test. This code does not
need to be complete or optimal, but it must
pass the test.

3)Refactor the code: Once the test has passed,

the code can be refactored to improve its quality,
clarity, and maintainability.

4)Repeat: The TDD process is then repeated for

the next feature or functionality that needs to
be implemented.
Continuous Integration
• Continuous Integration (CI) is a software development
practice that involves integrating code changes into a shared
repository frequently, often several times a day. The goal of CI
is to catch errors and conflicts early in the development
process and ensure that the code is always in a working state.

• CI relies on the use of automated tools that perform a series

of tests on the code each time it is integrated into the shared
repository. These tests can include unit tests, integration tests,
and functional tests, among others. If any errors or conflicts
are detected, the CI system alerts the developers, who can
then address the issues before they become more significant
problems.
Advantages of XP:

1)Fast MVP Delivery.

2)Less Documentation.
3)Customer satisfaction
4)No over time
5)Team Collaboration.
6)Clear Code.

Disadvantages:

1)Pair Programming takes longer.

2)Unclear Estimates
3)Works best in small projects.
4)Not working in remote working teams.
5)High cost
Communication
- Pavan Kumar
 Agenda

• 1.Communication &
related issues
• 2.Communication
tools – Pros & cons
• 3.Facilitation issues &
common issues
Introduction

• Communication is a fundamental aspect

of human interaction and is essential for
the success of any individual or
organization. Effective communication
can help convey information, ideas, and
feelings clearly and concisely, leading to
better understanding and cooperation
between people.
Role of communication in Agile methodology

In agile methodology, communication occurs at various levels and in different forms. Here are some examples:

Daily stand-up meetings

These are short, daily meetings where team members share
updates on their progress, identify any roadblocks or issues,
and discuss how they can help each other.

One-on-one meetings
These meetings allow team members to discuss
specific issues or concerns in a private setting.
Role of communication in Agile methodology

Sprint review
These meetings occur at the end of each sprint
and involve a demo of the work that was completed
during the sprint. This is an opportunity for the team
to get feedback from the customer and other
stakeholders.

Sprint retrospective
These meetings occur at the end of each
sprint and are focused on reflecting on what
went well, what didn't go well, and what the
team can do to improve.
Role of communication in Agile methodology

Effective communication in agile

methodology requires active listening,
clear and concise language, and a willingness
to ask questions and seek feedback.
It also requires a culture of transparency
and openness, where team members feel
comfortable sharing their thoughts and ideas.
When communication is done well, it can lead
to better collaboration, improved decision-making,
and ultimately, a more successful project.
Communication related issues in Agile methodology

While agile methodology emphasizes communication, there are still some common communication-related issues
that can arise. Here are a few examples

Misunderstandings
Can lead to delays and rework. For example, if a team member
misinterprets a requirement or instruction, they may end up
working on the wrong task or in the wrong direction. This can
cause delays and require additional work to correct.

Lack of transparency
Can result in missed opportunities or poor decision-making.
For example, if team members are not sharing information or
are working in silos, they may miss opportunities to collaborate
or may make decisions based on incomplete information.
Communication related issues in Agile methodology

Cultural and language barriers

This can lead to miscommunication and confusion. For example, if team

members are not aware of cultural differences or are not sensitive to
language barriers, they may misunderstand instructions or fail to
communicate effectively with each other.

Lack of feedback

This can result in a less successful project. For example, if team

members are not providing feedback to each other in a timely or
constructive manner, they may miss opportunities to improve or
to address issues before they become more significant.
Communication related issues in Agile methodology

Technical communication issues

This Can lead to delays and misunderstandings. For example,

if non-technical team members do not understand technical
jargon or concepts, they may misunderstand instructions or
fail to provide useful feedback on technical issues.

180
181
Communication Tools in Agile methodology

In agile methodology, communication is crucial for

the success of the project. There are various
communication tools that agile teams can use to
facilitate communication and collaboration.

Some of the commonly used communication tools in

agile methodology include:

• Email
• Instant Messaging
• Video Conferencing
• Project Management Software
• White Boards and Physical Boards

182
Communication Tools in Agile methodology

Email
Email is a commonly used communication tool in many organizations.

Pros & Cons

Pros Cons
Asynchronous May be slow and
communication allows unresponsive
people to respond at their
convenience

Can be used for formal and Can be prone to

official communication misinterpretation

Provides a written record of Difficult to collaborate and

communication brainstorm ideas

183
Communication Tools in Agile methodology

Instant Messaging
Instant messaging tools, such as Slack and Microsoft Teams, are commonly used by agile teams to facilitate
real-time communication and collaboration.
Pros & Cons

Pros Cons
Facilitates real-time Can be distracting and lead
communication and to interruptions
collaboration

Allows for quick responses Difficult to communicate

and decision-making complex ideas or concepts

Can be used for informal May not be accessible to

and casual communication all team members

20XX 184
Communication Tools in Agile methodology

Video Conferencing
Video conferencing tools, such as Zoom and Skype, are commonly used by agile teams for remote
collaboration.
Pros & Cons

Pros
Facilitates real-time
communication and
collaboration, regardless of
location
Allows for visual cues and
body language to improve
understanding
Can be used for remote
meetings and discussions
20XX
Cons
Requires a stable internet
connection
May be challenging to
schedule across time zones
Can be tiring for participants
who are on camera for long
periods of time
185
Communication Tools in Agile methodology

Project Management Software

Agile teams often use project management software, such as Jira and Trello, to manage their projects.

Pros & Cons

Pros Cons
Facilitates collaboration and Can be complex and require
transparency in project training to use effectively
management

Allows for tracking and May not be accessible to all

monitoring of tasks and
progress
Provides a centralized
location for project-related
information
team members
Can lead to information
overload if not managed
properly

20XX Sample 186

Footer Text
20XX 186
Communication Tools in Agile methodology

Whiteboards and physical boards

Agile teams often use whiteboards and physical boards, such as Kanban boards, to visualize their project
progress and track tasks. These tools allow team members to see the status of the project at a glance and
can facilitate
Pros & Cons communication and collaboration.
Pros Cons
Allows for visualization of May not be accessible to all
project progress and status team members, particularly
remote team members

Facilitates collaboration and Limited space for

discussion among team information and updates
members

Provides a physical Not searchable or easily

reminder of project goals archived
and milestones
20XX Sample 187
Footer Text
20XX 187
Facilitation in Agile methodology

Facilitation
Facilitation is an important aspect
of agile methodology because it
helps to ensure that team
members are able to work
together effectively and
efficiently. Facilitation involves
guiding the team through various
agile processes and ceremonies,
such as daily stand-up meetings,
sprint planning meetings, and
retrospectives. The Scrum Master
or agile coach is responsible for
facilitating these processes and
ceremonies, and for ensuring that
they run smoothly.

20XX Sample 188

Footer Text
20XX 188
Common Facilitation issues in Agile methodology

some common facilitation issues that can

arise in agile methodology are:

• Lack of engagement
• Unclear goals
• Resistance to change
• Lack of communication
• Limited resources
• Ineffective leadership

20XX 189
20XX 189
Common Facilitation issues in Agile methodology

Lack of engagement
For example, if team members are not actively participating in
daily stand-up meetings, it can be difficult to identify and
resolve issues in a timely manner, which can slow down the
project.

Unclear goals

For example, if the product owner is not clear about the

vision and goals of the product, it can be difficult for the
development team to prioritize work and make decisions
about what to include in each sprint.

20XX 190
Common Facilitation issues in Agile methodology

Resistance to change
Agile methodology requires a willingness to adapt and change
as the project progresses. However, some team members may
be resistant to change, which can create challenges in
implementing agile processes and achieving project goals. For
example, if team members are resistant to adopting new tools
or processes, it can be challenging to implement agile practices
effectively.

Lack of communication
Lack of communication can lead to misunderstandings,
delays, and a lack of progress. For example, if team
members are not communicating effectively during daily
stand-up meetings, it can be difficult to identify and
resolve issues in a timely manner, which can slow down
the project.
20XX
20XX 191
Common Facilitation issues in Agile methodology

Limited resources

Agile methodology requires a significant amount of

time and resources. For example, if the team is
understaffed, it can be difficult to complete all of the
work required for each sprint, which can lead to delays
and a lack of progress.

Ineffective leadership
The success of an agile project depends heavily on the
leadership provided by the Scrum Master or agile coach. If the
leadership is ineffective, it can lead to a lack of direction,
confusion, and a lack of progress. For example, if the Scrum
Master is not providing clear guidance and support to the
team, it can be difficult for the team to stay focused and make
progress towards achieving project goals.
20XX
20XX 192
Metrics and Measurements
Kailash KV
 CONTENTS

Types of Outcome Output Measuring Assessing Agile

Metrics metrics & NPS Metrics Team’s Health Maturity
score
What is Metrics ?
In general, Metrics are qualitative or quantitative standards that you choose and use in order to continuously
improve your product, service, organization and team. Metrics are measurements used to evaluate, quantify, and
track the performance or progress of a particular process, system, or project. Metrics provide objective and
measurable data that can be used to assess whether a goal has been achieved.

for example:

In the context of technology, metrics are often used to evaluate the performance of hardware, software, or systems.
Examples of metrics used in technology might include CPU usage, network latency, error rates, or uptime.

In agile methodology:
Metrics are used to measure and track the performance of the development process, team, and project, with the
goal of identifying areas for improvement and optimizing performance.
In agile methodology, Measurements refer to the collection, analysis, and interpretation of data to understand and
improve the performance and outcomes of the team and the project. Measurements are used to track progress,
identify potential issues, and make data-driven decisions to improve the performance and outcomes of the team.

Measurements in agile can include various

types of metrics:

• Outcome metrics
• Output metrics
• Health metrics
Outcome Metrics :
In agile methodology, outcome metrics are a type of metric that measures the impact or value of the product or
service being developed. such as customer satisfaction, revenue growth, or user engagement. These metrics are
typically tied to the goals and objectives of the project or organization.

Some examples of outcome metrics in agile include:

Customer satisfaction: This measures the level of satisfaction of the customers or users with the product or service
being developed.

Revenue growth: This measures the increase in revenue generated by the product or service.

User engagement: This measures the level of engagement or interaction of the users with the product or service.

Time to market: This measures the time it takes to deliver the product or service to the market.

Business value: This measures the value generated by the product or service in terms of business impact or return
on investment.
Output Metrics :
In agile methodology, output metrics are a type of metric that measures the amount of work completed by the team,
such as the number of user stories completed, the velocity of the team, or the cycle time of individual tasks. Output
metrics are useful for monitoring progress and assessing productivity.

Some common output metrics in agile include:

Velocity: This measures the amount of work the team can complete in a sprint.

Cycle time: This measures the time it takes to complete a single task or user story, from start to finish.

Burn-up and burn-down charts: These charts track the progress of work completed over time and compare it to the
projected completion rate.

Lead time: This measures the time it takes to complete a user story from the time it is created to the time it is
deployed.

Defect rate: This measures the number of defects or bugs found during development or in production.
Health Metrics :
In agile methodology, health metrics are a type of metric that measures the overall health and performance of the
team and the project. Health metrics are useful for identifying potential issues, tracking progress, and making data-
driven decisions to improve the performance and outcomes of the team.

Some common health metrics in agile include:

Team satisfaction: This measures the level of satisfaction of the team members with their work and the project.

Team morale: This measures the overall morale and motivation of the team.

Work-life balance: This measures the balance between work and personal life for team members.

Agile maturity: This measures the level of maturity of the team in adopting and implementing agile methodologies.

Sprint success rate: This measures the percentage of sprints completed successfully, meaning that all planned work
was completed within the sprint timeframe.

Stakeholder satisfaction: This measures the level of satisfaction of stakeholders with the progress and outcomes of
the project.
 NPS score : Net Promoter Score.

• The Net Promoter Score (NPS) is a metric that

indicates customer satisfaction and loyalty.
• In agile methodology, NPS can be used to assess the
effectiveness of the product or service being
developed and delivered to customers. It can also be
used as a tool to continuously improve customer
experience and drive product or service innovation.
• NPS can be included as a key performance indicator
(KPI) in agile metrics dashboards and can be tracked
over time to monitor progress and identify areas for
improvement.
Understanding the Outcome metrics and NPS score :

In Agile methodology, Outcome metrics and NPS score are used to measure the success and effectiveness of an Agile
project.
Outcome metrics evaluate :
• The overall results or outcomes of a project or initiative.
• To determine the effectiveness of the initiative in achieving its goals & objectives.
• Provide a broad view of the project's performance and can help the team identify areas for improvement.
• For ex: outcome metrics in Agile include the number of features delivered, the delivery time, and the project's
budget.

NPS metric which measures :

• Customer loyalty & satisfaction.
• NPS score is used to evaluate customer experience with the product or service delivered by the Agile project.
• NPS is considered a leading indicator of business growth, helps to ensure that the project is delivering value to
customers.
• Companies with high NPS scores tend to have high customer retention rates
Output Metrics : Velocity & Predictability

Velocity : Velocity metrics are a type of Agile metric used to measure the amount of work completed by an Agile
team during a specific iteration or sprint. Velocity is a measure of the team's productivity and can be used to
estimate how much work the team can complete in future sprints.

Velocity Formula = Total story points completed in a sprint / Number of working days in the sprint

Velocity metrics are used by Agile teams to:

Estimate the amount of work they can complete in a future sprint based on their past performance.
Track their productivity and identify areas for improvement.
Evaluate the team's capacity and identify any constraints that might affect their ability to complete work.
Forecast the team's progress and communicate progress to stakeholders.
Output Metrics : Predictability

Predictability metrics in Agile methodology are used to measure the predictability of a team's development process.
They help teams to understand how much work they can complete in a given time period, and to identify areas
where they can improve their performance. These metrics are used to track progress and to make data-driven
decisions about how to optimize the team's workflow.

Predictability metrics in Agile include:

• Sprint Burndown Chart
• Velocity
• Cycle Time
• Lead Time
• Cumulative Flow Diagram
Output Metrics : Cycle time ( Cycle Time = End Date – Start Date )

In Agile methodology, cycle time is a metric used to measure

the time it takes for a team to complete a task or user story
from start to finish. It is a measure of the duration of the
development process, from the moment a task is started until
it is completed and delivered.

Cycle time in agile identifies :

• Areas of inefficiency in their development process.
• Can identify bottlenecks and areas where they can
improve their performance.
• To predict how long it will take to complete similar tasks
in the future.
Output Metrics : Throughput rate ( Throughput = WIP / cycle time )

Throughput rate is an Agile output metric used to

measure the amount of work that a team completes
within a given time period. It is typically measured in
terms of user stories, features, or other units of work
completed during a sprint or other defined period of
time.

For example: If the team's throughput rate is

consistently lower than expected, they may need to
review their process and identify bottlenecks that are
slowing them down.

In a Kanban system, for example, as work is visualized in

cards, throughput is measured based on how many
Kanban cards were finished in a given period (weekly,
monthly, etc.)
Measuring Team’s Health :

Measuring team health in Agile involves a combination

of qualitative and quantitative data. By assessing
multiple factors that impact team performance and
well-being, teams can identify areas for improvement
and take steps to optimize their performance.

Common ways to measure team health in Agile:

• Retrospectives
• Team satisfaction surveys
• Communication quality
• Burnout
• Delivery metrics
Assessing agile maturity :

Assessing Agile maturity refers to evaluating how well an

organization or team is adopting and implementing Agile
principles and practices. It involves a comprehensive
evaluation of the organization's or team's Agile practices,
processes, and culture.

Common ways to assess Agile maturity:

• Assessing adoption of Agile practices
• Measuring productivity and performance
• Evaluating leadership and culture
• Assessing team collaboration
• Assessing continuous improvement
• Assessing Agile maturity models
Thank you for listening
- Poojvitha
 Transformation
Why is transformation required ?

• Trandsformation is required for the Change

Why is change required ?

• Change is required to get updated with the trend and

technology

Why we need to get updated with technology

• we need to get updated with technology and trends to get sustained in

the market
Emergence of the product management (SAAS)
• Software development was started in in 1960
before internet is emerged
• Internet is started in early 1991 whear as its
started booming from 1996 people started
using internet moreso the internet based
companies started emerging more ,people
started invensting on the online based
companies
• During the period of 1990’s due to .com
bubble many companies stocks and value fallen
down this created a very bad impact on Online
business companies
• After that again the advancements happened
and and the emergence of SAAS took place in
1999
• Waterfall methodology was established in early
1970’s
• Agile is formally launched on 2001 .
Understanding the Product analysis
The better you understand your users, the more likely you are to design
and build a service that works well for them. Who are our users? They are
people who need to use the services you are working on.

Market Research is a method of analysis on past and current market

behavior, along with dominant patterns of the market and its
consumers. This kind of analysis relies on examining statistical data
and recorded market behavior over a defined period of time

Technology is needed to understand the market trends , by

understanding the market trends , one can easily evaluate
theprogressions needed for thr product

Competition within the market in needed and for product

analysis knowing the competitors must be an added
advantage to place their products

a market trend analysis is a method of analysing the past

and current behavior, along with patterns of the market and
its consumers
Waterfall model to Agile model
Generic example of Waterfall and Agile
Generic example of Waterfall and Agile
Waterfall method
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model.
Each phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements
are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a
moderate to high risk of changing. So, risk and uncertainty is
high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
Importance of Agile :-

02 Release on demand

Sucess
Continous development

01

03 Involves in development with updating

technology and trends

Agile method
Advantages
• In Agile methodology the delivery of software is
unremitting.
• Customers satisfraction
• Customers can have a look of the working feature
which fulfilled their expectations.
• If the customers has any feedback or any change in
the feature then it can be accommodated in the current
release of the product.
• In Agile methodology the daily interactions are
required between the business people and the
developers.
• Attention is paid to good design work and interface
• Changes in the requirements are accepted even in the
later stages of the development.
• In Agile methodology the documentation
is less.
• In few of the projects at the starting of the
software development life cycle it ’s
difficult to estimate the actual effort
required.
• Because of the ever-evolving features,
there is always a risk of the ever-lasting
project.
• For complex projects, the reso urc e
requirement and effort are difficult to
estimate.
What is Quasi-agile ?
"Quasi-agile" is a term used to describe a situation where an
organization or team is attempting to implement Agile
methodologies but is not fully committed or able to follow all of
the principles and practices of Agile.
When Quasi-Agile will happen ?
• facing challenges such as resistance to change
• lack of understanding or training in Agile, or difficulties
adapting to the new way of working.
• In these cases, the organization or team may adopt some of
the Agile practices, but not fully embrace the Agile mindset.

While adopting some Agile practices can bring benefits such

as increased collaboration, transparency, and flexibility, it is
important to understand that true Agile adoption requires a
commitment to the Agile values and principles. Quasi-Agile
adoption may not result in the full benefits that Agile can
bring, and may lead to confusion or inconsistent results.
When Agile,waterfall and Quasi needed ?

• Waterfall for the products of long term developments such

like Windows 10 -11
• Agile is useful for the products which requires continous
changing adoptions based on the market trends and
technology
• Quasi Agile is sometime helpful and sometimes creates
confusion it can be used based on the updating changes
and immediate actions required if the agile team is in
condusion .
How user behaviour is linked with Product management (Transformation)

• Markets that makes users to adopt to its

trends

• Markets that runs with user Mindset and

their behaviour
A small activity

What if I say I can control your mind ?

Interesting quotes thats linked to Agile
• Don’t assume it rains without watching the sky

That means we can decide the users decidion without

understanding the competion, market trends, new
technologies and e.t.c

• Agile is like a lighthouse

Agile provides the right direction for the

products symbolically saying Light house
provides the correct direction for the
boats in the middle of the sea/ocean
Importance of Design thinking in Agile:-
• Design thinking is an iterative, non-linear process which focuses on a collaboration between
designers and users. It brings innovative solutions to life based on how real users think, feel and
behave

Stages:-

Define Prototype
Ideate
Test
Empathize
 The Design Thinking process starts with empathy. In order to create desirable products and services, you
Empathize need to understand who your users are and what they need. What are their expectations in relation to the
product you’re designing? What challenges and pain-points do they face within this context?

In the second stage of the Design Thinking process, you’ll define the user problem that you want to
solve. First, you’ll gather all of your findings from the empathize phase and start piecing them
Define together. What common themes and patterns did you observe? What user needs and challenges
consistently came up?
The third stage in the Design Thinking process consists of ideation—or generating ideas. By this point,
Ideate you know who your target users are and what they want from your product. You also have a clear
problem statement that you’re hoping to solve. Now it’s time to come up with possible solutions.

A prototype is essentially a scaled-down version of a product or feature—be it a simple paper

Prototype model or a more interactive digital representation.

During the testing phase, you’ll observe your target users—or representative users—as they
interact with your prototype. You’ll also gather feedback on how your users felt throughout the
Test
process
Four main factors

Human centric
Creative

Observation
User friendly
Lets see an Example
Few examples where Design thinking is used
Ratan tata
Electricity from Rotten vegetables

Nike shoes -Plastic waste

Dell eco bags-Ocean waste

Nzambi matee-Bricks from plastic waste

Ankith Agarwal -Incence sticks

Richard tuture-Torch idea

Petrol from plastic waste in Hyderabad

Future of Agile and Product
development

• Ola hikes

• Hologram technologies

• In future if there is advancements and

rapid technology may lead to include
lean and devops in Agile
WOW ,we are done
Thank you
• Dealing with ‘difficult teams’.

• Dealing with mini-waterfalls.

• Too may meetings.

• Problems with deadlines.

Ø Lack of participation
Lack of participation
• Some team members may not be fully engaged in the
Agile process, which can hinder the team's progress.

To avoid this
• In such cases, it's important to encourage the team
member to participate more actively.

• One way to do this is by assigning specific tasks or

responsibilities that match their skills and interests.

• Provide support

• Focus on continuous improvement

Poor Communication Skills
Good communication is essential for effective
teamwork in Agile. If a team member has poor
communication skills, it can lead to
misunderstandings and conflicts.

To avoid this

In such cases, it's important to provide

feedback and coaching to help the team
member improve their communication skills.
Lack of accountability
• In Agile, every team member is accountable
for their work. If a team member consistently
fails to deliver their work on time, it can affect
the entire team's progress.
To avoid this
• It's important to address this issue by setting
clear expectations and holding the team
member accountable for their work.

• Define clear responsibilities.

• Set achievable goals.

• Communicate regularly.

• Provide feedback and recognition.

• Establish consequences
Negative attitude
• A team member with a negative attitude
can bring down the morale of the entire
team.

To avoid this
• It's important to address this issue by
having a frank discussion with the team
member, finding out the root cause of
their negativity, and providing support and
coaching to help them become more
positive.

• Encourage open communication.

Lack of technical skills
• In Agile, every team member is expected to have a
certain level of technical skills.

• If a team member lacks the necessary technical skills,

it can affect the team's progress.

To avoid this
• It's important to address this issue by providing
training and coaching to help the team member
improve their skills.
Solutions
• Agile requires patience,
• Good communication skills,
• willingness to work collaboratively to find solutions.
• Understand the root cause of the difficulties
• Communicate effectively
• Encourage collaboration
Dealing with Mini waterfalls in Agile
Ø Lack of collaboration

Ø Limited feedback

Ø Inflexibility

Ø Quality issues

Ø Coordination challenges
Lack of collaboration
• Mini waterfalls can lead to teams working in
silos, with each team focusing on their
specific iteration without collaborating with
other teams.

• This can lead to a lack of communication and

knowledge sharing, which can hinder the
overall success of the project.
To avoid this
• Establish clear communication channels

• Define roles and responsibilities.

• Foster a collaborative culture.

• Set clear goals and expectations

• Provide sufficient resources

Limited feedback • Mini waterfalls can limit the amount of
feedback that teams receive.

• This can lead to a lack of understanding

of customer needs and requirements,
resulting in products that do not meet
customer expectations.
To avoid this
• Identify potential areas for limited
feedback.

• Encourage cross-functional
collaboration.

• Create checkpoints.

• Set clear expectations

Inflexibility
Mini waterfalls can be inflexible,
with each iteration being planned
out in advance.

This can make it difficult to adapt to

changing customer needs or
requirements, leading to delays and
cost overruns.
 To avoid this Inflexibility
: build flexibility into the process. This could involve allowing for changes in
requirements, adding or removing features, and adjusting timelines as needed.

Ensure that all stakeholders are communicating frequently and

openly throughout the development process. This can help identify potential roadblocks early and allow
for quick course corrections.

One potential drawback of the mini-waterfall approach is that testing may be

deferred until later stages, leading to costly rework if defects are discovered. Prioritizing testing
throughout the development process can help prevent this.
Quality issues
Mini waterfalls can lead to a focus on
delivering functionality in each iteration
rather than ensuring that the overall
product is of high quality.

This can result in poor quality code,

technical debt, and a lack of scalability.

To avoid this
Define clear requirements.

Use quality assurance techniques.

Monitor progress.
Coordination challenges
Mini waterfalls can make it challenging to
coordinate and integrate work across
teams, leading to integration issues and
delays.

To avoid this
Establish clear roles and responsibilities.

Use project management tools.

Establish a culture of accountability.

Solutions
• Prioritize collaboration,
• Communication,
• Feedback,
• Focus on delivering value to the customer,
• Continuously improve their processes to ensure that they can adapt
to changing customer needs and requirements
• Implement Agile practices
Too Many Meetings
Ø Reduced Productivity

Ø Loss of Focus

Ø Increased Stress

Ø Inefficient Communication

Ø Reduced Creativity
Reduced Productivity
• Meetings take up a significant amount of
time and can reduce the amount of time
available for actual work.

• If there are too many meetings, it can lead

to reduced productivity and decreased
efficiency in completing tasks.

• To avoid this

• Limit the duration of each meeting

Loss of Focus
• Having too many meetings can result in
losing focus on the actual goals of the
project.

• If meetings are held too frequently or last

too long, team members may start to lose
interest and fail to engage in productive
discussions.

• To avoid this

• Only the necessary people attend the

meetings.
Increased Stress
• Constantly attending meetings can be stressful
for team members, particularly if they have a
heavy workload.

• The added pressure of attending meetings can

result in decreased morale and job satisfaction.

• To avoid this

• Have clear objectives and agendas.

Inefficient Communication
• Too many meetings can lead to inefficient
communication.

• If meetings are not structured correctly or have

unclear objectives, it can result in
misunderstandings and miscommunication
among team members.

• To avoid this

• It is essential to schedule meetings

purposefully
Reduced Creativity
• Creative problem solving requires space and time
for reflection and brainstorming.

• If there are too many meetings, it can limit the

opportunities for creative thinking and reduce the
team's ability to come up with innovative solutions.

• To avoid this

• Take Action: Ensure that the meeting ends with

actionable steps and clear assignments.

• This can help to avoid a sense of stagnation and

keep the creative momentum going.
Problems with deadlines
Ø Overcommitment

Ø Changing Requirements

Ø Lack of Communication

Ø Technical Issues

Ø Scope Creep
Overcommitment • One of the most common problems in Agile
development is overcommitment.

• This occurs when the team agrees to take on more

work than they can realistically complete within the
given time frame.

• This can lead to missed deadlines, lower quality work,

and team burnout.

To avoid this

• Estimate Realistic Timelines.

• Communicate Clearly.

• Manage Expectations.

• Learn to Say No.

• Have a Plan B.
Changing Requirements
• Agile methodologies emphasize flexibility and
responding to changing requirements, but this can also
create problems with deadlines.

• If requirements change mid-sprint, it may be difficult to

complete all the necessary work within the original
deadline.

To avoid this

• Important to have a clear understanding of the project

goals and requirements
Lack of Communication
• Effective communication is essential in Agile
development.

• If team members are not communicating

effectively, it can lead to misunderstandings and
missed deadlines.

• It is important to have regular meetings and status

updates to ensure that everyone is on the same
page.

To avoid this

• Communicate effectively
Technical Issues
• Technical problems such as bugs or system failures can
cause delays and impact deadlines.

• It is important to have a plan in place for dealing with

technical issues, such as having a dedicated support
team or contingency plan.

To avoid this

• Test Equipment and Software twice before deadlines.

• Backup Data.

• Have Technical Support Available:

Scope Creep
• Scope creep occurs when the project
requirements or deliverables expand beyond
what was originally planned.

• This can result in missed deadlines, as well

as increased costs and resources.

To avoid this

• Define Project Scope

• Important to involve all stakeholders in the

project
Solutions
• Important to have a clear understanding of the project goals and
requirements
• Communicate effectively
• Regularly review progress
• Adjust plans as necessary.
• Important to involve all stakeholders in the project