UNIT -4

INTRODUCTION TO SCRUM

Agile Scrum Framework, Scrum Artifacts, Meetings, Activities and Roles, Scrum Team
Simulation, Scrum Planning Principles, Product and Release Planning, Sprinting:
Planning, Execution, Review and Retrospective; User story definition and Characteristics,
Acceptance tests and Verifying stories, Burn down chart, Daily scrum, Scrum Case Study.

Definition:
Scrum is an efficient framework within which you can develop software with teamwork. It is
based on agile principles. Scrum is a framework for developing and sustaining complex
products. Ken Schwaber and Jeff Sutherland developed Scrum. Together, they stand behind
the Scrum Rules.

Scrum is a framework which is based on agile principles, a framework that handle simple,
complicated and complex software development.

Scrum is based on continuous improvement in product and process.

Scrum deliver software frequently (value) and it showcase the hidden problems in system
development.

In scrum project move forward with series of iteration called Sprints. Each sprint size is
typically two to four weeks long. It is based on inspect and adaptive cycle. Producing product
incrementally and iteratively reduces the risk and enhance visibility.

Scrum has simple roles, activities and artifacts

The following are the roles in Scrum:

1. Product Owner 2. Scrum Master 3. Team

Product Owner

 Product Owner (PO) is client's representative.

 Define features of product.

 Decide release date and content.

 Priorities features according to market value.

 Be responsible for the profitability of product.

 Accept or reject work items.

Scrum Master

 Coach for scrum team.

 Enacting scrum values.

 Ensure team's productivity.

 Build winning team.

 Apply agile principles and make system effective.

Team

 5-9 Members team (Developer , Tester).

 Self-organizing, High performance team.

 Build winning product.

 Work collaboratively and share responsibilities.

 Cross functional team.

 Scrum Activities

1. Sprint Planning

2. Daily Scrum

3. Sprint Review

4. Sprint Retrospective

5. Product Backlog Refinement

Sprint Planning:

Goal: Team to plan and agree on backlog items they can complete and confirm the tasks required to
support acceptance.

Who: Scrum Team, Scrum Master, Product owner.

When: Beginning of the Sprint.

Duration: 4 Hours for 2 weeks sprint.

How: In 2 parts.

Part 1: Define what needs to be done.

Part 2: How to achieve goal.

Input: Priority, Product Backlog, Acceptance criteria, Capacity.

Output: Sprint goal, Sprint Backlog, Tasks and their estimates, burn down chart, DOD,
Development plan/ Strategy.

Description

 Product owners present the backlog items in priority order for review.

 Review and clarify user Backlog items/stories.

 Breakdown larger stories and each story into task and acceptance criteria.

 Task are estimated in hours by team.

 Developer and tester assigned to task.

 Process continue until all available hours are used for the sprint.

 Output of sprint planning is Sprint backlog, Estimated tasks, etc.

Daily Scrum:

The Daily Scrum, also known as the Daily Stand-Up, is a crucial event in the Scrum
framework. It is a short, time-boxed meeting that occurs every day of the sprint. The purpose
of the Daily Scrum is to synchronize the team’s activities, inspect progress toward the sprint
goal, and identify any impediments that need to be addressed.

Objectives of the Daily Scrum

 Synchronize Activities: Ensure all team members are aligned and working towards the
sprint goal.

 Inspect Progress: Review what has been accomplished since the last Daily Scrum.

 Identify Impediments: Highlight any obstacles that are hindering progress and need to
be addressed.

 Adapt Plans: Adjust plans and strategies as needed to ensure the sprint goal is
achieved.

Participants

 Development Team: All members of the Development Team participate.

 Scrum Master: Facilitates the meeting, ensuring it stays on track and within the time-
box.

 Product Owner: May attend but is not mandatory. They can provide input if needed.

Daily Scrum Format

The Daily Scrum typically follows a structured format where each team member answers three key
questions:

1. What did I do yesterday to help the team meet the sprint goal?

2. What will I do today to help the team meet the sprint goal?

3. Are there any impediments that prevent me or the team from meeting the sprint goal?

Best Practices for Effective Daily Scrums

 Time-Boxed to 15 Minutes: Keep the meeting short and focused.

 Stand Up: Encourage participants to stand to keep the meeting brief and energetic.

 Focus on Collaboration: The meeting is for the team to collaborate, not for detailed
problem-solving or status reporting to management.
  Be Consistent: Hold the Daily Scrum at the same time and place every day to
establish a routine.

 Impediment Management: The Scrum Master should note any impediments raised and
work to resolve them outside of the meeting.

Example Agenda for a Daily Scrum

1. Start the Meeting:

o Scrum Master or a designated team member starts the meeting on time.

2. Team Members Share Updates:

o Each team member answers the three key questions.

3. Identify and Address Impediments:

o Note any impediments mentioned and plan for addressing them after the
meeting.

4. Close the Meeting:

o Conclude the meeting promptly at the 15-minute mark.

Handling Common Challenges

 Going Off-Topic: If discussions stray from the three questions, note the topic and
schedule a separate discussion.

 Extended Meetings: Ensure everyone stays brief and focused. If needed, have the
Scrum Master provide gentle reminders.

 Impediments Not Addressed: The Scrum Master should follow up on impediments

raised to ensure they are resolved quickly.

Flow of the Daily Scrum:

1. Daily Scrum Start: The meeting begins promptly.

2. Team Member Updates:

o Yesterday: What did I do yesterday?

o Today: What will I do today?

o Impediments: Are there any impediments?

3. Note Impediments: The Scrum Master notes any impediments.

4. Meeting End: The meeting concludes within 15 minutes.

Goal: Plan for the day, Inspect and Adapt daily towards reaching the sprint goal.

Who: Scrum Team, Scrum Master.

When: Daily throughout the sprint.

Duration: 15 minutes maximum.

How: Team members form a group to focus on daily plan, Discuss on issues faced yesterday.

Input: Current status, risks, and done work.

Output: Plan for the day, task to work.

Description:

 Daily development Team standup for 15 minutes in circle and talk only on three
points.

o What I did since last daily scrum meeting?

o What I am planning to work on today?
o Impediments (Issue/blocker) if any?

 Scrum master protect the team and facilitate for being effective.

 This gives an opportunity to team to inspect and adapt daily on the sprint goal.
Sprint Review:
Goal: Get feedback on product development. Inspect and adapt on the product feature.

Who: Scrum Team, Scrum= Master, Product owner, Stakeholders.

When: Last day of sprint.

Duration: 2 hours for a 2 week sprint.

How: Demonstrate the working product to all.

Input: Sprint goal, 100% done stories, acceptance criteria.

Output: Acceptance, feedback on demonstrated stories.

Description:

 During this meeting team demonstrate 100% completed work.

 Scrum master facilitate the environment.

 In case any changes or new request, Product owner (PO) note and updates the product
backlog as required.

 Product owner is final decision maker on acceptance.

The Sprint Review is an essential Scrum event held at the end of each sprint.
Its purpose is to inspect the increment and adapt the product backlog based on feedback from
stakeholders.
It ensures transparency and alignment with the stakeholders' needs and helps the Scrum team
make informed decisions about the future direction of the product.
Objectives of the Sprint Review
 Inspect the Increment: Demonstrate the working product increment to stakeholders
and ensure it meets the Definition of Done.
 Gather Feedback: Obtain feedback from stakeholders to understand their
perspectives and needs.
 Adapt the Product Backlog: Update the product backlog based on the feedback
received and any changes in the business context.
 Celebrate Achievements: Acknowledge the team's accomplishments and celebrate
the progress made.

Participants
 Scrum Team: Product Owner, Scrum Master, and Development Team.
 Stakeholders: Customers, users, and anyone with an interest in the product.
Sprint Review Agenda
1. Welcome and Introduction:
o Scrum Master or Product Owner welcomes participants and outlines the
agenda.
2. Sprint Goal Review:
o Product Owner reviews the sprint goal and the intended outcomes.

3. Demonstration of the Increment:

o Development Team demonstrates the work completed during the sprint.

o The demonstration focuses on completed items and shows how the product
increment meets the Definition of Done.
4. Feedback Gathering:
o Stakeholders provide feedback on the demonstrated increment.

o Questions and discussions are encouraged to clarify any doubts and gather
insights.
5. Product Backlog Update:
 o Product Owner discusses any changes to the product backlog based on the
feedback and new information.
o Updates may include reprioritizing items, adding new user stories, or refining
existing ones.
6. Review of Market and Business Context:
o Discuss any changes in the market or business context that may impact the
product.
o Adjust the product strategy if necessary.

7. Next Steps and Wrap-Up:

o Outline the next steps, including the focus for the next sprint.

o Summarize the key takeaways and thank participants for their input and
collaboration.
Best Practices for Effective Sprint Reviews
 Prepare in Advance: Ensure the team is prepared for the review with a well-prepared
demo and relevant data.
 Engage Stakeholders: Actively involve stakeholders in the review and encourage
their participation and feedback.
 Focus on Value: Highlight the value delivered during the sprint and how it aligns
with the product vision and goals.
 Be Transparent: Honestly discuss what was completed, what was not, and any
challenges faced during the sprint.
 Use Visuals and Metrics: Use visuals, charts, and metrics to support the
demonstration and discussions.
 Time Management: Stick to the agenda and manage time effectively to cover all
important aspects of the review.
Example Agenda for a 1-Hour Sprint Review
1. Welcome and Introduction (5 minutes):
o Introduction by Scrum Master or Product Owner.

2. Sprint Goal Review (5 minutes):

o Product Owner reviews the sprint goal and objectives.

3. Demonstration of Increment (20 minutes):

o Development Team demonstrates completed user stories.

4. Feedback Gathering (15 minutes):

 o Stakeholders provide feedback and ask questions.

5. Product Backlog Update (10 minutes):

o Product Owner discusses changes to the product backlog.

6. Wrap-Up and Next Steps (5 minutes):

o Summary of key points and next steps.

The Sprint Review is a crucial event that fosters collaboration, transparency, and continuous
improvement. It ensures that the product remains aligned with stakeholders' needs and that
the team is always working on the most valuable tasks.

Sprint Retrospective:

A sprint retrospective is a key meeting in the Agile methodology, particularly in Scrum,

where the team reflects on the past sprint to improve future performance. The goal is to
identify what went well, what didn’t go well, and what could be improved. Here’s a typical
structure for a sprint retrospective:
1. Set the Stage:
o Welcome the team and set a positive tone.

o Review the agenda and goals of the retrospective.

2. Gather Data:
o Discuss what happened during the sprint.

o Use tools like:

 Mad, Sad, Glad: Team members write down what made them mad, sad,
or glad during the sprint.
 Start, Stop, Continue: Team members suggest things to start doing,
stop doing, and continue doing.
 Timeline: Map out the sprint’s events to visualize when things
happened.
3. Generate Insights:
o Identify patterns and root causes of issues.

o Discuss how the team’s processes and behaviors impacted the sprint.

4. Decide What to Do:

o Prioritize the insights and decide on action items.

o Ensure the actions are specific, achievable, and assigned to team members.
 5. Close the Retrospective:
o Summarize the key takeaways and action items.

o Reflect on the retrospective itself and seek ways to improve it.

Tips for Effective Sprint Retrospectives:

 Foster an open and honest environment where everyone feels safe to speak up.
 Focus on actionable items rather than just identifying problems.
 Keep the meeting timeboxed to ensure it remains efficient and focused.
 Rotate the retrospective format to keep it engaging and prevent it from becoming
routine.

Goal: To inspect and adapt to become more effective and efficient on process, people, culture
aspect.
Who: Scrum Team (anyone participation is decided by the scrum team on invite basis only).
When: Last day of sprint.
Duration: 2 hours for a 2 week sprint.
How: Close room discussion of observer pattern and desire results/improvements.
Input: Observation, issues, experience, pattern in behavior, recommendations, feedback and
information.
Output: List of activities/steps/suggestions that help to make more effective and efficient.
Action items on the team
Description:
 Participation in the discussion to inspect and adapt as scrum team.
 Scrum master play vital role in sprint retrospective, Scrum master bring in the culture
of openness, trust and respect as people discuss the improvement areas, facilitate and
focus on improvement and changes that pointing fingers at others.
 This is platform to scrum master to help team resolve ineffectiveness in the systems.
 Inspect and Adapt: Try everything that makes sense, reject things that didn’t work
even after repeated trails. Shape your culture, process and practice.

Product Backlog Refinement:

Product Backlog Refinement (also known as backlog grooming) is a collaborative
process in which the development team and the product owner review and prioritize the items
in the product backlog to ensure that the backlog remains relevant, detailed, and appropriately
ordered. This helps prepare stories for future sprints and ensures the team is aligned on
upcoming work. Here’s how to conduct an effective Product Backlog Refinement session:
Objectives:
1. Clarify Requirements: Ensure that all items are well-understood by the team.
2. Prioritize Work: Ensure the most valuable items are prioritized.
3. Break Down Large Items: Decompose large stories into smaller, more manageable
ones.
4. Estimate Effort: Assign effort estimates to backlog items.
Participants:
 Product Owner
 Development Team
 Scrum Master (optional, but can help facilitate)


Key Activities:
1. Review and Update Backlog Items:
o Clarify and Discuss: The product owner explains new or complex items,
providing the necessary context and answering any questions.
o Refine Acceptance Criteria: Ensure that each item has clear and testable
acceptance criteria.
 o Prioritize Items: Discuss and adjust the priority of backlog items based on
business value, dependencies, and team capacity.
2. Break Down Epics:
o Identify large user stories (epics) and break them down into smaller, more
actionable stories that can be completed within a sprint.
3. Estimate Effort:
o Use estimation techniques (e.g., Planning Poker, T-shirt sizing) to assign effort
estimates to each backlog item. This helps with sprint planning and capacity
assessment.
4. Update and Add Details:
o Ensure that the description, acceptance criteria, and any other relevant details
are up-to-date for each item.
5. Identify Dependencies and Risks:
o Discuss and document any dependencies between items and potential risks
that could impact delivery.
Tips for Effective Refinement:
 Regular Sessions: Conduct backlog refinement regularly (e.g., once a week) to keep
the backlog healthy.
 Timebox the Meeting: Limit the duration (e.g., 1 hour) to keep discussions focused
and efficient.
 Collaborative Effort: Encourage active participation from the entire team to ensure a
shared understanding.
 Stay Aligned with Sprint Goals: Ensure that refined items align with the product
vision and upcoming sprint goals.
Sample Agenda for a Refinement Session:
1. Introduction:
o Quick overview of the session’s goals and agenda.

2. Review New and Updated Items:

o Product owner presents new items added to the backlog since the last session.

o Discuss any updates or changes to existing items.

3. Clarify and Estimate:

o Discuss details and clarify acceptance criteria for selected items.

o Estimate effort using the chosen estimation technique.

 4. Prioritize and Decompose:
o Re-prioritize items if necessary based on the latest information.

o Break down large items into smaller stories.

5. Wrap Up:
o Summarize the refined items and any action items or follow-ups.

o Confirm the date and time for the next refinement session.

Goal: Keep product backlog items ready, uncertainty to certainty.

Who: Scrum Team, Scrum master, product owner.
When: Continuous process, in between the sprints.
Duration: 1-3 hours depending on the team’s need.
How: priorities the items as per business value. Add, remove, modify existing product
backlog item to achieve release scope/goal. Identify and discuss risks, dependencies and other
uncertain items in acceptance criteria.
Input: release strategy, priority, product backlog, dependency/risk.
Output: product backlog items 100% ready for future sprint.
Description:
  Product owner provide clarity on each product backlog item (All uncertainty clarified
into certainty).
 Product owner update product backlog. 100% be present and involve all team
members.
 Team understands, carefully listen to need of product owner, understand the
acceptance criteria. Help product owner to order the backlog.

Scrum Artifacts:
In Scrum, artifacts are tangible outputs that provide transparency and opportunities for
inspection and adaptation. These artifacts ensure that all stakeholders have a clear
understanding of the product being developed and the progress being made. The three
main Scrum artifacts are:

Scrum artifacts are tools that help Scrum teams visualize and organize information
about a product being developed. They are designed to increase transparency and help
the team and stakeholders adapt their work.

1. Product Backlog
2. Sprint Backlog
3. Increment

1. Product Backlog

The Product Backlog is a prioritized list of all the work that needs to be done on the
product. It is maintained by the Product Owner and is continuously refined based on
feedback and changes in requirements.

Key Features:

 Items: Each item in the backlog is a Product Backlog Item (PBI), which could be
features, functions, requirements, enhancements, and fixes.

 Prioritization: Items are prioritized based on business value, risk, dependencies, and
other factors.
  Estimation: Items are estimated in terms of effort or complexity.

 Dynamic: The backlog evolves as the product and its environment change.

Example:
# Product Backlog
1. User Registration
- Description: Allow users to register with email and password.
- Priority: High
- Estimate: 5 Story Points
- Acceptance Criteria:
- Users can input their email.
- Users can set a password.
- Users receive a confirmation email.

2. Password Reset
- Description: Allow users to reset their password.
- Priority: Medium
- Estimate: 3 Story Points
- Acceptance Criteria:
- Users can request a password reset.
- Users receive a password reset email.
- Users can set a new password.

2. Sprint Backlog
The Sprint Backlog is a subset of the Product Backlog items selected for the current sprint, along
with a plan for delivering them. It is created and owned by the Development Team.
Key Features:
 Selected PBIs: Items chosen from the Product Backlog for the sprint.
 Tasks: Detailed tasks necessary to deliver the selected PBIs.
  Commitment: Represents the work the team commits to complete in the sprint.
 Dynamic: Can be updated throughout the sprint as new information emerges.

Example:
# Sprint Backlog for Sprint 1
## Selected PBIs
1. User Registration (5 Story Points)
- Task: Design registration form
- Task: Implement form validation
- Task: Integrate with backend
- Task: Send confirmation email

2. Password Reset (3 Story Points)

- Task: Design reset request form
- Task: Implement reset logic
- Task: Integrate email service
- Task: Create new password form

3. Increment
The Increment is the sum of all the Product Backlog items completed during a sprint,
along with the value of increments from all previous sprints. It must be in a usable
state and meet the team's Definition of Done.
Key Features:
 Usable: Must be in a usable condition, regardless of whether the Product Owner
decides to release it.
 Complete: Adheres to the Definition of Done, meaning it is fully functional, tested,
and integrated.
 Transparent: Provides a clear picture of what has been accomplished and what
remains.
Example:
# Increment at the End of Sprint 1
## Completed PBIs
1. User Registration
- Users can register with email and password.
- Users receive a confirmation email.

2. Password Reset
- Users can request a password reset.
- Users receive a password reset email.
- Users can set a new password.

## Definition of Done:
- Code is peer-reviewed.
- Unit tests pass.
- Integration tests pass.
- Documentation is updated.
- Feature is demoed to stakeholders.
Supporting Artifacts
While the above are the primary artifacts, Scrum teams often use additional
supporting artifacts to aid transparency and tracking:
 Burndown Charts: Visual representation of remaining work in a sprint or project.
 Task Boards: Visual tool for tracking the status of tasks within a sprint.
 Release Plans: Outline of planned releases and their associated PBIs.
Scrum Information Radiators are visual tools used to display the status, progress, and key
metrics of a project to the entire team and stakeholders. These tools promote transparency and
enable quick, informed decisions. Common information radiators in Scrum include task
boards, burndown charts, and cumulative flow diagrams. Here’s a detailed look at these
radiators and how they can be used effectively:

1. Task Board
A task board is a visual representation of the work planned for the current sprint. It helps the
team track the progress of tasks and ensures everyone is aware of the current status.
Components:
 Columns: Typically include stages like To Do, In Progress, In Review, Done.
 Cards: Represent individual tasks or user stories.
 Swimlanes: Optional horizontal divisions to separate different types of work or team
members
# Task Board
## To Do
- Design registration form
- Create test cases for password reset
## In Progress
- Implement form validation
- Integrate backend for registration
## In Review
- Send confirmation email
## Done
- Create new password form

2. Burndown Chart
A burndown chart visually tracks the progress of the sprint by showing the amount of work
remaining over time. It helps the team understand if they are on track to complete the sprint
goals.
Components:
 X-axis: Represents time (days of the sprint).
 Y-axis: Represents remaining work (story points, hours, or tasks).
 Ideal Line: A straight line from the total work at the start of the sprint to zero at the
end of the sprint.
 Actual Line: Shows the actual remaining work as the sprint progresses.
Example:
# Burndown Chart

| Day | Work Remaining (Story Points) |

 |-----|-------------------------------|
| 1 | 20 |
| 2 | 18 |
| 3 | 15 |
| 4 | 12 |
| 5 | 10 |
|6 |7 |
|7 |5 |
|8 |3 |
|9 |1 |
| 10 | 0 |

3. Cumulative Flow Diagram (CFD)

A cumulative flow diagram shows the amount of work in different stages of the workflow
over time. It helps identify bottlenecks and understand how work progresses through the
system.
Components:
 X-axis: Represents time.
 Y-axis: Represents the number of work items.
 Bands: Each color band represents a stage in the workflow (e.g., To Do, In Progress,
Done).
# Cumulative Flow Diagram

| Day | To Do | In Progress | In Review | Done |

|-----|-------|-------------|-----------|------|
| 1 | 10 |5 |2 |0 |
|2 |8 |7 |2 |0 |
|3 |6 |8 |3 |0 |
|4 |4 |7 |4 |2 |
|5 |2 |6 |3 |4 |
|6 |1 |4 |2 |6 |
|7 |0 |3 |1 |9 |

4. Sprint Goal Board

A sprint goal board displays the sprint goals and tracks their progress. It ensures the team
remains focused on the agreed objectives for the sprint.
Components:
 Sprint Goals: Clearly defined objectives for the sprint.
 Progress Indicators: Visual markers indicating the progress towards achieving each
goal.
# Sprint Goal Board

## Sprint Goals
1. Implement user registration
2. Implement password reset functionality

## Progress
- User Registration: 80% Complete
- Password Reset: 60% Complete

5. Impediment List
An impediment list tracks obstacles that hinder the team’s progress. It helps the Scrum
Master address and resolve these issues promptly.
Components:
 Impediment: Description of the obstacle.
 Status: Current status (e.g., Identified, In Progress, Resolved).
 Owner: Person responsible for resolving the impediment.
# Impediment List

| Impediment | Status | Owner |

|------------------------------------|------------|-------------|
| Delay in backend API development | In Progress| John |
| Lack of test environment | Identified | Scrum Master|
| Conflicting priorities with another project | Resolved | Product Owner|

Benefits of Information Radiators:

 Transparency: Provides visibility into the team’s progress and current state.
 Alignment: Ensures all team members and stakeholders are on the same page.
 Accountability: Encourages ownership and accountability within the team.
 Early Detection: Helps identify issues early, allowing for timely intervention.
1. Burn Down Chart
A Burn Down Chart is a visual representation used in Agile project management,
specifically within the Scrum framework, to track the progress of work over time. It shows
the amount of work remaining versus time left in a sprint, helping teams predict if they will
complete their tasks by the end of the sprint.
Key Features of a Burn Down Chart:
 Axes: The X-axis typically represents time (days of the sprint), and the Y-axis
represents the amount of work remaining (usually measured in story points or hours).
 Ideal Line: This is a straight line drawn from the top-left corner (start of the sprint) to
the bottom-right corner (end of the sprint), representing the ideal pace at which work
should be completed to finish on time.
 Actual Burn Down Line: This line shows the actual amount of work remaining day
by day. It helps the team understand whether they are on track, ahead, or behind
schedule.
Purpose of a Burn Down Chart:
 Tracking Progress: Helps the team visualize their progress toward sprint goals.
 Forecasting: Provides a quick view of whether the team is likely to complete all tasks
by the end of the sprint.
 Identifying Issues Early: Helps identify if there is a lag in progress, allowing the
team to address potential blockers or issues promptly.
Interpreting a Burn Down Chart:
 On Track: If the actual burn-down line closely follows the ideal line, the team is on
track to complete the sprint on time.
 Behind Schedule: If the actual burn-down line is above the ideal line, the team is
behind schedule and may not complete all tasks in time.
 Ahead of Schedule: If the actual burn-down line is below the ideal line, the team is
ahead of schedule and may finish early.
2. Daily Scrum
The Daily Scrum (also known as the Daily Stand-up) is a short, time-boxed meeting that
happens every day during a sprint. It is a key component of the Scrum framework and is
designed to ensure the team remains aligned and communicates effectively.
Key Characteristics of a Daily Scrum:
 Time-boxed: The meeting is strictly limited to 15 minutes, ensuring it remains
concise and focused.
 Participants: Attended by the Development Team members, but the Scrum Master
and Product Owner may also attend as facilitators or observers.
 Purpose: To synchronize activities, discuss progress towards the sprint goal, and plan
the next 24 hours.
Typical Structure of a Daily Scrum: Each team member answers three key questions:
1. What did I do yesterday to help the team meet the sprint goal?
2. What will I do today to help the team meet the sprint goal?
3. Are there any impediments that prevent me or the team from meeting the sprint
goal?
Benefits of Daily Scrum:
 Transparency: Keeps everyone informed about the progress and challenges,
fostering a culture of openness.
 Accountability: Encourages team members to be accountable for their commitments
and progress.
 Improvement: Provides an opportunity to identify and address issues or blockers
early, ensuring continuous improvement.
3. Scrum Case Study
A Scrum Case Study typically involves a real-world example where an organization or team
has implemented Scrum to manage a project or product development. The case study
highlights the challenges faced, the solutions applied using Scrum practices, and the
outcomes achieved.
Components of a Scrum Case Study:
 1. Introduction:
o Overview of the organization or team.

o Description of the project or product being developed.

o Initial challenges or problems faced before adopting Scrum.

2. Implementation of Scrum:
o How Scrum was introduced and implemented within the team.

o Roles defined (Scrum Master, Product Owner, Development Team).

o Adoption of Scrum events (Sprint Planning, Daily Scrum, Sprint Review,

Sprint Retrospective).
o Use of Scrum artifacts (Product Backlog, Sprint Backlog, Increment, Burn
Down Charts).
3. Challenges and Solutions:
o Challenges faced during the adoption and adaptation of Scrum.

o Solutions applied to overcome these challenges.

o Modifications or adaptations to the standard Scrum framework to fit the

team’s context.
4. Results and Outcomes:
o Improvements in team collaboration, productivity, and product quality.

o Success in meeting project goals and timelines.

o Feedback from team members and stakeholders on the effectiveness of Scrum.

5. Lessons Learned:
o Key takeaways and lessons learned from the Scrum implementation.

o Advice for other teams or organizations considering adopting Scrum.

Example of a Scrum Case Study:

 Company: XYZ Software Solutions
 Project: Development of a new customer relationship management (CRM) system.
 Challenges: Delays in delivery, lack of collaboration, unclear requirements.
 Scrum Implementation:
o Appointed a certified Scrum Master to guide the team.

o Created a cross-functional development team and a dedicated Product Owner.

 o Conducted sprint planning meetings to define sprint goals and select backlog
items.
o Held daily stand-ups to track progress and resolve impediments.

o Regular sprint reviews and retrospectives to demonstrate increments and

improve processes.
 Outcomes:
o Reduced time-to-market by 30%.

o Increased team productivity and morale.

o Improved customer satisfaction with regular feedback loops.

Summary
 Burn Down Charts help visualize work progress and predict sprint completion.
 Daily Scrums ensure daily communication and alignment among team members.
 Scrum Case Studies illustrate practical applications of Scrum, showing both
challenges and successes.

User Stories in Agile (and XP)

A user story is a simple, concise description of a feature or functionality from the perspective
of the user. It’s a core component of Agile methodologies like Extreme Programming (XP)
and Scrum, guiding the development process by focusing on delivering value to the user.
User stories help teams break down complex projects into manageable pieces and ensure that
the team is always working on features that provide clear business value.
Structure of a User Story
The typical format for writing a user story is:
 As a [user role],
 I want [goal or action],
 So that [reason or benefit].
For example:
 As a customer,
 I want to search for products by category,
 So that I can find what I’m looking for faster.
This structure captures:
 1. Who the user is (the role).
2. What the user needs or wants to do (the goal).
3. Why the user needs it (the benefit or business value).
Characteristics of Good User Stories (INVEST Model)
The INVEST acronym is a widely accepted guideline for creating good user stories in Agile:
1. Independent:
o The story should be self-contained and not tightly coupled with other stories.
This allows the story to be developed, tested, and delivered independently.
o Example: "As a user, I want to reset my password" can be done independently
of the story "As a user, I want to update my profile information."
2. Negotiable:
o A user story is not a contract. It should be open to discussion and refinement
between the team and the customer. The details can be adapted as more is
learned.
o Example: "I want a faster checkout process" may evolve after discussing
design trade-offs or user feedback.
3. Valuable:
o Each story must deliver clear value to the user or customer. It should be tied to
a business need, addressing real user requirements.
o Example: "As an admin, I want to view user activity logs so that I can monitor
suspicious activity" provides clear value in terms of security.
4. Estimable:
o The story must be estimable so that the team can plan and allocate resources
accordingly. If a story is too vague, it can be broken down further to provide a
clearer estimate.
o Example: A story like "Improve system performance" is too vague. Instead,
break it down into specific tasks like "Reduce page load time for product
pages by optimizing images."
5. Small:
o User stories should be small enough to be completed within a single iteration
or sprint. Larger stories, known as epics, should be broken down into smaller,
actionable stories.
o Example: "As a user, I want to receive an order confirmation email" is small,
whereas "As a user, I want a complete order management system" is too large
and should be divided into smaller stories.
 6. Testable:
o A story must have clear criteria so that it can be tested and verified. If a story
cannot be tested, it means the definition of the feature is incomplete.
o Example: "As a user, I want to add a product to my wishlist so that I can
purchase it later" is testable with specific acceptance criteria (e.g., verify that
products are added to and displayed in the wishlist).
Acceptance Criteria for User Stories
User stories should have acceptance criteria—specific conditions that must be met for the
story to be considered complete. These criteria ensure that both developers and customers
have a clear understanding of the story's requirements.
Example for a story "As a user, I want to reset my password":
 The user must receive a password reset email within 5 minutes.
 The link in the email should expire in 24 hours.
 The new password must meet security requirements (e.g., at least 8 characters,
containing a mix of letters and numbers).
Types of User Stories
1. Functional Stories:
o Describe features or tasks that deliver value directly to the user.

o Example: "As a user, I want to filter products by price so that I can find items
within my budget."
2. Non-Functional Stories:
o Address system attributes like performance, security, or reliability.

o Example: "As an admin, I want the system to log all failed login attempts so
that I can ensure security."
3. Technical Stories:
o These are sometimes needed for behind-the-scenes work like infrastructure or
system improvements that don't deliver direct user functionality but are
necessary for supporting user stories.
o Example: "As a developer, I want to upgrade the database version so that it
supports new features."
Benefits of User Stories
1. User-Centric Focus: Stories focus on delivering features that are directly valuable to
the user, keeping the team aligned with the customer’s needs.
 2. Encourages Collaboration: Writing and refining user stories involve conversations
between developers, testers, and customers, leading to better understanding and
collaboration.
3. Facilitates Iterative Development: Stories help break down large projects into
smaller, manageable chunks that can be delivered iteratively.
4. Adaptable: User stories are flexible and can evolve as more is learned about the
project and the users' needs.
Challenges with User Stories
1. Overly Vague Stories: If user stories are not clearly defined, they can lead to
confusion, delays, or unmet expectations.
2. Scope Creep: Without well-defined acceptance criteria, stories can grow in scope,
leading to incomplete or unfocused work.
3. Difficulty in Splitting Stories: Breaking down large epics into smaller stories can be
challenging, especially if teams are new to Agile.
Conclusion
User stories are a key element in Agile and XP, providing a structured yet flexible way to
capture and communicate user requirements. By following the INVEST principles and
ensuring clear acceptance criteria, user stories help teams stay focused on delivering value
while promoting collaboration and adaptability throughout the development process.