Scrum is about Teams producing complex Results in an agile way. Scrum Teams achieve results by using a simple framework and set of rules. We will describe scrum to set the stage for an applied approach to scrum.
The Team
The fundamental element of scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of Team Members who provide useful Results/Products for Stakeholders.
Arguably, the most important role involved in scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the team to form.
While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the sole Team Member held accountable for the product the Team builds. The Product Owner must find a result that will satisfy the Stakeholders needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done. The Product Owner connects the team with the purpose.
The Scrum Team Members are the people that actually do the work that satisfies the goals and priorities the Product Owner has set for them. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve itself. The Team works on the priorities the Product Owner has set, and the Team commits to the amount of work it can do without undue influence from the Product Owner.
In order to aid the Team in doing its work, there is a role on the Team called the Scrum Master (SM). The SM's responsibilities are to be a facilitator, moderator and coach, with particular emphases on helping the Team mature its self-organization and self-management. The Scrum Master manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team – often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the team and outside the team. The Scrum Master understands the scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to.
The Backlog
A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs", "Backlog Items”, or simply "Items"). When the list is small it is just a simple list of things, as it grows we add grouping mechanisms to organize it and help us keep track. The list of work items can evolve from a simple "cut the grass" to demanding "build a 20 story interactive office building". The key is that the list of work items evolves and becomes no more complicated than is necessary.
These Items represent the Stakeholder's needs and wants – each of them is a request for something of value to be provided by the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that backlog and the Team is responsible for committing to as many Items they can do in a Sprint – thus creating the Sprint Backlog. From the Team’s view, the Product Backlog is work that we might do some day and the Sprint Backlog is work we are committed to doing.
The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: ready does not imply excessive detail but, instead refers to enough detail. The team working with the PO will determine what “enough detail” is. The key here is an unfolding dialog.
When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify backlog items. This process is called Backlog Grooming, and is a continuous process throughout the Project.
Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.
