Scrum is a framework for developing, delivering, and sustaining complex products. It all starts out with our stakeholders, customers, and users that have an idea about a product they need and want developed. They collaborate directly with Developers to turn this idea into reality.
Developers in Scrum are not just programmers. They are part of a self-managing and cross-functional team with all of the necessary skills to take a concept or idea and convert it into a Product. In order to ensure that all the stakeholders are on the same page and are not pulling the Developers in different directions, the Product Owner engages with the stakeholders and Developers to establish a Product Goal and get everyone aligned on the overall vision and roadmap. From this Product Goal, a Product Backlog emerges consisting of Product Backlog Items like hypotheses, features, requirements, and enhancements that help achieve the product goal. Now that we have a Product Backlog, Developers can work by pulling items off of the top of the Product Backlog and build the product iteratively and incrementally. For each Product Increment delivered, the stakeholders and users provide feedback, and based on this feedback, the Product Owner re-orders and updates the Product Backlog ensuring that the most valuable items are towards the top.
How does all this happen? Well, In Scrum, we work in Sprints. A Sprint is a fixed duration with a specific start time and end time. A Sprint cannot be longer than 30 days. Once a team decided on a Sprint length, all Sprints follow the same length so that the team works on a regular cadence. Most teams I work with today do 2-week Sprints.
The Sprint starts with Sprint Planning where the team plans out their work for this Sprint. In Sprint planning, they establish a Sprint Goal, pull the high-priority items from the top of the Product Backlog that will help accomplish the Sprint Goal, and then task out the activities that they have to do in order to build and develop these Product Backlog Items into a working Product Increment. The Sprint Goal, the Product Backlog Items, and the tasks are known as the Sprint Backlog, or the team’s plan to accomplish the work.
From this point on, the team is focused on the Sprint Backlog and collaborates together to complete these items as effectively as possible. Every day the Developers plan their day in what is called a Daily Scrum where they inspect their progress toward the Sprint Goal and adjust the Sprint Backlog accordingly.
This continues until the end of the Sprint where the Developers package up what they completed into a Product Increment. The Product Increment is the output of every Sprint. It is a quality, working, useful, and valuable increment that includes all the previously built increments in addition to what was just built in this Sprint. The Product Increment should be at a level of quality as per the team’s agreed-upon Definition of Done.
At the end of each Sprint, the team has a Sprint Review where they collaborate with the Stakeholders and users to get feedback on what they built and what to build next. “Here’s what you asked us to build, and here is what we built. Is this correct? Is this what you were expecting? Is this valuable? Are we on the right track? Here’s what we are about to work on next? Is this still the most valuable thing we can be working on? Based on the feedback, the Product Owner adjusts the Product Backlog accordingly. This ensures that for each Sprint, the team is always working on the most valuable items and are regularly delivering value to the stakeholder in an iterative and incremental fashion.
Next, the team has a Sprint Retrospective to inspect how they are working as a team and see if they can improve. The Sprint Review is about inspecting and adapting the Product, while the Sprint Retrospective is about inspecting and adapting the process of building the Product. Any action items that come out of the Sprint Retrospective get added to the next Sprint Backlog as tasks for the team to work on.
Throughout the Sprint, the team is actively doing Product Backlog Refinement where they refine, clarify, research, estimate, split, and prep the Product Backlog Items so that the items at the top of the Product Backlog are ready to be worked on. There are no breaks in between Sprints. When one Sprint ends, the next one starts, so the product backlog needs to always be prepped with actionable items for future Sprints.
Finally, we have our Scrum Master, who is the team’s leader providing servant Leader to support the Developers, the Product Owner, and the organization as a whole, ensuring that everyone is working together effectively and making forward progress toward their goals. The Developers, the Product Owner, and the Scrum Master are known as the Scrum team.
This is the Scrum Framework as defined by it’s
5 events: The Sprint, and within the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective
It’s 3 Artifacts: The Product Backlog, Sprint Backlog, and Product Increment along with the 3 commitments of the Product Goal, Sprint Goal, and Definition of Done.
And finally, it’s 3 accountabilities of Product Owner, Developers, and Scrum Master.
For more details, sign up for an upcoming foundational ScrumMaster® (CSM®) class or a Certified Product Owner® (CSPO®) class or Certified Scrum Developer® (CSD®) class.