The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and the team establishes a Sprint Goal, the team does not accept change requests that will disrupt the team from accomplishing the Sprint Goal and delivering the Product Increment. Any such changes will go into the Product Backlog to be considered for future Sprints.
The Product Increment is built iteratively and incrementally which means it includes all prior increments plus what was just built. This means the team continuously delivers products from Sprint to Sprint and regularly gets feedback ensuring the team is always working on the most valuable items. The Product Increment is a useful, valuable, and usable Product Increment and must be at a level of quality as per the Team’s Definition of Done.
The Definition of Done is the team’s auditable quality checklist. It is established as part of the team’s working agreement at the very beginning and then gets strengthened over time. The Definition of Done is not established in Sprint Planning because it does not change from Product Backlog Item to Product Backlog Item as it has more to do with how the team operates to ensure quality and less to do with the actual requirement they are building. Over time, the team improves its processes via regular retrospectives and updates its Definition of Done accordingly.
It is important to note that the team does not need to wait until the end of the Sprint to deliver the increment and can deliver multiple increments within the Sprint as long as the increment is a quality increment that meets the team’s Definition of Done.
And that’s the Product Increment, a working, useful, valuable, increment that’s delivered every Sprint, includes all previous Product Increments, and is at a level of quality as defined by the team’s Definition of Done.
In the Sprint Retrospective, the team might consider their team dynamics, relationships, processes, tools or their Definition of Done, and then come up with action items to take on to improve. There are many types of retrospectives, the most basic is referred to as pluses and deltas where the team looks at what went well and what can be improved and then takes on improvement action items accordingly. The action items from the retrospective go into the next Sprint backlog as tasks for the team to work on to become more effective. This means that in the next Sprint, the team needs to allocate some time for continuous improvement initiatives that came out of the retrospective.
The Sprint Retrospective is the last event of the Sprint and is timeboxed to 3 hours for a 4-week Sprint and 1.5 hours for a 2-week Sprint and so on.
And that’s the Sprint Retrospective. A timeboxed event that occurs at the very end of the Sprint for the Scrum team to inspect their processes and adapt to continuously improve and become a more effective team and organization.
Next check out the entire Scrum in a Nutshell series:
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 […]
In Scrum, there are 3 accountabilities, 3 artifacts, and 5 events. The 3 accountabilities in Scrum are: The 3 artifacts in Scrum are: The 5 events in Scrum are: And that’s the Scrum Framework as defined by
The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master. Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing. Developers are cross-functional to remove bottlenecks and dependencies. Developers […]
The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal. The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work […]
In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event […]
The Daily Scrum is a brief daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is […]
The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users […]
The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and […]
The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and […]
For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage. Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal. Focus: […]
Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses […]
Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products. The participants shared and learned about […]