PSM I Understanding and Applying the Scrum Framework

Understanding and Applying the Scrum Framework Detailed Explanation

Scrum revolves around key principles, roles, events, and artifacts that allow teams to work in an agile, iterative manner.

1. Scrum Theory and Principles

Scrum operates on three core principles: Transparency, Inspection, and Adaptation. These principles provide the foundation for Scrum practices and guide teams in their development journey.

1.1 Transparency

Transparency ensures that everyone involved in the project has a clear view of what's happening. In Scrum, transparency means that:

• Work visibility: The entire Scrum team, as well as stakeholders, can see and understand the current state of work. For example, the Product Backlog and Sprint Backlog should be visible to everyone. If work is not progressing as expected, it is clear to all.

• Access to information: Decisions about what to work on, why certain things are prioritized, or which tasks are blocked should be open for everyone to discuss. This builds trust within the team and ensures that all stakeholders are informed.

• Scrum artifacts are transparent: Scrum artifacts (like the Product Backlog, Sprint Backlog, and Increment) should be accessible to the team and stakeholders. This makes it easier to monitor progress and address any issues promptly.

1.2 Inspection

Inspection is about checking the current state of work at regular intervals. In Scrum:

• Scrum events encourage inspection: The events like Sprint Review and Daily Scrum are designed for inspection.

• What to inspect: The team reviews its progress towards the Sprint goal, the quality of the work done, and if there are any issues or risks. For instance, during the Daily Scrum, team members briefly discuss what they’ve completed, what they plan to work on, and any challenges they are facing.

• Frequent reviews: Scrum promotes frequent inspection to identify problems early. If an issue arises, it can be dealt with before it grows larger.

1.3 Adaptation

Adaptation is about making changes based on what was discovered during the inspection. After inspecting, teams must adjust their work to ensure progress towards goals.

• After inspection: Teams may need to change their strategy, approach, or techniques. For example, if the progress of the Sprint is not aligned with expectations, adjustments might be made in the form of re-prioritizing work in the Sprint Backlog.

• Continuous improvement: Scrum teams constantly adapt based on new insights and changing circumstances. This iterative process ensures that the team is always improving and responding to change in an effective way.

• Process improvements: During the Sprint Retrospective, the team evaluates how they worked and identifies improvements to the process, helping the team evolve and perform better in the future.

2. Scrum Roles

Scrum defines three primary roles, each with its own distinct responsibilities. The roles are designed to create a balance between leadership, vision, and execution.

2.1 Scrum Master

The Scrum Master is not a traditional manager. Instead, they serve as a servant-leader, ensuring that the Scrum team functions optimally. Their role is more about coaching and facilitating than directing. Key responsibilities include:

• Promoting Scrum values and principles: The Scrum Master makes sure everyone on the team understands and follows Scrum practices. This includes reinforcing principles like collaboration, commitment, and respect.

• Facilitating the team’s self-organization: The Scrum Master coaches the team to become self-organizing. This means they should be empowered to make decisions about how they will achieve the Sprint goal, rather than being told what to do.

• Removing blockers: If there are any impediments or obstacles that are preventing the team from making progress (e.g., technical issues, resource shortages, organizational barriers), the Scrum Master works to remove them.

• Protecting the team from distractions: External pressures or requests can interfere with the team’s focus. The Scrum Master ensures that the team can work without unnecessary interruptions.

• Guiding Scrum events: The Scrum Master facilitates Scrum events like Sprint Planning, Sprint Review, and Sprint Retrospective, ensuring they run smoothly and achieve their goals.

2.2 Product Owner

The Product Owner is the individual responsible for maximizing the value of the product and managing the Product Backlog. The Product Owner should be actively involved in every part of the Scrum process. Key responsibilities include:

• Defining and prioritizing the Product Backlog: The Product Owner manages the list of features, bug fixes, enhancements, and technical improvements (the Product Backlog). They ensure that the items are prioritized according to business value, customer needs, and market changes.

• Clarifying requirements: The Product Owner is the point of contact for any questions or clarifications about the backlog items. They help the team understand what needs to be done and why it is valuable.

• Refining the backlog: The Product Owner regularly refines (or grooms) the Product Backlog, breaking large items into smaller ones, adding new items, and re-prioritizing them as necessary based on feedback or market shifts.

• Aligning work with business objectives: The Product Owner ensures that the work being done aligns with the broader business goals and vision for the product. They must strike a balance between technical considerations and customer satisfaction.

2.3 Development Team

The Development Team consists of professionals who work together to deliver the product increment during the Sprint. Their responsibilities include:

• Cross-functional skills: The team is typically made up of various roles (e.g., developers, testers, designers) that work together to complete the required tasks. The team should be capable of handling all aspects of the development process, from designing and coding to testing and deployment.

• Self-organization: The Development Team is self-organizing. This means that while they must collaborate and follow the Product Owner’s guidance on priorities, they are free to decide how to best approach the work in each Sprint. They may choose their own tasks and break down features into manageable chunks.

• Collaboration: The Development Team works closely with the Product Owner to understand goals and requirements, and with the Scrum Master to ensure they are following Scrum practices.

• Delivering increments: At the end of each Sprint, the Development Team must deliver a potentially shippable product increment that adds value to the product. This means the work must meet the agreed-upon Definition of Done (DoD).

3. Scrum Events

Scrum defines specific events (or meetings) that provide structure to the project. These events allow for inspection, adaptation, and synchronization.

3.1 Sprint

The Sprint is the central event in Scrum, a time-boxed iteration during which the team works to create a product increment. A Sprint typically lasts from 2 to 4 weeks, but the duration may vary depending on the team’s needs. During the Sprint:

• The Sprint Backlog is established, outlining the work to be completed.
• The team works toward achieving the Sprint Goal.

At the end of the Sprint, the team delivers a potentially releasable Increment.

3.2 Sprint Planning

Sprint Planning is held at the beginning of each Sprint to set the team’s goals for the upcoming iteration. The team works together to:

• Define what will be accomplished: The Product Owner presents the prioritized items from the Product Backlog, and the team selects which ones to work on.

• Plan how the work will be done: The team breaks down the backlog items into smaller tasks and estimates the effort required for each.

The outcome of Sprint Planning is the Sprint Backlog, which contains the work to be completed during the Sprint.

3.3 Daily Scrum (also known as the Daily Standup)

The Daily Scrum is a brief 15-minute meeting where the Development Team synchronizes its work. It occurs every day during the Sprint, ideally at the same time and place. The primary purpose is to inspect the team’s progress toward the Sprint Goal and adapt the work plan for the next 24 hours.

Each team member answers three key questions:

1. What did I accomplish yesterday?
   This helps the team understand what work has been completed and what has been achieved in the last 24 hours.

2. What will I work on today?
   This gives the team clarity on what needs to be focused on in the next 24 hours, keeping everyone aligned.

3. Are there any blockers or issues?
   This is the critical question where team members highlight any impediments or challenges they’re facing. If blockers are raised, the Scrum Master works to remove them.

• Key Points:
  • The Daily Scrum is not a status report for the Scrum Master or Product Owner, it is a self-organizing event for the Development Team.
  • It’s focused on the current day’s work, and the team uses it to stay on track.
  • If a deeper discussion is needed, it should be taken offline (after the Daily Scrum).

3.4 Sprint Review

At the end of the Sprint, the Sprint Review is held to inspect the work done and gather feedback. This event is typically longer than the Daily Scrum and involves both the Scrum Team and stakeholders. The objectives of the Sprint Review are:

• Present the Increment: The team showcases the completed work, presenting the product increment that was developed during the Sprint. The increment should be potentially shippable, meaning that it should be ready to be released, even if it’s not immediately deployed.

• Collect stakeholder feedback: During the review, stakeholders (such as customers, business representatives, or end-users) are invited to give feedback on the increment. This helps the team understand whether they are meeting the customer’s needs and whether any adjustments are necessary.

• Update the Product Backlog: Based on the feedback gathered, the Product Owner may adjust the priorities or add new items to the Product Backlog. This ensures the team is always working on the most valuable features for the business.

• Key Points:

  • The Sprint Review should be an open discussion, not a formal presentation. It’s a collaborative event for everyone to reflect on the work and adjust accordingly.
  • Stakeholders’ feedback is crucial, as it informs the team about market changes, user needs, or new insights that should influence future work.

3.5 Sprint Retrospective

The Sprint Retrospective is an event that happens after the Sprint Review and before the next Sprint Planning. The purpose of the retrospective is for the team to reflect on their process, identify improvements, and make plans for the upcoming Sprint.

During the Sprint Retrospective, the Scrum Master guides the team through a reflection process. Some key questions to explore during this event are:

• What went well in the Sprint?
  This helps the team celebrate successes and reinforce positive behaviors.

• What didn’t go well?
  This allows the team to identify challenges, blockers, or any areas where the process can be improved.

• What can we improve next Sprint?
  The team decides on action items that can be applied in the next Sprint to improve their processes, communication, or any other aspect that will help them deliver better results.

• Key Points:

  • The Sprint Retrospective is a safe space for the team to reflect honestly and openly about their work.
  • The Scrum Master facilitates the meeting, but the team leads the discussion on what to improve.
  • It’s essential to create a plan for implementing improvements and track progress over time.

4. Scrum Artifacts

Scrum uses artifacts to ensure transparency, focus, and alignment in the development process. These artifacts are key to the team's understanding of what is expected, the progress made, and the value being delivered.

4.1 Product Backlog

The Product Backlog is the foundational artifact in Scrum. It is a prioritized list of everything that needs to be done for the product. The Product Backlog is owned and maintained by the Product Owner, who ensures it is up-to-date and reflects the current needs of the business.

Key characteristics of the Product Backlog include:

• Prioritization: The backlog is ordered based on the value to the business, market changes, and customer feedback. The most important items are at the top.

• Dynamic and evolving: The Product Backlog is never complete. New work items are added, existing items are refined, and priorities change over time based on feedback and changing market conditions.

• Contains all work items: The Product Backlog includes not just features and functionality, but also bug fixes, technical debt, and any necessary improvements or maintenance.

• Granularity: Items in the backlog can range from high-level epics (large, broad requirements) to detailed user stories or tasks (smaller, more specific items).

4.2 Sprint Backlog

The Sprint Backlog is a subset of the Product Backlog. It contains the work the team has committed to delivering during the current Sprint. The Sprint Backlog is a dynamic artifact that is continuously updated throughout the Sprint.

Key characteristics of the Sprint Backlog:

• Commitment: During Sprint Planning, the Development Team selects items from the Product Backlog and commits to completing them during the Sprint. These items become the Sprint Backlog.

• Breakdown into tasks: Each Product Backlog item is broken down into smaller tasks, making it easier to track progress and ensure that the team is on track.

• Flexibility: The Sprint Backlog can evolve during the Sprint. As the team works, they may add new tasks or change their approach, but the overall Sprint Goal should remain the same.

• Visible and transparent: The Sprint Backlog is visible to the entire Scrum Team, and progress is tracked. The team can easily see if they are on track to complete the work by the end of the Sprint.

4.3 Increment

The Increment is the sum of all the work completed during a Sprint. It represents the potentially shippable product that adds value to the end-users. The Increment must meet the team’s Definition of Done (DoD), ensuring it is of high quality and can be used immediately if needed.

Key characteristics of the Increment:

• Shippable state: The Increment must be in a ready-to-release state at the end of the Sprint. It doesn’t need to be released, but it must meet the agreed-upon quality standards and be potentially deployable.

• Value-driven: Every Increment adds value to the product and helps the team move closer to the overall product vision and goals.

• Cumulative: The Increment is cumulative, meaning that each Sprint builds on previous work. At the end of the Sprint, the Increment includes all the work done so far, creating a growing product.

• Tested and validated: The Increment should be tested and validated to ensure it meets customer expectations and quality standards. This validation is critical for maintaining trust and delivering value.

Summary of Scrum Framework

The Scrum Framework is a highly structured yet flexible approach to managing complex work. By focusing on transparency, inspection, and adaptation, Scrum enables teams to remain focused, adaptable, and collaborative. Scrum is iterative, with regular events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) and clear roles (Scrum Master, Product Owner, and Development Team) that work together to create a product that adds real value.

The Scrum artifacts (Product Backlog, Sprint Backlog, and Increment) ensure that the team has a clear understanding of what needs to be done, what is being worked on, and what has been completed. The framework empowers teams to work autonomously while staying aligned with business needs and customer expectations.

Understanding and Applying the Scrum Framework (Additional Content)

1. Definition of Done (DoD) – A Core Concept in Scrum

What is the Definition of Done?

The Definition of Done (DoD) is a shared understanding within the Scrum Team of what it means for work to be complete. It is not just a checklist; it is a formal standard for product quality and delivery readiness.

Why is DoD important?

• Quality Assurance: It ensures that every Product Backlog item turned into an Increment meets the same quality criteria. This includes coding standards, testing, documentation, and integration.

• Transparency: It makes the work status visible. If something does not meet the DoD, it is not considered done.

• Consistency: Without a common DoD, different team members might have different assumptions about what “done” means.

Who defines the DoD?

• The Scrum Team defines the DoD. It can be influenced by organizational standards, but the Development Team is responsible for maintaining and applying it.

• The Product Owner does not define it alone. The Product Owner can provide input, but the DoD is a team agreement.

• Multiple Scrum Teams working on the same product should share a common DoD.

How is DoD used?

• During Sprint Planning, DoD helps the team understand what work is realistically achievable.

• During the Sprint, it serves as a reference for completing tasks.

• During the Sprint Review, it clarifies what can be presented as a “done” Increment.

Common Exam Traps:

• “Can each team have its own DoD?”
  → Only if they are working on separate products. For the same product, teams must share one.

• “Can the PO change the DoD?”
  → No. The PO can provide input, but the DoD is agreed upon by the whole Scrum Team.

2. Scrum Values – The Foundation of Scrum Behavior

What are the five Scrum Values?

1. Commitment – Everyone commits to achieving the goals of the Scrum Team.

2. Focus – The team focuses on the work of the Sprint and the goals of the Scrum Team.

3. Openness – Scrum Team members and stakeholders are open about all the work and the challenges.

4. Respect – Scrum Team members respect each other to be capable and independent.

5. Courage – The team members have the courage to do the right thing and work on tough problems.

Why are Scrum Values important?

• They guide team behavior and decision-making.

• They support transparency, which is essential for effective inspection and adaptation.

• They enhance self-organization by creating a safe environment where ideas and feedback are welcome.

Where do they apply?

• In Sprint Retrospectives, the team uses openness and respect to identify improvements.

• In Daily Scrums, the team shows commitment and focus to achieve the Sprint Goal.

• During conflicts or uncertainty, courage helps the team choose what’s best for value delivery.

Exam Relevance:

• You may be asked which values are required for transparency.
  → Answer: All of them support transparency, especially openness and respect.

• “What enables trust within the team?”
  → Scrum Values, applied consistently.

3. Scrum Event Timeboxes – Critical for Agile Discipline

Timeboxing is a key Scrum principle. Each event has a maximum duration, ensuring that meetings are focused, purposeful, and do not consume unnecessary time.

Timebox Limits for Scrum Events:

Event	Maximum Timebox (for 1-month Sprint)
Sprint	1 month
Sprint Planning	8 hours
Daily Scrum	15 minutes
Sprint Review	4 hours
Sprint Retrospective	3 hours

For shorter Sprints (e.g., 2 weeks), these timeboxes are usually proportionally shorter, but they are never extended.

Purpose of Timeboxing:

• Focus: Keeps the team aligned and prevents unproductive discussions.

• Predictability: Teams learn how to manage within fixed periods.

• Discipline: Encourages preparation and efficiency.

Exam Relevance:

• “What is the maximum length of a Sprint?” → 1 calendar month

• “How long is the Daily Scrum?” → 15 minutes, regardless of Sprint length

• “Can a Sprint Retrospective last 6 hours for a 1-month Sprint?” → No, maximum is 3 hours

Summary of the Three Key Additions:

Area	Exam Importance	Key Takeaways
Definition of Done	★★★★☆	One shared definition; governs quality
Scrum Values	★★★★☆	Foundation for trust, openness, and focus
Scrum Event Timeboxes	★★★★★	Must-know durations; frequent exam topic