Scrum - The Very Basics
•Télécharger en tant que KEY, PDF•
2 j'aime•377 vues
A very short take on what Scrum is.
Recommandé
Recommandé
Contenu connexe
En vedette
Dernier
Dernier (20)
Scrum - The Very Basics
- 1. SCRUM
- 3. PRODUCT
- 4. 3 ROLES Scrum Master Product Owner The Team
- 5. PRODUCT OWNER “I own your ass”
- 6. SCRUM MASTER “Get to work!”
- 7. TEAM “We make it happen”
- 8. TEAM Developers Testers Customers Executives “I make stuff ” “I make sure “I use it” “I pay for it” it works”
- 10. USER STORIES
- 11. RELEASE BACKLOG
- 12. SPRINT
- 13. SPRINT DEMO
- 14. BURNDOWN CHART
- 15. VELOCITY
- 16. BUGS
- 17. DEFECT BACKLOG
- 19. SUMMARY SCRUM is: • Short, iterative cycles • Plan > Develop > Demo > Plan • Product & Deliverable based cycles • Self managing Teams
- 20. THANKS
Notes de l'éditeur
- Introduction to Scrum methodology\n
- What is SCRUM & why should I care?\nSCRUM = Agile development liftcycle built on a few simple ideas - iterative design, build and test cycles - all centered around one thing...\n
- The first is that you have a Product. This is the core thing that will be produced during the project - be it software, a website, a garden shed... anything.\n
- A SCRUM project has 3 main roles. They must be unique people and should be 100% on any 1 project.\n
- First is the Project Owner - She represents the client (or could be the client) and is solely responsible for making the Project Backlog (more about this in a moment)\n
- The Scrum Master is the Ring Leader. They help the Project Owner prioritize the Backlog and track the Team and project progress.\n
- The Team are the ones that build the system - the developers, designers, IAs, UX team - All the people that actually *make* the product.\n
- A Team usually consists of 4 types of people - Developers (those who make it), Testers (those who make sure it works), Customers (who make sure its meeting the requirements) and Executives (who pay for it).\n
- The Project Backlog is one of *the* most important pieces of the SCRUM method. This is where all the requirements and wish lists are kept as actual achievable goals. This is done through...\n
- User Stories. Each Backlog item must relate to a user story or scenario. These are created by the Product Owner (with the help of the Scrum Master if needs be).\n
- When you’ve decided on the product -i.e. what you want to build - you break it up into small chunks called Sprints and each Sprint has a Release Backlog of requirements that will be built during the Sprint.\n
- Sprints can vary in length from 3 to 30 days and are dependent on the timeline of the project. The shorter the time you have to complete the project, the shorter the Sprint should be.\n
- At the end of each Sprint you should have a demo-able product that will be shown to the Product Owner and the Scrum Master. The next Sprint will then be reevaluated and the Release Backlog will be agreed upon.\n
- As each Backlog item is checked off, the time that it took to complete is compared to the estimate that the developer gave before kick off and the actual time it took is places on a Burndown chart.\n
- This helps the Scrum Master to calculate the Velocity of each of the Team members - that is, whether they are faster or slower than they think they are. This helps them get an accurate idea of how long the project should take to complete.\n
- But what about Bugs? These should be flaged by Testers during a Sprint and a Backlog item should not be checked off until the Bugs are squashed. Every few Sprints there should be one dedicated to taking care of bigger bugs.\n
- The bigger Bugs and hold-ups are collected in a separate Defect Backlog. This Backlog will be the one that drives the Bug Sprint.\n
- During a Sprint its important that the Team knows what the rest of the Team is working on and that Team members can flag any dependencies or hold-ups with each other. This is done with a short standing meeting, no more than 15 minutes long, at the beginning of each day of a Sprint.\n
- So, what is SCRUM? Is basically a short development cycle where importance is placed on delivering a working product at the end of each cycle. This means that you’re always chiping away at the actual mountian of work, rather than trying to wade through it.\n
- Thanks for taking the time to listen to me today and if you have any questions please feel free to talk to me any time or check out the resource links.\n