This chapter is from the book
This chapter is from the book
This chapter is from the book
11.2 Agile and Scrum in a Nutshell
Scrum is a framework for managing Agile software development projects. A Scrum project starts with a definition of the items that the system should include and address, including functionality, features, and technology. These items are often called requests. The list of requests is called the product backlog (or project backlog). The requests can be of various types: textual requirements, use cases, test cases, stories, defects, enhancement requests, and so on. The requests are likely captured in an external tool such as Rational Requirements Composer (RRC) and are referenced or linked from the change management tool.
Requests can be submitted by any team member, affected users, or stakeholders. The request content is elicited from various sources, but the requests are prioritized by the product owner only and not by the development team. The product backlog is dynamic; it changes and evolves as the project advances.
During the first phase of the project, often called warm-up, the requirements are analyzed by SMEs to determined feasibility, cost, effort, and risk. This phase is done with the close participation of the stakeholders. The analysis gives the stakeholders a better basis for setting their priorities.
Agile projects are divided into iterations; the iteration has a fixed duration of a few weeks, usually two to four. In Scrum the iteration is called a sprint.
The Scrum team's responsibility is to take the requirements from the backlog and develop a usable product or component that has real value to the project, within the sprint period. The team is cross-functional and performs all activities related to the delivery. The team as a whole is responsible for delivering the requirements.
The sprint starts with a team planning meeting. Each team takes one or more top-priority requests from the product backlog, as many as they think they can develop and deliver during the sprint. A sprint must finish with delivery of a new, executable product; thus each sprint consists of all lifecycle disciplines: design, development, testing, and so forth.
The team creates a list of activities (or tasks) from the requirement(s) they have selected. This is called the sprint backlog. The activities represent the way the team decides to implement the requirements. Each activity is assigned to a team member (or sometimes to team pairs).
Each Scrum team is autonomous; the team decides how to develop work products from a requirement. Teams are organized in a way that they could be autonomous, thus having expertise in various domains. The team decides which of the Agile development methods to use—XP, pair programming, test-driven development, or another method. They decide how much modeling to do. However, the team must adhere to regulations, standards, and rules that the organization has set.
An important role within the Scrum process is the Scrum Master. This role facilitates and guides the teams in adopting the agreed-upon practices and removes impediments. The Scrum Master is not part of the team and does not give orders to the team.
Every day the team gathers for a short (15-minute) stand-up meeting called a Daily Scrum Meeting. The purpose of the meeting is to share status and identify potential issues. During the Daily Scrum Meeting the team progress is reviewed and impediments are identified for removal by management. The Scrum Master facilitates the daily meetings, tracks progress, and works to resolve any inhibitors raised by team members.
Each Scrum member briefly reports on three items:
- What was accomplished since the previous meeting?
- What is planned to be accomplished before the next meeting?
- What prevents the member from accomplishing the activities?
The report should focus on information that helps other team members gain knowledge, learn a lesson, or contribute from their experience. Important practices in the meeting are honesty and transparency.
At the end of the sprint, the team is gathered for a Sprint Review Meeting with the stakeholders. The team reviews the work that was completed and that was not completed. The products developed are demonstrated to the stakeholders to examine their value. They will make a decision about whether to make use of the products and obtain funding for the next iteration. Additional elements of the meeting are to learn from the experience in order to make an improvement for the next iteration. Some teams conduct a different meeting for that purpose; members give their opinions on what went well and what needs improvement. This meeting is called a Sprint Retrospective.
The Sprint Review usually results in some adaptation of the product backlog. Enhancement requests are added, defects are submitted, and maybe new features are introduced. The remaining items in the sprint backlog are moved to the product backlog. The team can add an activity, for example, to learn and experiment with a new technology, or to perform more performance tests. Stakeholders and product owners may decide to change the priorities of some backlog requirements.
Now a new sprint starts again with teams selecting top-priority requests for development. The sprint cycles continue until the stakeholders think they have enough value and quality to release a product. This stage is called the Release Iteration or the End Game. During this iteration final system testing and acceptance testing are performed. Stakeholders may request some defect fixing. The team finalizes system and user documentation. Users and administrators are trained, and the system is deployed to production.
The Scrum project process is often described using the schema illustrated in Figure 11.2.
)
Figure 11.2 The Scrum Project Lifecycle (copyright Scott W. Ambler)