Scrum Overview

Agenda What is scrum…and what it isn’t Scrum’s Characteristics The Scrum Process Scrum Phases Measurements Key Practices Backlogs Sprint 24 teams and work assignment Team assignments Backlog review TFS and reporting Next steps

What is Scrum Scrum is an agile, iterative, process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Based on modern process control theory, Scrum causes the best possible software to be constructed given when requirements are rapidly changing.

What SCRUM isn’t A design methodology A programming methodology A quality control methodology A documentation methodology You are free to use what ever you like to address these concerns. Scrum is meant to coexist with existing practices.

Scrum's Characteristics Projects are controlled through ongoing measurement and control of backlog, issues, risk, problems and changes -- task level management is not used A deliverable product is always ready through the use of constant builds and testing in parallel with development Small teams develop and enhance their solutions.

The Scrum Process Planning & ArchitectureSprintsClosure

Scrum Phases 1.Planning and System Architecture Phase 2.Sprints Phase 3.Closure Phase

Planning & System Architecture Phase Determine date at which the application should be placed in production or released to the market Prioritizing functionality requirements (ranging from good-enough to best-possible) Identifying the resources available for the development effort, envisioning the application architecture, and establishing the target operating environment(s). Planning phase is conducted relatively quickly because it assumes that pragmatic managers and the course of events will require that any or all of these initial parameters will be changed during the Sprint phase.

Sprints Phase Sprint teams are established consisting of between 1 and 7 members (dev/test/PM) Each team is given its assignments and all teams are told to break down their assignments to achieve their objectives on the same day. Delivery of those items is between 1 and 6 weeks from the start of the Sprint. At the end of the Sprint period all the teams meet to review their progress (including executable code delivered to date) with each other. At the conclusion of the review session, there exists an opportunity to change anything and everything. This built in flexibility allows the organization to add to (or, rarely, subtract from) the requirements for the application during the Sprint phase. When the objectives of the application development effort are completed in terms of functionality and quality, or the time/budget constraints are reached, the Sprint phase is completed. Approved modifications to the original planning and systems architecture are lumped into a category called backlog and assigned to the teams (whose resources may also be changed to reflect the new objectives) at the beginning of the next Sprint period.

Closure Phase Finishing system and regression testing Developing training materials Completing final documentation Approved modifications to the original planning and systems architecture are lumped into a category called backlog and assigned to the teams (whose resources may also be changed to reflect the new objectives) at the beginning of the next Sprint period.

Measurements A Scrum software project is controlled by establishing, maintaining, and monitoring key control parameters. These controls are measured, correlated, and tracked. The main controls are backlog and risk. –Backlog should start relatively high, get higher during planning, and then be whittled away as the project proceeds - either by being solved or removed, until the software is completed. –Risk will rise with the identification of backlog, issues, and problems, and fall to acceptable levels as the software is changed.

Key Practices Self-directed & self-organizing team No addition of work to iteration once chosen Daily stand up meeting with key questions Usually 30-day calendar iterations Demo to stakeholders at end of iteration Each iteration, client-driven adaptive planning

Key Workproducts 1.Product Backlog 2.Sprint Backlog

Product Backlog All conceivable items (requirements and features) go into the Product Backlog Estimates (in person hours) start as rough guidelines & refined as the team commits Product Owner owns the Product Backlog New items/work can be added at any time Product Backlog is prioritized

Example Product Backlog 1

Sprint Backlog Team estimates how many top pri items in Product Backlog are achievable in the next sprint – these become the Sprint Backlog Items may be broken down further and estimates improve (revised daily) Updated daily by PM (everyone inputs) New estimates are allowed to increase Track Sprint Burndown (Time Remaining) Management can’t add items during sprint

Example Sprint Backlog 1 1