Roles
Scrum framework primarily defines three crucial roles: the Product Owner, the Scrum Master, and the Development Team. Each of these roles has a unique set of responsibilities, and all must work together effectively to ensure the success of Scrum. The collaboration between these roles forms the foundation of any Scrum project and helps deliver high-value products iteratively and incrementally.
Scrum Master
The Scrum Master is a servant-leader for the Scrum Team. They help everyone understand and enact Scrum principles and values. They guide, coach, and mentor the team, remove obstacles that could impede its progress, and facilitate Scrum events when necessary. Their primary role is to create a balance where the team can be most productive, maintaining the Scrum framework and protecting the team from external interruptions.
Product Owner
The Product Owner is a strategic role responsible for maximizing the product’s value resulting from the Development Team’s work. This role represents the interests of stakeholders and customers. The Product Owner manages the Product Backlog, defining and prioritizing its items, and ensures that the team works on the most valuable features or tasks. They also represent the customer’s voice, ensuring that the team understands the users’ needs and wants.
Development Team
The Product Owner is a strategic role responsible for maximizing the product’s value resulting from the Development Team’s work. This role represents the interests of stakeholders and customers. The Product Owner manages the Product Backlog, defining and prioritizing its items, and ensures that the team works on the most valuable features or tasks. They also represent the customer’s voice, ensuring that the team understands the users’ needs and wants.
Projects
Teams use projects or initiatives to implement significant changes to a product or service. They are often based on the principle of Kaikaku, a Japanese term meaning “radical reform.” This represents a substantial, transformative change to enhance business performance and competitiveness. Contrasting with the gradual, continuous improvement seen in the Kaizen principle, Kaikaku projects aim to achieve big, bold, and disruptive changes that substantially impact the organization.
Here are some key elements of Kaikaku-based projects:
- Bold vision: developing a clear, compelling vision of the organization’s goal through the initiative.
- Strategic thinking: using strategic thinking and planning to identify the most promising opportunities for radical change.
- Collaboration: Encouragement of cross-functional collaboration involving all stakeholders in the change process.
- Innovation: they embrace and promote innovative thinking and approaches to drive change.
- Risk-taking: they are willing to take calculated risks to achieve transformative change.
Epics
An epic is an important, high-level user story that outlines a significant modification or addition to the product. Due to their scale and complexity, epics are usually too large to be accomplished within a single sprint. As a result, they are broken down into smaller user stories that can be executed across one or more sprints.
Product Backlog
The Product Backlog is a comprehensive list of features, functions, requirements, enhancements, and fixes the product needs. It’s a dynamic document that evolves as the needs of users and the business change.
The Product Owner manages the Product Backlog, responsible for its content, availability, and ordering.
The items in the Product Backlog, often referred to as “Backlog Items” or “User Stories,” are usually written from the end user’s perspective. Each item should provide value to the users and the business and must be clear and concise enough for the Development Team to understand and take action.
Each Backlog Item needs to be estimated, usually in terms of effort or complexity. This helps the team plan the work for each Sprint and provides a way to measure the product’s progress over time.
The Product Backlog is never complete. As long as the product exists, something new can be added to the backlog. It’s a living document that reflects the work needed to improve the product, address user needs, and provide value to the business.
Stories
A story, or a user story, is a distinct, compact piece of functionality depicting a specific outcome or value the product should deliver to its users.
Typically, stories are formulated as follows:“As a [user], I want [functionality] so that [benefit].”
They capture the product’s requirements and guide the development team in their tasks.
User stories outline the functionality a product or feature should provide from the end user’s viewpoint. When creating a user story, it is beneficial to follow the INVEST criteria:
- I(Independent): Each user story should be self-sufficient, meaning it should not rely on other user stories to be complete.
- N(Negotiable): User stories should be open to discussion and refinement, allowing flexibility and adaptability.
- V(Valuable): Every user story should offer value to the end user, contributing positively to their experience.
- E(Estimable): A user story should be possible to estimate in terms of effort and complexity, aiding in efficient planning and task allocation.
- S(Small): User stories should be compact enough to be completed within a single sprint, promoting focus and momentum.
- T(Testable): Each user story should be verifiable through manual or automated testing, ensuring its functionality and reliability.
Sprints
A sprint is a defined period, typically two weeks, during which teams work diligently to complete a selected set of stories and deliver a potentially releasable product increment or tangible value to the business. Sprints are a fundamental component of Scrum, providing a consistent cadence of work and delivery while enabling the team to adapt to changing requirements and feedback from stakeholders.
Ceremonies
Each Sprint is punctuated by a series of key ceremonies. These ceremonies provide structure and rhythm to the team’s work, guide collaboration, and foster transparency, inspection, and adaptation, which are essential Scrum values.
Daily Scrum
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team, aiming to inspect progress towards the Sprint Goal and adapt the Sprint Backlog as necessary.
- What they have accomplished since the last meeting
- What they plan to accomplish before the next meeting
- Any obstacles they are facing
It’s recommended that each team member shares their screen to show their tasks and comment on their progress, promoting active participation in the meeting. Without the Scrum Master or Product Owner, the Daily Scrum should still occur, as the Scrum Team is self-managing. In-depth discussion or backlog refinement should be done separately to keep this meeting short and focused.
Planning
Sprint Planning sets the stage for the Sprint, outlining the work for the coming period. This plan is developed collaboratively by the entire Scrum Team. The Product Owner ensures attendees are ready to discuss the most crucial Product Backlog items and how they align with the Product Goal. The Scrum Team may also invite others to provide input.
For each chosen Product Backlog item, the Development Team plans the necessary work to create an increment that meets the Definition of Done. Often, this involves breaking down Product Backlog items into smaller tasks that can be completed within one day or less. How this breakdown is accomplished is solely at the discretion of the Developers. The Sprint Goal, the Product Backlog items selected for the Sprint, and the delivery plan make up the Sprint Backlog. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, with shorter sprints having proportionally shorter meetings. For instance, Sprint Planning lasts about one hour in a two-week Sprint.
Backlog Refinement
Backlog Refinement, or backlog grooming, is reviewing and maintaining the product or project backlog. This regular, ongoing activity involves the team reviewing tasks and user stories in the backlog, clarifying details, estimating the required effort, and prioritizing their execution based on their importance and relevance to the project.
Backlog Refinement ensures that the backlog remains up-to-date, relevant, and appropriately structured, helping the team focus on high-value tasks and align their work with the product goals.
In this meeting, the Product Owner, the Scrum Master, and the Development Team collaborate to ensure that the product backlog items are clearly defined, appropriately prioritized, and ready for development in upcoming sprints.
By regularly refining their backlog, teams can improve their efficiency and effectiveness, ensuring they are constantly working on the most valuable items and ready to respond to changes in their business environment. Backlog refinement is an ongoing process and does not have a strict time box. However, teams should spend 10% of their time on backlog refinement activities.
Review
The Sprint Review is a time to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team showcases the results of their work to key stakeholders, and the progress towards the Product Goal is discussed.
During the Sprint Review, the Scrum Team and stakeholders review what was achieved during the Sprint and what has changed in their surroundings. Based on this information, the group collaborates on the next steps, possibly adjusting the Product Backlog to respond to new opportunities.
The Sprint Review is a working meeting, not merely a presentation.
For a one-month Sprint, the Sprint Review is timeboxed to a maximum of four hours. For shorter sprints, the event is typically shorter. For instance, Sprint Review lasts approximately 60 minutes for each two-week Sprint.
Retrospective
The Sprint Retrospective occurs at the end of each Sprint, providing a time for the team to reflect on what transpired, both positive and negative, during the last Sprint. It also allows the team to evaluate their routines and processes to optimize how they work together.
The Sprint Retrospective occurs at the end of each Sprint, providing a time for the team to reflect on what transpired, both positive and negative, during the last Sprint. It also allows the team to evaluate their routines and processes to optimize how they work together.
