• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,065
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
126
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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

  • 1. Succeeding with Scrum
    Esteban Garcia
  • 2.
  • 3.
  • 4. What is Scrum?
    Agile development
    Iterative
    High-quality code
    Shippable product with every iteration
    High-priority features first
  • 5. Characteristics
    Self-organizing teams
    Sprints
    Product Backlog
    User Stories
  • 6. Goals
    Team environment
    Communication
    Quality product
    Transparency
    Agility
  • 7. Traditional Approach
  • 8. The Problem
  • 9. Scrum Process
  • 10. Scrum Process
    Release Planning Meeting
    Sprint
    Sprint Planning Meeting
    Sprint Review
    Sprint Retrospective
    Daily Scrum
  • 11. Team dynamics
  • 12. Backlogs
    Product Backlog
    Sprint Backlog
  • 13. Burn-down chart
  • 14. Done
  • 15. Let’s build a website!
    An E-commerce website is needed for your sportswear company
    Product Backlog:
  • 16. Sprint backlog
    Break down the tasks from the product backlog and make a commitment for the sprint: “As a user, I can view the company’s inventory”
  • 17. Calculating Velocity
  • 18. Burndown Chart
  • 19. Velocity Chart
  • 20. Quality
    “Production Ready” after every sprint
    Never sacrifice quality
    Run sprints through completion
    Re-assess often
  • 21. Communication
    Sprint planning meetings
    Sprint goal
    Sprint back-log
    Sprint burn-down chart
    Daily scrum meetings
  • 22. Tools – Planning Poker
  • 23. Tools – Task Board
    Source: http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg
  • 24. Software Tools
    Whiteboard
    Excel
    TFS (Scrum Templates)
    TeamPulse
    ScrumWorks
    Rally Software
  • 25. Common pitfalls
    Mini-waterfalls in each sprint
    Making changes to the process before trying it out
    ScrumMaster behaving as a team lead
    Allowing sprints to go on longer than planned
    Bug-creep
    Developer-level burn-downs
    QA not part of the process
  • 26. Conclusion
    Scrum allows for better communication
    Scrum helps with transparency
    Scrum exposes existing problems and surfaces new problems as soon as they come up
    Scrum helps you learn from the past
  • 27. esteban.garcia@agilethought.com
    http://estebanfg.blogspot.com
    @EstebanFGarcia