Skip to main content

Understanding Epics, Sprint Refinement, and Scrum Ceremonies

Definition, scope , responsibilty and process​

Epic​

An epic is a large body of work that can be broken down into smaller user stories or tasks. It represents a significant feature, project, or initiative that usually spans multiple sprints. Epic creation involves defining the overarching goal or feature and identifying its scope, value, and key components. The epic is later refined into smaller, actionable user stories during refinement sessions or Poker Planning.

Scope:​

  • High-Level Overview: The epic captures a broader objective or feature that delivers substantial value to the business or users. It usually encompasses multiple related user stories.
  • Decomposition into Stories: While the epic outlines the larger goal, it must be broken down into smaller, actionable user stories during the refinement process. The epic provides the overarching direction, while the stories specify detailed tasks.
  • Goal-Oriented: The epic aligns with the product roadmap and overall business goals, ensuring that it contributes to strategic priorities.
  • MVP Definition: For large epics, part of the epic creation process is determining what the Minimum Viable Product (MVP) looks like, focusing on delivering the most critical features early.

Responsibilities:​

  • Product Owner:
    • Defining the Epic: The product owner is responsible for creating the epic by outlining the high-level goals, scope, and objectives. They define what the epic aims to achieve, ensuring it aligns with business needs and value.
    • Clarifying Requirements: They provide a clear description of the epic’s purpose, the problem it solves, and its expected outcome.
    • Prioritization: The product owner is responsible for prioritizing epics within the backlog, ensuring the most critical features are developed first.
    • MVP Identification: If the epic is large, the product owner works to define the MVP, highlighting the essential components to deliver in early iterations.
  • Development Team:
    • Refining the Epic: The development team provides input on how to break down the epic into smaller user stories or tasks. They help ensure that each part of the epic is actionable and technically feasible.
    • Estimation: During Poker Planning or refinement sessions, the development team helps estimate the complexity and effort required for stories related to the epic.
    • Feedback and Discussion: The development team collaborates with the product owner to refine the epic further, providing technical feedback and suggesting ways to approach the work.
  • Scrum Master (Optional):
    • Facilitating Refinement: The Scrum Master may facilitate the epic refinement process, ensuring the development team and product owner collaborate effectively and that the epic is broken down in a way that supports sprint planning.

Process:​

  1. Epic Definition by Product Owner:
    • The product owner creates an epic by outlining the high-level goal, specifying its business value, and defining the scope of the work. They also identify key features and functionality that the epic should include.
    • The epic’s description should clearly state the problem to be solved, the desired outcome, and any key acceptance criteria.
  2. Initial Discussion with the Development Team:
    • Once the epic is defined, the product owner presents it to the development team to provide an overview of the goals and requirements.
    • The development team may raise questions, provide technical insights, or offer suggestions to refine the epic further.
  3. Breaking Down the Epic:
    • The epic is broken down into smaller user stories or tasks during refinement sessions or Poker Planning. These stories represent specific, actionable work that can be completed within a single sprint.
    • The team identifies the stories necessary to deliver the MVP, focusing on the most critical aspects of the epic first.
  4. MVP Definition:
    • For larger epics, the team and product owner work together to define the MVP — the minimal set of features required to deliver value. This ensures that the team can deliver a usable product even if they are unable to complete the entire epic at once.
  5. Prioritization and Estimation:
    • The product owner prioritizes the epic based on business needs, and the team may begin estimating the stories related to the epic during Poker Planning or refinement.
  6. Tracking and Progress:
    • The epic is tracked in the product backlog, with its progress measured as user stories are completed across multiple sprints. The team can regularly update and refine the epic based on new learnings or changes in requirements.

Sprint Refinement​

Sprint refinement, often referred to as backlog refinement, is the process of reviewing and refining the items in the sprint backlog. The aim is to ensure that the work planned for the upcoming sprint is clearly understood, well-defined, and actionable. It typically occurs throughout the sprint in preparation for the upcoming sprint planning session.

Scope:​

  • Clarifying User Stories: The team discusses the stories in the backlog to ensure that they are well understood. Requirements are clarified, and acceptance criteria are confirmed.
  • Adding Details: If any user stories lack detail, more information is added to ensure they are ready to be worked on in the next sprint.
  • Estimating Stories: The team estimates the effort required for each user story, usually using techniques like story points or t-shirt sizing.
  • Adjusting Priorities: The product owner might reprioritize items in the backlog based on new business priorities or feedback.
  • Splitting Large Stories: Any user stories that are too large to complete within a single sprint may be split into smaller, more manageable stories.
  • Removing or Reordering Stories: The team may identify stories that no longer need to be worked on or can be deprioritized.

Responsibilities:​

  • Product Owner: Ensures the backlog items reflect the product goals and are prioritized based on business value and dependencies.
  • Development Team: Engages in the discussion by reviewing user stories, asking questions, providing estimates, and identifying potential blockers.
  • Scrum Master: Facilitates the meeting, ensures the backlog refinement process is smooth, and helps resolve any impediments to clear understanding of the work.
  • Stakeholders: In some cases, stakeholders may be involved to provide further clarification or insights on certain backlog items.

Poker Planning​

Poker Planning is a consensus-driven estimation process where the development team estimates the effort and complexity of user stories or tasks using Planning Poker cards/Story Points. It also involves creating or refining user stories and defining the MVP (Minimum Viable Product) for epics or larger features. The development team leads these sessions, ensuring that both clarity on the stories and creation of meaningful, actionable tasks are achieved.

Scope:​

  • Effort Estimation: Estimate the complexity and effort required for user stories, epics, or tasks using story points or other estimation techniques.
  • Story Clarification: Ensure that every story is well-understood by the development team, with a clear definition of requirements and acceptance criteria.
  • Story/MVP Creation: Collaboratively create new user stories or break down large features into smaller, manageable stories. This includes defining the MVP for larger epics, ensuring the team focuses on delivering the most valuable features early.
  • Team Consensus: The team reaches a consensus on story points, as well as on the scope of each user story and MVP definition.
  • Continuous Refinement: Regular refinement and updating of the product backlog based on new insights gained during Poker Planning.

Responsibilities:​

  • Development Team (Leads the process):
    • Story and MVP Creation: Lead the creation of user stories and define the MVP for larger tasks. Break down large epics into smaller, actionable stories.
    • Effort Estimation: Provide individual estimates using Planning Poker cards/Story Points. Engage in discussions to align on final estimates.
    • Clarify Stories: Ask questions and clarify any uncertainties to ensure full understanding before estimating or defining the MVP.
    • Challenge and Refine Requirements: Collaboratively review and refine story requirements, breaking down large or ambiguous stories to ensure they are ready for development.
  • Scrum Master (Optional):
    • Facilitating the Session: Ensure the Poker Planning session runs smoothly and stays focused. Help keep discussions on track and encourage participation.
    • Removing Blockers: Identify and help remove any impediments preventing the team from gaining clarity or reaching a consensus.

Process:​

  1. Story Presentation & MVP Discussion:
    • The development team presents high-level stories or epics. For larger features, they collaboratively define the MVP — the minimal set of features that must be developed to create a functional, value-generating product.
  2. Clarification and Story Creation:
    • The team reviews epics and breaks them down into smaller, more manageable user stories. They ensure that all the stories are well-defined, asking questions and discussing unclear requirements with the product owner.
    • The team may create new stories on the spot to refine the backlog and better define the MVP.
  3. Estimation:
    • Once the stories are well-understood, each team member selects an estimate using Planning Poker cards/Story Points. T
    • If discrepancies occur, the team discusses the reasons behind higher or lower estimates.
  4. Final Estimate and Story Agreement:
    • The team agrees on the final estimate and story breakdown. They also finalize the MVP if they are working on larger features.
  5. Move to Backlog:
    • The refined and estimated stories, along with the MVP, are updated in the product backlog, ready for future sprint planning sessions.

Sprint Planning​

Sprint Planning is a Scrum ceremony that occurs at the beginning of each sprint. During this meeting, the Scrum team (development team, product owner, and sometimes the Scrum master) collaborates to define the work that will be accomplished during the sprint. The goal is to create a sprint backlog, which includes a list of prioritized user stories or tasks that the team commits to completing during the sprint.

Scope:​

  • Setting Sprint Goals: The product owner outlines the objectives for the sprint, specifying what they want the team to deliver. These goals are derived from the overall product roadmap and prioritize the highest value features.
  • Selecting Work: The development team reviews and selects user stories from the product backlog that they believe they can complete within the sprint. The product owner ensures these stories align with business priorities.
  • Task Breakdown: The development team breaks down user stories into tasks that can be completed within the sprint timeframe, usually in a few hours or days.
  • Capacity Planning: The team estimates their capacity (how much work they can accomplish), considering factors like holidays, team availability, and past performance.

Responsibilities:​

  • Product Owner:
    • Presenting Prioritized Work: The product owner ensures that the most critical, prioritized user stories are ready for the sprint. They clarify the business goals and the importance of each story.
    • Clarifying Requirements: The product owner answers questions and provides additional detail or clarification about the stories. They help refine stories as needed, ensuring they are clear, with well-defined acceptance criteria.
    • Setting Sprint Goals: The product owner defines the goal of the sprint by outlining the desired outcome and how the stories selected for the sprint contribute to it.
  • Development Team:
    • Work Estimation: The development team estimates the effort and complexity of the user stories or tasks to be included in the sprint. They use historical data, Planning Poker, or other techniques to ensure accuracy.
    • Capacity Check: The team assesses its capacity based on the sprint duration, team members' availability, and workload from previous sprints.
    • Commitment: The team selects the stories they believe they can commit to completing by the end of the sprint, ensuring that the workload is realistic.
    • Task Breakdown: Once stories are selected, the development team breaks them into smaller, manageable tasks that can be completed within the sprint.
  • Scrum Master (Facilitator):
    • Facilitating the Meeting: The Scrum master helps guide the meeting, ensuring that discussions are productive and focused. They ensure that everyone stays on track, and the planning meeting is completed within the timebox (usually 2 hours for a 2-week sprint).
    • Helping with Estimation and Capacity: The Scrum master ensures that the team has considered capacity and doesn’t over-commit to more work than they can handle.

Process:​

  1. Setting the Sprint Goal:
    • The product owner outlines the high-level goal for the sprint. This is the overall objective that the team aims to achieve. The goal provides direction and ensures that everyone is aligned on what will be delivered.
  2. Reviewing and Selecting Stories:
    • The product owner presents the highest priority user stories from the backlog. The development team discusses these stories to clarify requirements, confirm understanding, and assess whether the stories are ready to be worked on (i.e., they meet the Definition of Ready).
  3. Estimating Work:
    • The development team estimates the effort required to complete the stories. If necessary, they break large stories into smaller tasks to make them more manageable and provide more accurate estimates.
    • They also consider their capacity and ensure that the amount of work selected for the sprint is realistic.
  4. Breaking Down Tasks:
    • The team breaks down each story into smaller tasks that can be completed in hours or days. This ensures that the work is well-structured, and team members can easily track progress during the sprint.
  5. Finalizing the Sprint Backlog:
    • The sprint backlog, which consists of all the tasks and stories the team has committed to, is finalized. This backlog is the team’s plan for the sprint.
  6. Confirming Commitment:
    • Before closing the meeting, the team agrees on the sprint goal and commits to completing the stories within the sprint timeframe.

Responsibilities During Sprint Planning:​

  1. Product Owner’s Role:
    • Sprint Goal Definition: Set the clear sprint goal based on business needs.
    • Clarification: Be available to answer any questions related to the user stories, clarify acceptance criteria, and provide the business context for each story.
    • Story Refinement: Refine or split stories if needed based on feedback from the development team.
  2. Development Team’s Role:
    • Story Selection: Select the appropriate stories to work on based on capacity and priority.
    • Estimation: Estimate the effort required for each story.
    • Task Breakdown: Break user stories into smaller tasks and finalize the sprint backlog.
    • Commitment: Commit to completing the selected stories by the end of the sprint.
  3. Scrum Master’s Role:
    • Facilitation: Keep the meeting organized, time-boxed, and focused. Ensure that every team member participates and that discussions remain productive.
    • Capacity Management: Help the team understand its capacity and prevent over-committing.
    • Removing Blockers: Identify potential impediments early and plan to address them.

Daily Standup (Daily Scrum)​

The Daily Standup is a short, time-boxed meeting held every day of the sprint. Its purpose is to synchronize the team’s progress, identify any obstacles, and ensure alignment toward achieving the sprint goal. It usually lasts for 15-30 minutes and allows team members to quickly communicate what they’re working on and any challenges they face.

Scope:​

  • Progress Synchronization: Each team member provides an update on what they accomplished the previous day, what they are working on today, and any impediments.
  • Transparency and Accountability: The meeting fosters transparency, ensuring that everyone knows the progress of the team and their peers. It also helps maintain accountability as everyone shares their status.
  • Impediment Identification: Any blockers or impediments to progress are quickly surfaced, allowing the Scrum master to assist in removing them.
  • Focus on the Sprint Goal: The standup ensures that the team is continually focused on achieving the sprint goal by aligning daily tasks with the overall sprint plan.

Responsibilities:​

  • Development Team:
    • Sharing Updates: Each team member shares what they worked on the previous day, what they plan to work on today, and any blockers that could prevent them from progressing.
    • Highlighting Blockers: If a team member faces any impediments or dependencies that are delaying their work, they raise it during the standup to get help from the Scrum master or other team members.
    • Aligning on Sprint Goal: The development team aligns their daily tasks with the sprint goal to ensure that the team is collectively moving towards the agreed objectives.
  • Scrum Master:
    • Facilitating the Meeting: The Scrum master ensures the meeting stays focused and time-boxed to 15 minutes. They may intervene if the discussion deviates from the purpose or becomes too detailed.
    • Removing Blockers: After blockers are raised by team members, the Scrum master takes action to remove those impediments or escalate them if needed. They help ensure the team can focus on delivering value without unnecessary delays.
  • Product Owner (Optional):
    • Attending for Context: The product owner may attend the standup to stay informed about the team’s progress and understand if there are any blockers affecting the completion of high-priority stories.
    • Providing Clarifications: If the team has any immediate questions about user stories or requirements, the product owner can provide clarifications during or after the meeting.

Process:​

  1. Each Team Member’s Update:
    • Each team member answers the following three questions:
      1. What did I do yesterday?
      2. What will I do today?
      3. What obstacles are in my way?
    • The updates are short and focused on tasks that contribute to the sprint goal.
  2. Addressing Blockers:
    • If a team member mentions a blocker, the Scrum master takes note and works to resolve it after the standup. The standup itself is not the place for in-depth problem-solving, but it’s an opportunity to surface issues.
  3. Stay Time-Boxed:
    • The meeting is strictly time-boxed to 15-30 minutes. Any discussions or detailed problem-solving should be taken offline after the standup.
  4. Focus on the Sprint Goal:
    • The team remains aligned on the sprint goal. The Scrum master or product owner may intervene if they notice that the team is drifting from the goal, ensuring that work remains focused on delivering value.

Sprint Review​

Sprint Review is a Scrum ceremony held at the end of each sprint to inspect the work completed during the sprint and gather feedback from stakeholders. It serves as a collaborative platform for the Scrum team to demonstrate the product increment, showcasing new features, updates, or changes made. The meeting fosters transparency and alignment, ensuring that the product is on track to meet business goals.

Scope:​

  • Reviewing Completed Work: The team demonstrates the work completed during the sprint, focusing on features or product increments that meet the Definition of Done.
  • Gathering Feedback: The primary goal is to collect input from stakeholders to ensure that the work aligns with business needs and to inform adjustments to the product roadmap.
  • Inspecting and Adapting: The sprint review allows the team and stakeholders to assess progress toward long-term goals and discuss any changes in business conditions or user needs that may impact the product backlog.
  • Updating the Product Backlog: Based on the feedback received, the product owner updates the product backlog with new priorities, additional features, or changes for future sprints.
  • Optional Demo: The meeting may include optional demos of features that are in progress or being considered for future development, providing stakeholders with a broader context of the product's evolution.
  • Closure of the Sprint: The review concludes the sprint, allowing the team to reflect on what went well and what could be improved, ensuring a smooth transition to the next sprint.

Responsibilities:​

  • Development Team:
    • Demonstrating Work: The development team demonstrates the completed user stories or product features to the stakeholders, showcasing what has been built and how it meets the sprint goal.
    • Gathering Feedback: They actively listen to feedback from stakeholders and are open to questions and suggestions about the work they’ve done.
    • Discussing Incomplete Work: If any stories or tasks were not completed, the development team explains the reasons behind this, providing insights into challenges encountered, technical issues, or shifting priorities.
  • Product Owner:
    • Leading the Review: The product owner typically leads the review, presenting the overall sprint progress, explaining the value delivered, and framing the discussion around the product roadmap and business goals.
    • Presenting Business Context: The product owner provides context for why certain features or stories were prioritized and how they align with business objectives.
    • Updating Backlog: Based on feedback from stakeholders and the development team, the product owner updates and reprioritizes the product backlog to ensure that it remains aligned with business needs.
  • Scrum Master:
    • Facilitating the Meeting: The Scrum master ensures that the sprint review runs smoothly and remains productive, keeping the meeting focused on reviewing the work and gathering feedback.
    • Ensuring Stakeholder Engagement: The Scrum master helps ensure that stakeholders are engaged in the review and that their feedback is documented and taken into consideration.
  • Stakeholders:
    • Providing Feedback: Stakeholders, including customers, users, or business representatives, provide feedback on the delivered product increment. They evaluate how well the work aligns with their expectations and whether the features address their needs.
    • Offering Insights: Stakeholders offer insights about changes in the business environment, user requirements that could influence future development.

Process:​

  1. Review of Sprint Goal:
    • The product owner or Scrum master begins by reviewing the sprint goal and summarizing the work that the team committed to completing during the sprint.
  2. Demonstrating Completed Work:
    • The development team demonstrates the working features, focusing on the product increment that has been built. They walk through the functionality, explain how it meets user stories, and show the value it delivers to stakeholders.
  3. Gathering Feedback:
    • Stakeholders provide feedback on the features and overall product increment. They ask questions, suggest improvements, and discuss how the product aligns with the evolving business needs.
  4. Discussion of Incomplete Work:
    • The development team discusses any stories or tasks that were not completed during the sprint. They explain the reasons for incompletion, whether due to technical challenges, shifting priorities, or resource constraints, and document these insights for future reference.
  5. Optional Demo:
    • If applicable, the team may provide optional demonstrations of features that are still in progress or concepts being considered for future sprints, giving stakeholders a sense of upcoming work.
  6. Product Backlog Discussion:
    • Based on feedback, the product owner revisits the product backlog and discusses upcoming priorities with the stakeholders. They discuss any changes that should be made to the product roadmap, including potential new features, refinements, or re-prioritization.
  7. Wrap-Up and Sprint Closure:
    • The meeting concludes with a summary of feedback, insights on incomplete work, and any updates to the backlog or sprint priorities. The Scrum master or product owner ensures that all feedback is documented, and the team is clear on what needs to be adjusted moving forward.
    • The sprint review marks the official closure of the sprint, allowing the team to reflect on successes and areas for improvement as they transition into the next sprint.

Sprint Retrospective​

Sprint Retrospective is a vital Scrum ceremony held at the end of each sprint, following the Sprint Review. Its primary purpose is to reflect on the sprint, discussing what went well, what didn’t, and how the team can improve its processes and performance in future sprints. The retrospective fosters a culture of continuous improvement and collaboration, enabling the Scrum team to identify actionable steps for enhancing teamwork, efficiency, and overall product quality.

Scope:​

  • Reflection on the Sprint: The team reviews the entire sprint experience, discussing achievements, challenges, and any issues that arose.
  • Identifying Improvements: The primary goal is to pinpoint specific improvements to processes, collaboration, and communication that can enhance the team's performance in future sprints.
  • Team Engagement: The retrospective provides a safe space for all team members to express their thoughts, ensuring that everyone’s voice is heard.
  • Action Items Creation: The team collaborates to create actionable items or experiments that will be implemented in the next sprint to address the issues identified during the discussion.
  • Recognition: Acknowledging team members or colleagues outside of the team who have contributed to the sprint's success is essential. Celebrating these contributions fosters morale and reinforces a collaborative culture.

Responsibilities:​

  • Development Team:
    • Sharing Experiences: Team members share their perspectives on the sprint, discussing what they felt went well and what could have been improved.
    • Identifying Challenges: The development team discusses any roadblocks, miscommunications, or technical challenges they encountered during the sprint.
    • Creating Action Items: Based on the discussions, the team collaborates to define concrete action items or changes they want to implement in the next sprint.
    • Recognition of Contributions: The team highlights and appreciates individuals or teams that provided support or valuable input throughout the sprint, acknowledging their impact on the project.
  • Scrum Master:
    • Facilitating the Retrospective: The Scrum master facilitates the retrospective, ensuring it stays focused, productive, and respectful. They help create an open environment where all team members feel comfortable sharing their thoughts.
    • Guiding the Discussion: The Scrum master uses various techniques and formats to guide the discussion, helping the team explore different aspects of their performance and processes.
    • Tracking Action Items: The Scrum master ensures that any identified action items are documented and followed up in future sprints.
    • Encouraging Recognition: The Scrum master encourages team members to recognize each other's contributions and those from outside the team, fostering a spirit of collaboration and appreciation.
  • Product Owner:
    • Participating Actively: While the product owner primarily focuses on the product backlog and stakeholder engagement, they should also participate in the retrospective, providing insights related to product direction and how team dynamics impact delivery.
    • Aligning Goals: The product owner can align feedback from the retrospective with broader product goals, ensuring that improvements align with business objectives.

Process:​

  1. Set the Stage:
    • The Scrum master welcomes the team and sets a positive tone for the retrospective. They remind everyone of the purpose of the meeting and establish ground rules for open and respectful communication.
  2. Gather Data:
    • The team discusses the events of the sprint, sharing both positive experiences and challenges. This may include using techniques like “Start, Stop, Continue,” where team members identify practices to start, stop, and continue.
    • The Scrum master may facilitate the gathering of data through various methods, such as anonymous surveys, sticky notes, or digital collaboration tools, to capture team feedback.
  3. Generate Insights:
    • The team reviews the collected data to identify patterns, root causes of issues, and areas for improvement. This is a collaborative discussion that allows team members to share insights and agree on key findings.
  4. Decide What to Do:
    • Based on the insights generated, the team identifies specific action items or experiments to implement in the next sprint. These should be clear, measurable, and manageable, ensuring that the team can realistically accomplish them within the next iteration.
  5. Recognize Contributions:
    • The team takes time to acknowledge and celebrate the contributions of team members and any external colleagues who supported them during the sprint. This could be through verbal recognition, shout-outs, or even small tokens of appreciation, reinforcing the importance of collaboration.
  6. Wrap-Up:
    • The retrospective concludes with a summary of the action items and insights gained. The Scrum master ensures that all decisions and commitments are documented.
    • The team may also take a moment to reflect on the retrospective itself, discussing what worked well in the meeting and how it could be improved for next time.
  7. Follow-Up:
    • The Scrum master tracks the progress of action items throughout the next sprint, ensuring that the team addresses the identified improvements and evaluates their effectiveness in subsequent retrospectives.

Example CMD1-5999 -Getting issue details... STATUS​

Was this page helpful?