Agile Scrum

Agile Scrum

Kenneth R. Walsh (University of New Orleans, USA) and Sathiadev Mahesh (University of New Orleans, USA)
DOI: 10.4018/978-1-4666-5888-2.ch691
OnDemand PDF Download:
$30.00
List Price: $37.50

Chapter Preview

Top

Background

Scrum is suitable in turbulent business situations where change must be embraced rather than rejected. Scrum is beneficial in situations where initial cost and time estimates are unreliable. The project manager can dynamically adapt to changes in cost and time using scrum (Chen, van den Akker, Brinkkemper, & Diepen, 2010). While scrum is commonly recommended for smaller projects, it can be integrated with approaches used for large projects such as the Capability Maturity Model (CMM) (Sutherland, Jakobsen, & Johnson, 2007; Marcal, de Freitas, Furtado-Soares, & Belchior, 2007). Roadmaps to link scrum practices to the CMMI model and provide a Mature Scrum approach are presented by Lucasiewicz and Miler (2012) and Moksen and Mensely (2012). Since CMMI enforces discipline in software development throughout the organization, and institutionalizes processes in the business, scrum benefits from a workforce that can adapt to and abide by the rules of the system. It is important to understand that scrum is not undisciplined hacking, but is systematic development of a product within a dynamic environment.

Scrum has been combined with extreme programming (XP) and the Unified Software Development Process (Zhang & Patel, 2011). While standard scrum has sandboxed sprints, with one sprint completed and reviewed before the next sprint, an overlapping sprint approach (Sutherland J., 2005) has been proposed by Jeff Sutherland, one of the developers of the original scrum approach. Sutherland describes type B and type C scrums where each sprint has tasks that stage work for a subsequent sprint. This reduces the time used to update and prepare the newly prioritized product backlog at the start of each sprint.

Key Terms in this Chapter

Sprint Planning Meeting: A negotiation between the scrum team (Development team, QA, Training, and TE), the Product Owner, Project Manager, and the Customer about what the scrum team will accomplish during the next sprint. Since the time allocated for a sprint is between two weeks and a month, it is important that the scrum team is capable of completing the tasks within the allotted time. The Product Owner explains how the highest priority items in the Product backlog should work, and the team chooses functionalities to be developed, and makes time estimates. The team defines tasks to be completed. The process is also called Sprint Backlog Settlement.

Sprint Backlog: Contains the user stories from the product backlog that will be addressed in the sprint. The development team defines detailed tasks to complete these items and estimates time and resources for these tasks during the sprint planning meeting. Sprint backlog items are sometimes sized to be completed in a few hours. The sprint backlog items are kept at a fine level of granularity to facilitate completion before the next scrum meeting.

Burndown Charts: Show work remaining over time, with time on the horizontal axis. A sprint burndown chart shows daily progress with task hours left for the day on the vertical axis. A product burndown chart presents a “big picture” view of a project's progress and shows the work to be accomplished at the beginning of each sprint on the vertical axis.

Sprint Review Meeting: Held at the end of the sprint when the work is presented to the Product Owner and other stakeholders. The Sprint Retrospective meeting allows the scrum team and the Scrum Master to discuss what went well and what to improve in the process for the next sprint. The Product Owner does not attend the retrospective meeting.

Daily Scrum Meeting: A brief (fifteen minute) daily meeting attended by the scrum team in which each member answers three questions (1) tasks done the previous day (2) tasks to be done before the next scrum, (3) any impediments that prevent task completion.

Product Backlog: A list of user stories with priority rankings. In addition to user stories, requirements may be generated by the team to make the product feasible. During the Sprint Planning Meeting, backlog items are moved from the Product Backlog into a Sprint Backlog, based on the priorities. A backlog item is small and can be completed within one sprint. Backlog items are made up of smaller tasks.

Velocity: The number of story points that the scrum team can handle in one sprint. The baseline velocity for the organization is determined in the first sprint. Velocity charts show the scrum team's performance over time.

Sprint: One phase of the project during which one part of the product functionality is implemented. The product functionality is termed an increment. The sprint starts with a 1-day Sprint Planning Meeting. Daily Scrum meetings are held during the sprint. At the end of the sprint, there is a Sprint Review Meeting and a Sprint Retrospective Meeting. The team must not be interrupted with additional requests during the sprint, and team members must be dedicated to the project. This makes it possible for team members to keep commitments to the sprint.

Complete Chapter List

Search this Book:
Reset