Module 2 :

Measurements and Metrics in Scrum (Detailed for Students)

Scrum is an Agile framework used in software development. It helps teams work in
short iterations (called sprints) and deliver working software frequently.
Metrics in Scrum are ways to measure how well the team is performing and to improve the
process. Think of them as “performance indicators” for the team and the project.

1. Why Do We Measure in Scrum?

The main purposes of metrics in Scrum are:
1. Track progress – Are we completing work as planned?
2. Improve predictability – Can we estimate how much work we can finish in the
next sprint?
3. Identify problems – Are there bottlenecks, delays, or quality issues?
4. Support continuous improvement – Metrics give data for retrospectives.
Important: Metrics are not meant to blame team members. They are learning tools.

2. Key Scrum Metrics

We can divide metrics into 5 categories: Sprint metrics, release/project metrics, quality
metrics, flow metrics, and team health metrics.

A. Sprint Metrics
Sprint metrics measure what happens during a sprint (usually 1–4 weeks).
1. Sprint Burndown Chart
o Shows remaining work day by day in a sprint.
o X-axis: Days of sprint | Y-axis: Story points or hours remaining.
o Helps visualize whether the team is on track to finish the sprint goal.
o Example:

If your team planned 50 story points for a 5-day sprint, the burndown
chart shows how many points remain each day.
2. Velocity
o Average number of story points completed per sprint.
o Helps predict future sprints.
o Example:

Sprint 1 = 30 points, Sprint 2 = 40 points, Sprint 3 = 35 points →

Average velocity = (30+40+35)/3 = 35 points per sprint.
3. Committed vs Completed Work
o Compares planned vs actual work in a sprint.
o Helps improve planning accuracy.

B. Release / Project Metrics

These metrics look at progress over multiple sprints.
1. Release Burndown
o Shows remaining work for the entire release.
o Helps track if the team will finish on time.
2. Epic / Feature Progress
o Tracks the completion of large features or epics across sprints.
o Useful for managers and product owners to see long-term progress.

C. Quality Metrics
Measure how good the software is.
1. Defect Count / Defect Density
o Number of bugs per sprint or per module.
o Example: 10 defects in 200 lines of code → defect density = 10/200 =
0.05.
2. Escaped Defects
o Bugs found after release.
o Helps improve testing before release.
 3. Technical Debt
o Measures shortcuts in coding or design that need fixing later.
o Helps maintain sustainable software development .

D. Flow Metrics
Measure how work moves through the system.
1. Lead Time
o Time from creating a story to delivering it .
o Example: Story created on Nov 1, completed on Nov 5 → Lead time = 5
days.
2. Cycle Time
o Time from starting work to completing it.
o Focuses on team efficiency.
3. Cumulative Flow Diagram (CFD)
o Shows the number of tasks in different states: To Do, In Progress, Done.
o Highlights bottlenecks.

E. Team Health Metrics

Measures team well-being and efficiency.
1. Team Happiness / Morale
o Collected through surveys or retrospectives.
o Happy teams are more productive.
2. Sprint Predictability
o How closely the team delivers what was planned.
o Helps improve planning accuracy over time.

3. Best Practices for Students and Teams

● Focus on learning, not blaming.
● Use a small set of metrics—don’t overwhelm yourself.
● Combine metrics with retrospectives for actionable insights.
● Avoid using velocity for performance comparison—it’s about team capacity, not
individual work.

4. Example Scenario for SYIT Students

Imagine your team is building a mini library management system:
● Planned 20 story points for sprint 1.
● Completed 18 story points.
 ● Velocity = 18 points.
● Burndown chart shows tasks slowly decreasing each day.
● 2 bugs found in QA → defect count = 2.
● Lead time for the first user login feature = 3 days.
From these metrics, the team can discuss:
● Why 2 story points weren’t completed.
● Why bugs occurred and how to prevent them.
● How to improve planning for the next sprint.

Project Management: Scrum vs Waterfall

Project management is all about planning, executing, and delivering a project successfully.
Scrum and Waterfall are two popular approaches, but they are very different in
philosophy and execution.

1. Waterfall Model (Traditional Project Management)

Definition
Waterfall is a linear and sequential approach to project management. Each phase must
be completed before moving to the next .
Phases of Waterfall
1. Requirement Analysis – Gather all requirements at the start.
2. System Design – Design architecture and system components.
3. Implementation / Coding – Develop the system.
4. Testing / Verification – Test the system for bugs.
5. Deployment / Delivery – Release the system to users.
6. Maintenance – Fix issues after release.
Think of it like a waterfall: you can only flow downstream after finishing the previous
stage.
Characteristics
● Sequential, rigid, and plan-driven.
● Changes are difficult and costly after the project starts.
● Works well when requirements are clear and stable.
● Focuses on documentation.
Pros
● Easy to manage with clearly defined milestones.
● Good for projects with fixed scope.
● Simple to understand and document.
Cons
 ● Not flexible; difficult to adapt to changing requirements.
● Late testing may result in costly bug fixes.
● Low customer involvement during development.
Example
Building a library management system with Waterfall:
● Requirement phase: Define all features (add books, issue books, return
books, etc.)
● Design phase: Create database schema and UI design
● Implementation phase: Start coding all features
● Testing phase: Test the entire system
● Deployment phase: Deliver to users
If the librarian changes requirements halfway (like adding a digital catalogue), it’s
hard and expensive to adjust.

2. Scrum (Agile Project Management)

Definition
Scrum is an iterative and incremental approach to project management. Work is done in
short cycles called sprints (usually 1–4 weeks), with continuous feedback and improvement .
Key Roles in Scrum
1. Product Owner (PO) – Defines what needs to be built and prioritizes the backlog.
2. Scrum Master (SM) – Facilitates Scrum, removes obstacles, ensures the process
is followed.
3. Development Team – Builds the product and delivers incrementally.
Key Artifacts
● Product Backlog – List of features prioritized by value.
● Sprint Backlog – Selected tasks for the current sprint.
● Increment – Working product delivered at the end of each sprint.
Key Events
1. Sprint Planning – Decide what to work on in the sprint.
2. Daily Scrum / Standup – 15-minute daily meeting to track progress.
3. Sprint Review – Demonstrate completed work to stakeholders.
4. Sprint Retrospective – Discuss what went well and what to improve.
Characteristics
● Iterative and flexible.
● Frequent customer feedback.
● Continuous improvement.
● Changes can be accommodated even late in development .
Pros
● Flexible and adaptive to changing requirements.
● Early delivery of functional software.
● High customer involvement.
● Improves team collaboration and morale.
Cons
● Less predictable cost and time in early stages.
● Requires experienced team members.
● Needs strong collaboration and communication.
Example
Building a library management system with Scrum:
● Sprint 1: Implement book catalog and search feature
● Sprint 2: Implement issue and return functionality
● Sprint 3: Implement user registration and reports
● After each sprint, review with librarian for feedback and adjust next sprint
backlog
Even if the librarian wants a new feature in Sprint 3, Scrum can handle it easily.

3. Comparison Table: Waterfall vs Scrum

Feature Waterfall Scrum (Agile)

Approach Linear, sequential Iterative, incremental

Flexibility Low High
Customer
Involvement Mostly at start & end Continuous throughout

Risk detected early &

Risk Handling Risk detected late continuously
Delivery At the end of project After every sprint (incremental)
Lightweight, focus on working
Documentation Heavy software
Projects with stable Projects with changing
Best Suited For requirements requirements

4. When to Use Which

● Waterfall – Government projects, construction, or banking software with clear,
fixed requirements.
● Scrum – Software startups, mobile apps, or any project with evolving
requirements.
In summary:
● Waterfall = Plan everything, do it once, deliver at the end.
● Scrum = Build incrementally, adapt frequently, deliver continuously.

Quality Management in Scrum

Quality Management ensures that the software product meets customer expectations and
project requirements, while maintaining high standards of performance, reliability, and
maintainability.
In Scrum, quality is built in, not inspected at the end. Unlike traditional models, Scrum
emphasizes continuous quality improvement throughout development.

1. Key Principles of Quality Management in Scrum

1. Quality is Everyone’s Responsibility
o Developers, testers, Scrum Master, and Product Owner all contribute to
quality.
o There is no separate “quality department”; the team owns it collectively.
2. Built-In Quality
o Quality is integrated into every sprint rather than tested at the end.
o The goal is to deliver potentially shippable increments every sprint.
3. Continuous Feedback
o Frequent reviews with stakeholders ensure the product meets
expectations.
o Issues are identified early, preventing costly fixes later.
4. Continuous Improvement
o Scrum promotes retrospectives to analyze defects and improve processes.

2. Scrum Practices That Ensure Quality

a) Definition of Done (DoD)
● A shared checklist defining when a task or story is considered complete.
● Ensures consistency and quality across the team.
● Example DoD for a story:
o Code implemented and peer-reviewed
o Unit tests passed
o Functional tests completed
o Documentation updated
o Integrated into main branch
Without DoD, the team might consider partially done work as complete, affecting
quality.

b) Continuous Testing
● Testing happens during development, not just at the end.
● Types of testing in Scrum:
1. Unit Testing – Developers test individual modules.
2. Integration Testing – Ensures modules work together.
3. Automated Testing – Speeds up testing during multiple sprints.
4. Acceptance Testing – Product Owner verifies that the feature meets
requirements.

c) Sprint Reviews
● At the end of each sprint, the team demonstrates the working increment to
stakeholders.
● Stakeholders provide feedback, helping catch defects or gaps early.
● Ensures the product is aligned with expectations.

d) Continuous Integration (CI)

● Developers frequently integrate code into a shared repository.
● Automated builds and tests are run to catch issues immediately.
● Reduces integration problems and ensures high-quality software delivery.

e) Retrospectives
● After each sprint, the team discusses:
o What went well
o What went wrong
o How to improve processes
● Helps in reducing defects and improving quality in future sprints.

3. Metrics for Quality Management in Scrum

To measure and ensure quality, Scrum teams often track:
Metric Purpose Example

Number of defects per module/ 5 defects per 1000 lines

Defect Density feature of code
Escaped Defects Bugs found after release 2 bugs reported by users
Test Coverage Percentage of code tested by 80% coverage of core
Technical Debt automated tests modules
Velocity of Defect
Fixes Time taken to fix defects in sprints 3 days average per bug

Using these metrics, teams can continuously monitor and improve quality .

4. Benefits of Scrum Quality Management

● Early detection of defects → lower cost and faster fixes
● Improved product reliability and maintainability
● Better customer satisfaction through continuous feedback
● Encourages collaboration and ownership within the team
● Supports agile continuous improvement culture

5. Example Scenario for Students

Imagine your team is developing a Library Management System:
● Definition of Done: A book search feature must have UI working, code peer-
reviewed, and unit tests passing.
● During Sprint: Developers write and run unit tests; code is integrated
continuously.
● Sprint Review: Librarian tests the search functionality and provides feedback.
● Retrospective: Team notices that many bugs are in the search feature; decides
to improve test coverage in the next sprint.
This cycle ensures high-quality software from the start rather than discovering all bugs
at the end.

Summary:

In Scrum, quality management is proactive, continuous, and team-owned. It’s ensured

through:
● Definition of Done
● Continuous testing & integration
● Sprint reviews and feedback
● Retrospectives and improvement cycles

Customer Management in Scrum

Customer Management in Scrum is the practice of actively engaging with the customer or
stakeholder throughout the project to ensure that the product meets their needs and
delivers value.
Unlike traditional models like Waterfall, where the customer is usually involved only
at the beginning (requirements) and end (delivery), Scrum emphasizes continuous
collaboration with the customer.
1. Key Principles of Customer Management in Scrum
1. Customer Collaboration Over Contract Negotiation
o Scrum values ongoing communication with customers rather than sticking
rigidly to a fixed plan.
o Customers are part of the development process.
2. Deliver Value Frequently
o Scrum delivers small, working increments of the product each sprint
(usually 1–4 weeks).
o Customers can see progress, test features, and provide feedback regularly.
3. Transparency
o Customers can view the product backlog and see what features are
prioritized.
o Sprint reviews give a clear picture of what has been delivered.
4. Adaptability
o Customer feedback is used to adjust priorities or requirements for upcoming
sprints.
o Ensures the product evolves according to real needs, not outdated
specifications.

2. Roles in Customer Management

Role Responsibility in Customer Management

Product Owner Acts as the voice of the customer. Maintains the product backlog,
(PO) prioritizes features based on customer needs.
Customer / Provides feedback and requirements, attends sprint reviews, helps
Stakeholder define acceptance criteria.
Implements features according to backlog priorities and delivers
Scrum Team increments for customer validation.
The Product Owner is the main bridge between the customer and the development
team.

3. Key Practices for Managing Customers in Scrum

a) Product Backlog Management
● The backlog is a prioritized list of features and tasks.
● Product Owner ensures the backlog reflects customer needs and business value.
● Customers can request new features or changes anytime; the PO decides the
priority.
b) Sprint Reviews
 ● Held at the end of each sprint.
● The Scrum team demonstrates the completed features to the customer.
● Customers give feedback, which may affect future sprint priorities.
c) Feedback Loops
● Continuous feedback is a core part of Scrum.
● Short sprints mean feedback is applied quickly, reducing the risk of building
features the customer doesn’t need.
d) Collaboration Tools
● Tools like Jira, Trello, or Azure DevOps allow customers to track progress, view
backlog items, and comment on features.
e) Regular Communication
● Product Owner communicates progress, risks, and changes to the customer.
● Ensures that customer expectations are managed.

4. Benefits of Effective Customer Management in Scrum

Benefit Explanation

High Customer Customers see frequent progress and can influence the
Satisfaction product.
Early detection of requirements misunderstandings reduces
Reduced Risk costly mistakes.
Better Product-Market
Fit Product evolves according to real user needs.

Important features are delivered first, providing immediate

Faster Delivery of Value benefits.
Transparent
Development Customers know exactly what is being developed and why.

5. Example Scenario for Students

Suppose your team is developing a Library Management System:
1. Backlog Creation: The librarian (customer) wants book search, issue/return,
and late fee calculation. The Product Owner prioritizes these features.
2. Sprint 1: Team implements book search.
o Sprint review: Librarian tests it and asks for advanced filters.
o PO updates the backlog to include filters in the next sprint.
3. Sprint 2: Team implements issue/return functionality and advanced search filters.
o Sprint review: Librarian approves features; feedback ensures alignment
with real needs.
 4. Continuous Collaboration: Every sprint, the librarian sees working features and
suggests improvements.
By involving the customer regularly, the team ensures the final product meets actual
requirements and avoids unnecessary features.

6. Key Takeaways for Students

● Scrum treats customers as partners throughout development.
● The Product Owner is the key link between the team and the customer.
● Frequent deliveries and feedback loops reduce risk and improve quality.

Customer managemenDiagram Concept: Customer Management in Scrum

Title: Customer Management in Scrum
Components to include:
1. Customer / Stakeholder
o Provides requirements and feedback.
o Shown on the left side.
2. Product Owner (PO)
o Acts as the bridge between customer and team.
o Prioritizes the backlog.
o Connects to both customer and Scrum team.
3. Scrum Team
o Development team implementing features.
o Delivers working increments each sprint.
4. Product Backlog
o A list of prioritized features/tasks.
o Positioned between PO and Scrum team.
5. Sprint Cycle
o Short iterative cycles (1–4 weeks).
o Includes Sprint Planning → Daily Scrum → Sprint Review → Retrospective.
6. Feedback Loop
o Arrow from Sprint Review back to PO and Customer.
o Represents continuous feedback.
7. Deliverable / Increment
o After each sprint, the team delivers a working feature.

Diagram Layout (Text Version)

[Customer / Stakeholder]


 [Product Owner]


---------------------
| Product Backlog |
---------------------


[Scrum Team]


[Working Increment / Feature]


(Sprint Review / Feedback)

back to Customer
Flow Explanation:
1. Customer provides requirements and feedback → Product Owner.
2. PO prioritizes tasks → Product Backlog.
3. Scrum Team picks tasks from backlog → implements features.
4. Working increments delivered each sprint → Sprint Review.
5. Customer reviews, gives feedback → PO updates backlog → next sprint.
● t is proactive, continuous, and transparent.

Risk Management in Scrum

Risk Management is the process of identifying, assessing, and responding to risks in a
project to minimize negative impacts.
In Scrum, risk management is integrated into the process, rather than being a separate
phase like in traditional Waterfall. Scrum handles risk continuously and proactively.

1. Key Principles of Risk Management in Scrum

1. Continuous Identification
o Risks are identified throughout the project, not just at the beginning.
o Daily stand-ups, sprint planning, and retrospectives help uncover risks
early.
2. Early Delivery Minimizes Risk
o Scrum delivers small increments of working software frequently.
o Problems are detected early, reducing the impact of risks.
3. Transparency
o Scrum promotes openness about issues and obstacles.
o Risks are visible to the entire team and stakeholders.
4. Collaboration and Adaptation
 o Scrum teams work together to mitigate risks.
o Feedback from customers allows adaptation to changing conditions or
new risks.

2. Common Types of Risks in Scrum

Risk Type Example

Technology chosen may not support required

Technical Risk features.
Requirement Customer requirements are unclear or may
Risk change.
Resource Risk Key team member leaves or is unavailable.
Sprint deadlines may not be met due to
Schedule Risk underestimation.
Delivered features may contain defects or fail to
Quality Risk meet DoD.
Market or business conditions change during
Business Risk development.

3. Risk Management Practices in Scrum

a) Product Backlog Prioritization
● Product Owner prioritizes high-risk items earlier in the backlog.
● Tackling risky or complex features early reduces uncertainty later.
Example: If integrating a new payment gateway is technically complex, it is done in
the first sprint to uncover issues early.

b) Short Sprints / Iterations

● Short iterations (1–4 weeks) limit exposure to risk.
● If a sprint fails or a feature cannot be implemented, risk impact is contained.

c) Daily Scrum / Standups

● Team members report obstacles or potential risks daily.
● Enables early mitigation.
Example: A developer reports difficulty integrating a library; team can address it before
it becomes a bigger problem.

d) Definition of Done (DoD)

● Ensures that work meets quality standards before completion.
 ● Reduces the risk of low-quality code causing defects later.

e) Sprint Review
● Stakeholders review incremental deliveries.
● Early detection of mismatched requirements or technical flaws reduces
business risk.

f) Retrospectives
● Teams reflect on what went wrong and what could be improved.
● Helps prevent the same risks in future sprints.

4. Risk Management Cycle in Scrum

1. Identify Risks → List potential issues from backlog, standups, retrospectives.
2. Assess Risks → Determine probability and impact.
3. Plan Response → Mitigate, accept, transfer, or avoid the risk.
4. Monitor Risks → Track during sprints and update backlog accordingly.
Because Scrum is iterative, this cycle happens every sprint, making it more effective
than one-time risk planning.

5. Metrics for Risk Management

Scrum teams often use metrics to track risks and prevent them:
Metric Purpose

Defect Density Identify potential quality risks early.

Track defects found after delivery to reduce
Escaped Defects future risk.
Variations in velocity may indicate schedule or
Velocity Stability resource risks.
Backlog Risk High-risk backlog items prioritized for early
Ranking sprints.

6. Example Scenario for Students

Imagine your team is developing a Library Management System:
1. Technical Risk: Integrating barcode scanning for books may fail.
o Mitigation: Implement barcode feature in Sprint 1.
2. Requirement Risk: Librarian may change late fees rules.
o Mitigation: Build late fee module in a later sprint and review rules every
sprint.
 3. Quality Risk: Search function may return wrong results.
o Mitigation: Include automated tests and peer review in DoD.
By addressing risks in small increments, Scrum reduces the chance of major project
failure.

7. Key Takeaways
● Risk management in Scrum is continuous, proactive, and collaborative.
● High-risk items are tackled early to reduce uncertainty.
● Frequent reviews, feedback loops, and retrospectives detect and mitigate risks
effectively.
● Metrics and DoD help maintain quality and reduce technical risks.

Cost Management in Scrum

Cost Management is the process of planning, estimating, monitoring, and controlling project
costs to ensure the project stays within budget while delivering value.
In Scrum, cost management is adaptive and iterative, rather than fixed upfront like in
Waterfall. Costs are managed through continuous planning, incremental delivery, and
frequent feedback.

1. Key Principles of Cost Management in Scrum

1. Incremental Spending
o Costs are incurred per sprint, based on the features being developed.
o This avoids large upfront expenditures on uncertain requirements.
2. Value-Based Approach
o Spending is prioritized for features that deliver the most business value first.
o Ensures ROI (Return on Investment) is maximized.
3. Transparency
o Costs, estimates, and progress are visible to stakeholders.
o Helps in managing budget expectations.
4. Adaptive Planning
o Budget is adjusted as requirements evolve.
o Teams re-prioritize backlog items to align with budget constraints and
business priorities.

2. Cost Management Practices in Scrum

a) Product Backlog Prioritization
● Product Owner prioritizes features according to value vs cost.
 ● High-cost, low-value items may be deferred or refined.
Example:
● Feature A (book search) costs 10,000 INR, Feature B (advanced reports)
costs 30,000 INR.
● Product Owner prioritizes Feature A to deliver value early within budget.

b) Sprint Planning and Budgeting

● Each sprint has planned work and cost estimation.
● The Scrum team estimates effort (in story points or hours), which translates
to cost per sprint.
Example:
● Sprint 1: 5 stories × estimated 8 hours each × developer hourly rate = Sprint
cost.

c) Iterative Delivery Reduces Risk

● Small, frequent increments prevent overspending on features that may change.
● Budget is only spent on approved, developed features.

d) Monitoring and Reporting

● Track actual cost vs planned cost per sprint.
● Burn rate (cost per sprint) can be monitored to keep the project on budget.
Metrics:
● Planned vs Actual Cost – Shows overspending or savings per sprint.
● Cost per Feature / Story Point – Helps predict cost for future sprints.

e) Transparency with Stakeholders

● Sprint reviews allow stakeholders to see progress and costs incurred.
● Adjustments to backlog or scope can be made to stay within budget.

3. Metrics for Cost Management in Scrum

Metric Purpose

Planned vs Actual Track if the sprint/project is within

Cost budget.
Helps estimate cost of future
Cost per Story Point features.
Measures how fast the budget is
Burn Rate being spent.
Value Delivered vs
Cost Measures ROI of completed features.

4. Example Scenario for Students

Imagine your team is developing a Library Management System:
● Budget: 100,000 INR
● Sprint 1: Develop book search feature
o Estimated cost: 20,000 INR
o Actual cost: 18,000 INR
● Sprint 2: Develop book issue/return module
o Estimated cost: 25,000 INR
o Actual cost: 30,000 INR
At the end of Sprint 2, Product Owner reviews:
● Cost overruns in Sprint 2 require re-prioritizing remaining backlog.
● Expensive features with low value might be postponed to stay within budget.
Scrum allows flexible budget control while still delivering value early.

5. Key Takeaways
● Cost management in Scrum is iterative, adaptive, and value-driven.
● Costs are monitored per sprint, not only at the end of the project.
● Product Owner prioritizes backlog items to maximize value within budget.
● Metrics like planned vs actual cost, burn rate, and ROI are essential for
transparency.