Development Team

The Development Team is made up of the professionals who do the work of delivering the Product Increment. They self-organize to accomplish the work. Development Team members are expected to be available to the project full time.

Traditional software development approaches define various job types, such as architect, programmer, tester, database administrator, UI designer, and so on. Scrum defines the role of Development Team, which is simply a cross-functional collection of these types of people. The Development Team’s members, collectively, have the skills required to deliver the business value requested by the Product Owner. Whenever you can, you should create cross-functional teams. Parcelling the work out to different role-specific teams is suspect and is likely a serious impediment to the successful use of Scrum.

At the beginning of each Sprint, the Development Team participates in Sprint Planning. In collaboration with the Product Owner and with facilitation from the Scrum Master, the Development Team helps to establish the goal for the next sprint.

Sprint Retrospective

At the end of each Sprint, the Scrum Team meets for the Sprint Retrospective. The purpose is to review how things went with respect to the process, the relationships among people, and the tools. The team identifies what went well and not so well, and identifies potential improvements.

The Sprint Retrospective is one of the most important and least appreciated practices in the Scrum framework. It is important because it gives teams the chance to customize Scrum to their unique circumstances. It is under-appreciated because some people have a misguided view that it takes time away from doing “real” design, build, and test work.

The Sprint Retrospective is a crucial contributor to the continuous improvement that Scrum offers. Scrum teams hold Retrospectives each and every sprint, allowing teams to take advantage of insights and data before they are lost. Because a Scrum Team meets at the end of each Sprint to inspect and adapt its Scrum process, it can apply early and incremental learning throughout the development process and thereby significantly affect the outcome of the project.

Sprinting

In Scrum, work is confined to a regular, repeatable work cycle, known as a Sprint or Iteration. Scrum Sprints are fixed intervals, ranging from one week to one month with preference to shorter periods. Working within the boundaries of such an accelerated time-frame, the team would only be able to build the most essential functionality.

A Release is typically composed of multiple Sprints, each of which delivers customer or user value. Every Sprint begins with Sprint Planning, a time when the Scrum Team gathers to agree on a Sprint Goal and determine what it can deliver during the forthcoming Sprint.

Sprint Execution accounts for the majority of time during a Sprint. It begins after Sprint Planning and ends when the Sprint Review starts. On a two-week-long Sprint, Sprint Execution might account for about eight out of the ten days.

Sprint Execution is the work the Scrum Team performs to meet the Sprint Goal. During the Sprint, the Development Team self-organizes to produce a Product Increment in accord with the Sprint Backlog, as determined during Sprint Planning. Self-organizing means that the team responsibly produces the Product Increment in accord with all the organization’s standards, according to the Definition of Done, and that the Development Team determines just how to go about that.

The Scrum Master participates as the coach, facilitator, and impediment remover, doing whatever is possible to help the team be successful. The Scrum Master doesn’t assign work to the team or tell the team how to do the work. A self-organizing team figures these things out for itself.

The Product Owner must be available during sprint execution to answer clarifying questions, to review intermediate work and provide feedback to the team, to discuss adjustments to the Sprint Goal if conditions warrant, and to verify that the acceptance criteria of Product Backlog Items have been met.

Product Owner

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.

Sprint Planning

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.

What is Scrum?

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.