Near the end of the Sprint, the team conducts two important inspect-and-adapt activities: the Sprint Review and the Sprint Retrospective. The Sprint Review focuses on the product itself. The Sprint Retrospective, on the other hand, looks at the process the team is using to build the product.
During Sprint Planning we plan the work. During Sprint Execution we do the work. During Sprint Review we inspect (and adapt) the result of the work – the Potentially
Shippable Product Increment. The Sprint Review occurs near the end of each Sprint cycle, just after Sprint Execution and just before – or occasionally after – the Sprint Retrospective.
The Sprint Review gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The Sprint Review provides a transparent look at the current state of the product, including any inconvenient truths. It is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities.
Demonstrates what was achieved in the Sprint and collect feedback
Whole team participates
Invite anyone and everyone
Read More »
The Product Owner is the empowered central point of product leadership. It is one of the three collaborating roles that constitute every Scrum Team (the others being the Scrum Master and the Development Team).
The Product Owner needs to look in at least two directions simultaneously. On one hand, the Product Owner must understand the needs and priorities of the organizational stakeholders, the customers, and the users well enough to act as their voice. In this respect the Product Owner acts as a product manager, ensuring that the right solution is developed. On the other hand, the product owner must communicate to the Development Team what to build and the order in which to build it. The product owner must also ensure that the criteria for accepting features are specified and the tests that verify those criteria are later run to determine whether the features are complete. The product owner doesn’t write detail-level tests but ensures that the high-level ones are written so that the team can determine when the product owner will consider the feature complete. In these respects the product owner is part business analyst and part tester.
Read More »
The Scrum Master is one of the three roles that constitute every Scrum Team (the others being the Product Owner and the Development Team). While the Product Owner is focused on building the right product and the Development Team is focused on building the product right, the Scrum Master is focused on helping everyone understand and embrace the Scrum Values, principles, and practices. The Scrum Master acts as a coach to both the Development Team and the Product Owner. A Scrum Master also provides process leadership, helping the Scrum Team and the rest of the organization develop their own high-performance, organization-specific Scrum approach.
The Scrum Master is a servant leader, helping the rest of the Scrum Team follow their process. The Scrum Master must have a good understanding of the Scrum framework and the ability to train others in its subtleties.
The Scrum Master works with the Product Owner to help the Product Owner understand how to create and maintain the Product Backlog. He works with the Development Team to find and implement the technical practices that will allow them to get the job done at the end of each Sprint. He works with the whole Scrum Team to evolve the Definition of Done. The Scrum Master continuously helps the Scrum Team improve the process, whenever possible, to maximize delivered business value.
Read More »
Each Sprint begins with a time boxed meeting called Sprint Planning. In this meeting the Scrum Team collaborates to select and understand the work to be done in the upcoming Sprint.
The entire team attends the Sprint Planning meeting. Working from the ordered Product Backlog, The Product Owner and the Development Team members discuss each item and come to a shared understanding of that item and what is required to complete it consistent with the current Definition of Done.
In Scrum, the Sprint Planning meeting is described as having two parts.
Choose Goal: the Team and the Product Owner collaborate to decide how much of the prioritized backlog can be turned into potentially shippable functionality.
Create Sprint Backlog: the Team defines the tasks required to build that functionality during the next Sprint, including estimates to achieve the Definition of Done.
Read More »
Product Backlog is a prioritized list of desired product functionality.
The Product Backlog provides a centralized and shared understanding of what to build and the order in which to build it. It is a highly visible artifact at the heart of the Scrum framework that is accessible to all project participants. It is the single source from which all requirements flow. This means that all the work the Development Team does comes from the Product Backlog.
Read More »
Scrum is an Agile framework for developing innovative products and services, for organizing and managing work. Scrum begins when some stakeholders need a product. The Scrum framework is based on a set of values, principles, and practices that provide the foundation to which your organization will add its unique implementation of relevant engineering practices and your specific approaches for realizing the Scrum practices. The result will be a version of Scrum that is uniquely yours. Scrum is a refreshingly simple, people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment, and collaboration. The Scrum practices themselves are embodied in specific roles, activities, artifacts, and their associated rules. Read More »