Your SlideShare is downloading. ×
Succeeding with Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Succeeding with Scrum

2,112

Published on

Succeeding with Scrum presented at devLINK 2011.

Succeeding with Scrum presented at devLINK 2011.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,112
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
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

    ×