Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

SCRUM

No description
by

Piotr Jachimczak

on 26 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SCRUM

A Quick Guide To Agile Development This is SCRUUUUM !! Manifesto for Agile Software Development



We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more. Individuals and interactions over processes and tools


PMI:
PMBoK - over 600 pages, 33 processes defined
ultimate solution for all problems ?

SCRUM:
Scrum Guide - 16 pages

Simple GOOD. Complex BAD. Key word: Communication Working software over comprehensive documentation

Traveling Lightly
Barely sufficient documentation

Documentation: expensive, not accurate

Solution:
Better talk with someone then write
Write documentation only when it's needed
When writing documentation keep in mind it's receivers
Use simplest possible form and language Customer collaboration over contract negotiation

Work with customer as one Team
Share new ideas and potential problems
Customer is in control !!!
Outcome is most important
Customer makes decisions based on information or lack of information that comes from YOU !!! Responding to change over following a plan

Plans change more often then don't
Don't complain, think about possible solution In project the only constant is change ! SCRUM Whole team is working to pass the ball
as far as possible Remember: opposing team is not the customer but project obstacles Visibility/Transparency
Inspection
Adaptation Empirical Process Control Significant aspects of the process must be visible to those responsible for the outcome. For example:
A common language referring to the process must be shared by all participants
A common "Definition of Done" must be shared by those performing the work and those accepting the work product.
Problems must be reported and known
Sprint progress must be known
Quality !! Checking burndown
Checking sprint velocity
Number of reported bugs
Managing issues and problems

Performed by "skilled inspectors at
the point of work" i.e. should be done by ScrumMaster An adjustment must be made as soon as possible to minimize further deviation.

Inspection and adaptation:
Sprint Planning Meeting
Daily Scrum
Sprint Review
Sprint Retrospective Adaptation is continuous process The Team

Roles:
Product owner
ScrumMaster
Developer

There are no other roles (i.e. tester)
Customer is part of our team
There should be only one Product Owner Product Owner Is responsible for maximizing the
value of the product and the work of the Development Team The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says. Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Ensuring the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
Ensuring the Development Team understands items in the Product Backlog to the level needed Scrum Master The Scrum Master is a servant-leader for the Scrum Team. Is responsible for ensuring Scrum is understood and enacted
Helps to solve problems
Helps everyone change interactions to maximize the value created by Scrum Team Scrum Master Service to the Product Owner  Finding techniques for effective Product Backlog management;
 Clearly communicating vision, goals, and Product Backlog items to the Development Team;
 Teaching the Scrum Team to create clear and concise Product Backlog items;
 Understanding long-term product planning in an empirical environment;
 Understanding and practicing agility;
 Facilitating Scrum events as requested or needed. Scrum Master Service to the Development Team Coaching the Development Team in self-organization and cross-functionality;
Teaching and leading the Development Team to create high-value products;
Removing impediments to the Development Team’s progress;
Facilitating Scrum events as requested or needed;
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood. Scrum Master Service to the Organization Leading and coaching the organization in its Scrum adoption;
Planning Scrum implementations within the organization;
Helping employees and stakeholders understand and enact Scrum and empirical product development;
Causing change that increases the productivity of the Scrum Team;
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. The Development Team They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole;

Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis. Sprint a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created  No changes are made that would affect the Sprint Goal;
 Development Team composition remains constant;
 Quality goals do not decrease
 Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
Only the Product Owner has the authority to cancel the Sprint Sprint Planning Meeting Part One: What will be done this Sprint? The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team
Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment. Part Two: How will the chosen work get done? Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting.
Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal
If the Development Team determines it has too much or too little work, it may renegotiate the Sprint Backlog items with the Product Owner
The Product Owner may be present during the second part of the Sprint Planning Meeting to clarify the selected Product Backlog items and to help make trade-offs four-hour long Sprint Goal As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology Daily Scrum Daily Scrums improve communications, eliminate other meetings, identify and remove impediments to development, highlight and promote quick decision-making, and improve the Development Team’s level of project knowledge. This is a key inspect and adapt meeting. The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.
The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.
The Development Team uses the Daily Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog.
The Development Team often meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s work.
Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint.
The Development Team tracks this total work remaining at least for every Daily Scrum The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s Definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it. The Increment Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. Sprint Backlog The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
As new work is required, the Development Team adds it to the Sprint Backlog.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team. Sprint Review two-hour long an informal meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. The Sprint Review includes the following elements:
The Product Owner identifies what has been “Done” and what has not been “Done”;
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date;
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. Sprint Retrospective The purpose of the Sprint Retrospective is to:
 Inspect how the last Sprint went with regards to people, relationships, process, and tools;
 Identify and order the major items that went well and potential improvements;
 Create a plan for implementing improvements to the way the Scrum Team does its work. The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. 1,5-hour long  Lightweight
 Simple to understand
 Extremely difficult to master SCRUM is Does it mean that we don't know how to use SCRUM ? YES !!! Why SCRUM is difficult ? We're used to old development process
Agile approach is something completely different from old development process
As humans we do not like change
We are in control -> more responsibilities
We do not take into consideration learning curve
There is no "comfort zone" in SCRUM
SCRUM requires constant improvement
SCRUM requires high problem solving skills What can we do ? Continuous Improvement !!! Beyond SCRUM SCRUM does not tell us how to actually code application
SCRUM does not define specific processes
SCRUM does not define specific tools Common problem: because of the mess in code later sprints have smaller increments Why user stories ? "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, and estimate." Easy to understand by technical and non technical stuff
Easy to manage (i.e. break down to smaller stories)
Easy to evaluate (you know Product Owner expectations)
Easy to test (you don't need SRS and test plans) Why KANBAN ? Ensures visibility (for example on Daily SCRUMs
Simplicity
Enables cooperation
Fun to use !!! Maybe eXtreme Programming ? 1. Pair programming
2. Test-driven development
3. Planning game
4. Continuous integration
5. Continuous Refactoring
6. Small Releases
7. System metaphor
8. Simple design
9. Collective code ownership
10. Design improvement
11. Sustainable pace
12. On-site customer Large-scale SCRUM Grooming A Backlog Grooming session can be used to:
• Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more StoryTime sessions)
• Break down user stories that are too big (epics)
• Improve user stories that are poorly written
• Estimate backlog items
• Add acceptance criteria
• Look deeper into the backlog to do longer-range technical planning Whole SCRUM team should participate
Everyone helps prepare product backlog
Clarify acceptance criteria Embrace the change !!!
SCRUM does not resolve problems, it exposes them
Efficient communication is a key to better productivity
SCRUM team is self-organized, no master-and-commander here
Team members are multi-functional
Don't whine, think of solutions
Know where You stand ... always !!! "Listen to the gurus, read the books, but then think for yourself!" eXtreme Programming
SCRUM
Crystal Methods
DSDM
Feature Driven Development
Lean software development
Kanban (development) Agile Frameworks Framework less than methodology
simple
flexible
do not solve problems SCRUM + XP
SCRUM + LEAN
SCRUM + LEAN + XP
FDD + XP Blender SCRUM - foundation
XP - tech quality
Lean/Kanban - process Visibility Inspection Adaptation Definition of Done Helps to make binary decision if given piece of functionality is done or not (YES/NO)
There is no almost done !!! Example of DoD for task * Code written
* TODOs removed
* Unit Tests written (coverage > 75%)
* Build is “Green” on CI system
* Documentation written (if needed)
* Code Review done
* Fixes after code review done Example of DoD for feature * Automatic E2E tests written
* All tests are green
* Acceptance criteria passed
* Feature deployed to .Q env
* Documentation attached Agenda Agile Software Development
Agile frameworks
Agile manifesto
SCRUM
Basics
Roles
Sprint
Artifacts
Events
Beyond SCRUM
User stories
SCRUM + XP Artifacts Product Backlog
Sprint Backlog Product Backlog Ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases Product Backlog items have the attributes of a description, order, and estimate. User Stories ready for development should be

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable Slaiders
Full transcript