Corporate Education Group

C O R P O R AT E E D U C AT I O N G R O U P Key Practice: Sprint Retrospective At the end of the sprint review, before planning the next sprint, the team meets to review its own processes and methods. The sprint retrospective is inward looking. It is a 30-minute brainstorming ses- sion in which the team determines: • What we should continue to do • What we should stop doing Managers and observers may not attend. It is reflective, looks inward and is intended to be honest so that process improvements result. Key Practice: Frequent Testing To assure a continuous working product, testing is done during every sprint. To do this efficiently, automated regression testing tools are essential. Each team mem- ber first tests their own code and then the QA role tests the product before the sprint review. Continu- ous integration is emphasized and acceptance tests should be written before coding starts. This forces a full and accurate definition of the exact product requirements. Key Practice: Time-boxing Each iteration (sprint) is time boxed, which means it is held to a particular length of time. The typical length of an iteration is 15 to 30 calendar days and the iteration length remains the same throughout the project. The length can be extended on large projects, but the risk of building the wrong product may increase as reviews are done less frequently. No extensions are allowed, but reduced scope is accepted. A fixed iteration length allows us to estab- lish the actual working capacity of the team. With a fixed iteration length, there is a tendency for project managers to demand that everything that was agreed upon for the iteration be completed no matter how much effort it takes; working nights and weekends is often required—which is not good! The team must work at a sustain- able pace; otherwise you will nev- er know the exact capacity of the team other than its peak capacity. And that pace is impossible to sustain through the entire project unless you want team members to burn out and eventually leave. All tasks must be time boxed— sprint reviews, daily scrums, design meetings, sprint retro- spectives. A scrum team sets a deadline for everything it does. This practice focuses the team and forces them to forgo less import- ant work. User Stories as Requirements User stories define requirements from a user's perspective and are deliberately written without much detail. Details are added during conversations with the user, product owner, and subject matter experts once the user story has been selected for implementation during an iteration. Example user story: As a cashier, I want to be able to enter a customer's order so that I can track and review it. 1 Managing User Stories User stories are often tracked using simple methods such as hand-written index cards, but software tracking systems are also available. User stories should be visible to all team members and stakeholders; it is common to pin them up on the wall in the team's war room. Product Backlog Prioritized product features Sprint Backlog Selected features Sprint Tasks Tasks and Owners Time Remaining Code Design Test Review Plan Reflect 30 DAY SPRINT Figure 3. Scrum Methodology Overview 1 This is the format originally suggested by Mike Cohn.

• Cover