Agile development methodologyHelps cross-functional teams commit and deliver high-quality, production-ready code in phasesScrum is an iterative process for developing any product or managing any work, which produces a potentially shippable set of functionality at the end of every iteration. Scrum engages developers to produce the major pieces of an application in less time than by traditional methods
Self-organizing teamsProduct progresses in a series of two- to four-week “sprints”Requirements are captured as items in a list of “product backlog”No specific engineering practices prescribedUses generative rules to create an agile environment for delivering projects
Team environment & communicationQuality productProvide more information on project progress early onAbility to adjust to business needs
Time is spent on every phase, but the client doesn’t see any benefit until the endMajor changes due to business needs are not easily incorporated into the designQA does not get involved until the end which results in very costly bug fixes
Sprint planning meetingAllows product owner and team to see what will be deliveredTeam addresses “What” and “How”Sprint goal is setItems are moved from the product backlog into a sprintSprint backlog is createdDaily Scrum meetingsAllows team to see entire picture everydayShort meeting, team members answer the following:What did I work on since the last meeting?What will I work on until we meet again?What impediments are preventing me from getting my tasks done?Not a status meetingSprint review meetingOccurs at the end of the sprintProduct is demo’dProduct owner can accept/reject the deliverablesReview Product backlog at the endSprint retrospectiveDiscuss what went well and what to improve in the next sprintTeam is encouraged to revise processes in order to become more effective on the following sprintInspect how the last Sprint went in regards to people, relationships, process and toolsThe product owner does not attend this meeting.Start/Stop/Continue
Self-organizing teamsNo one person is in charge of the team’s decisionsTeam is responsible for committing and deliveringCross-functional teams (BSA, QA, developers, PM)
Product BacklogThe requirements for a systemPrioritized list Includes both functional and non-functional customer requirements, as well as technical team-generated requirements. Sprint BacklogDefines the work for a sprintRepresented by the set of tasks that must be completed to realize the sprint's goals
Tracks how much value has yet to be deliveredWork remaining is the Y axis and time is the X axisSprint burn-down charts show daily progressProduct burn-down chart show monthly (per sprint) progress.
Every sprint should produce “potentially shippable” codeTeam must define what “Done” means to themEveryone should have the same understanding of “Done”
Focus on creating “production ready” deliverables at the end of each sprintProduct is designed, coded, unit tested, peer reviewed, built and QA tested during the sprintNever sacrifice qualityIf an item cannot be delivered, negotiate with project ownerIt should be apparent early in the process if something will not be deliveredA sprint should always run through completion to maintain quality of code base.At the end of each spring, a decision can be made regarding the direction of the project.Lack of focus on quality reduced efficiency over time
Sprint planning meetings allow the project owner and team to see what will be delivered and have a common “Sprint Goal”Sprint back-log is updated daily to show progress and possible estimation errorsSprint burn-down chart shows progress throughout the sprint (generated from the sprint back-log)Daily scrum meetings foster communication about daily tasks and allows the entire team to assess the project on a daily basis
Combines expert opinion, analysis to provide quick/reliable estimatesIncludes entire teamUse special cards or modified playing card Have fun
Transcript of "Succeeding with Scrum"
Succeeding with Scrum<br />Esteban Garcia<br />
Common pitfalls<br />Mini-waterfalls in each sprint<br />Making changes to the process before trying it out<br />ScrumMaster behaving as a team lead<br />Allowing sprints to go on longer than planned<br />Bug-creep<br />Developer-level burn-downs<br />QA not part of the process<br />
Conclusion<br />Scrum allows for better communication<br />Scrum helps with transparency<br />Scrum exposes existing problems and surfaces new problems as soon as they come up<br />Scrum helps you learn from the past<br />