Introduction to Scrum

Scrum, an agile method, is an iterative, incremental framework for projects and product or application development. Scrum is a way for teams to work together to develop a project or product. Project or Product development, using Scrum, occurs in small pieces, with each piece building upon previously created pieces. Building a project or product one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly and only what is needed. In simple terms, Scrum is a simple framework for effective team collaboration on complex projects. Scrum is much more than a simple framework. Scrum supports our need to be human at work: to belong, to learn, to do, to create and be creative, to grow, to improve, and to interact with other people.

A major theme in Scrum is “inspect and adapt”. Since development inevitably involves learning, innovation, and surprises, Scrum emphasizes taking short steps of development. Inspecting both the resulting product and the efficacy of current practices, it recommends improvising current or adapting new practices if required. This improvising on the processes and practices should be repeated for ever.

Scrum as an Agile Development Method Agile principles emphasize building working software that people can get hands on quickly, versus spending a lot of time writing specifications up front. Agile development focuses on cross-functional teams empowered to make decisions, versus big hierarchies and compartmentalization by function. Agile development also focuses on rapid iteration, with continuous customer input along the way. The term “Scrum” is extracted from the game of Rugby in which a self-organizing (self-managing) team moves together down the field (The Product Development).

Scrum Roles The Scrum Team is comprised of three Scrum roles: The Product Owner Takes the input of what the project or product should be and translates them into a product vision or a product backlog. The Team Develops the project or product envisioned by the Product Owner. The Scrum Master Does whatever it takes to make the Scrum team successful, such as removing organizational impediments, facilitating meetings, acting as a gatekeeper so no one unnecessarily interrupts the team's work.

Scrum Ancillary Roles The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process—but nonetheless, they must be taken into account. Stakeholders: The stakeholders are the customers, vendors. They are people who enable the project or product and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews. Managers: People who control the environment.

Sprint Scrum structures development in cycles of work called sprints. Sprints are less than one month in length, and usually measured in weeks. Sprints take place one after the other. The sprints are of fixed duration. They end on a specific date whether the work has been completed or not. They are never extended. So they are said to be timeboxed.

… Sprint At the beginning of each sprint, a cross-functional team selects items (customer requirements) from a prioritized list called the “Product Backlog,” and this list is called the “Sprint Backlog.” The team commits to complete the items by the end of the sprint. During the sprint, the chosen items do not change. Every day the team gathers briefly (“Daily Scrum”) to re-plan its work to optimize the likelihood of meeting commitments.

… Sprint At the end of the sprint, the team reviews the sprint (“Sprint Retrospective”) with stakeholders and demonstrates what they have built, including the features developed in previous sprints (“increments”). People obtain feedback that can be incorporated in the next sprint. Scrum emphasizes a working project or product at the end of the sprint that is really “Done.” “Done” means code that is Integrated. Fully tested. Potentially shippable.

Meetings Daily Scrum Backlog grooming: story time Scrum of Scrums Sprint planning meeting Sprint review meeting Sprint retrospective

Daily Scrum Each day during the sprint, a project or product status meeting occurs. This is called a “daily Scrum,” or the daily stand-up. This meeting has specific guidelines: All members of the development team come prepared with the updates for the meeting. The meeting starts precisely on time even if some development team members are missing. The meeting should happen at the same location and same time every day. The meeting length is set (timeboxed) to 15 minutes. All are welcome, but normally only the core roles speak.

… Daily Scrum During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do today? Any impediments/stumbling blocks? Any impediment/stumbling block identified in this meeting is documented by the ScrumMaster and worked toward resolution outside of this meeting. No detailed discussions shall happen in this meeting.

Backlog Grooming: Story Time The team should spend time during a sprint doing product backlog grooming. This is the process of estimating the existing backlog using effort/points, refining the acceptance criteria for individual stories, and breaking larger stories into smaller stories. Meetings should not be longer than an hour. Meetings do not include breaking stories into tasks. The team can decide how many meetings are needed per week. The most commonly used method is “planning poker.”

Scrum of Scrums This meeting will be conducted each day, normally after the daily Scrum. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. A designated person from each team attends. The agenda will be the same as the daily Scrum, plus the following four questions: What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? Are you about to put something in another team’s way?

Sprint Planning Meeting At the beginning of the sprint cycle (every 7–30 days), a “Sprint planning meeting” is held. Select what work is to be done. Prepare the Sprint backlog that details the time it will take to do that work, with the entire team. Identify and communicate how much of the work is likely to be done during the current sprint. Eight-hour time limit: 1st four hours - Entire team dialog for prioritizing the product backlog. 2nd four hours - Development team hashing out a plan for the sprint, resulting in the sprint backlog.

Sprint Review Meeting The sprint review meeting will be held at the end of each sprint cycle. Review the work that was completed and not completed. Present the completed work to the stakeholders (“the demo”). Incomplete work cannot be demonstrated. Four-hour time limit.

Sprint Retrospection The sprint review meeting will be held at the end of each sprint cycle. All team members reflect on the past sprint. Make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Three-hour time limit. This meeting is facilitated by the ScrumMaster.

Artifacts The scrum process generally has the following artifacts: Increment Burn-down Product backlog Sprint backlog

Increment An increment is the sum of all the product backlog items completed to date, i.e., all the stories (features) completed during the current sprint and all the previous sprints. The increment must be in the usable condition.

Sprint Burn-down Chart The burn-down chart is the publicly displayed chart showing the work remaining in the sprint backlog. The burn-down chart is the graphic representation of the sprint progress.

Release Burn-down Chart This is the amount of work left to finish the stories or features that need to be completed for a release.

Product Backlog The product backlog is an ordered list of "requirements" that is maintained for a project or product. It contains product backlog items that are ordered by the product owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format. The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the product owner is ultimately responsible for prioritizing the stories on the backlog for the development team.

Product Backlog The product backlog contains rough estimates of both business value and development effort. These values are often stated in story points, using a rounded Fibonacci sequence. Those estimates help the product owner gauge the timeline and may influence the ordering of backlog items.

Sprint Backlog The sprint backlog is the work that the development team needs to address during the next sprint. This should be the list that is derived selecting stories (features) from the top of the of the product backlog (ordered in the priority) until the development team feels it has enough work that can be done in the sprint. The decision should be taken by the development team, asking, “Can we also do this?” before adding features to the sprint backlog. This decision should be taken depending on the velocity of its previous sprints (the total effort that the team is capable of delivering in a sprint).

Next Presentation I will be talking about different estimation techniques in my next presentation.

Please send feedback (preferably where I need to improve) to Resources: Scrum (software development) Scrum Handbook by Jeff Sutherland The Scrum Guide - The Definitive Guide to Scrum: Rules of the Game from Scruminc. Please send feedback (preferably where I need to improve) to gvadrevu@yahoo.com