Agile scrum induction
•
5 j'aime•2,681 vues
Agile & Scrum Basics for Inducting a new team
![Agile Induction -Priyank [email_address]](https://image.slidesharecdn.com/agilescruminduction-110929040115-phpapp01/85/Agile-scrum-induction-1-320.jpg)
![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Agile scrum induction
Similaire à Agile scrum induction (20)
Dernier
Dernier (20)
Agile scrum induction
- 1. Agile Induction -Priyank [email_address]
- 4. SDLC Process
- 5. I Overview to Agile
- 6. Manifesto for Agile © Agile Alliance http://agilemanifesto.org
- 7. Agile Principles © Agile Alliance http://agilemanifesto.org
- 8. Agile Principles cont.. © Agile Alliance http://agilemanifesto.org
- 9. Agile Methodology © & Reference http://blog.klover.se/
- 10. II Overview to Scrum
- 11. Typical Scrum Lifecycle © Scot Amber http://www.ambysoft.com/essays/agileLifecycle.html
- 12. Sprint activities & roles Release n User Stories Sprint 1, 2, ..n Update product Backlog Sprint Planning Meeting > Daily Scrum > Daily Work Product Backlog Product Backlog Burndown Sprint Backlog Sprint Burn down Impediments list Sprint Retrospective Sprint Review Product Increment Sprint Cycle > Daily Cycle > Product Owner Scrum Master Stakeholders Scrum Team End Users © Scot Amber http://www.ambysoft.com/essays/agileLifecycle.html
- 13. Scrum Size: Scrum team is of 8-10 team members while few of the team cab be small in size and have only 3-4 team members
- 14. Scrum Team
- 15. Extended Release Team Note essential to have a separate Release team as Scrum can integrate
- 25. Planning Poker cont Clarity ? Tester Coder UI Dev Tester Coder Coder 4 8 3 2 4 1 User Story Planning Poker Outliers Discussion Estimates
- 28. Testing During an Iteration After an Iteration In Integration , System Test & UAT Bug Tracking Test @ Sprint Test @ Release Test Environment Skill Requirement Automation Manual
- 32. IV Metrics, Meetings and Reporting
Notes de l'éditeur
- Steps - Product Owner starts by explaining a user story to team Story can be further divided at granular level task (Action Items) Story can have multiple tasks These task would be estimated for efforts required to develop each Every team member can write his estimated Story Point on a Card Play card are collectively displayed to everyone For example 1,2,4,6,6,4,8,8,12 are the cards shown by a team Outliers can be picked up first for analysis Like 1 and 12 would be analyzed first in above example Developer/team will provide prospective and insight for tagging them 1 and 12 And this discussion can address more insight over what exactly is to be developed Estimate can be done on teams agreement on a number. As a practice team can pick an estimate for general understanding .
- Held daily 15- Minutes (no longer, otherwise it’s not a daily stand up) Not for problem solving (if there are issues that need to be addressed hold a separate meeting) Is not a status for the scrum master or project owner. It’s commitments in front of peers Fix Place – Hold the daily scrum in the same place at the same time every work day. Time – Best time is early in the morning so that the first thing team members do on arriving at work is think of- What they did the day before? and, What they plan to do today? All team members are required to attend. Cannot attend in person, by phone or by having another team member report on the absent members status. Team members must be prompt. The scrum master starts the meeting at the appointed time, regardless of who is present. Each team member should respond to three questions only: 1. What have you done since the last daily scrum regarding this project? 2. What will you do between now and the next daily scrum meeting regarding this project? 3. What impedes you from performing your work as effectively as possible?
- Focus on acceptance criteria . You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done. Start with the demo in mind . Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story. Prepare . Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Selenium if necessary to get your app into a state where you can start an interesting demo. Practice . Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Snagit and record yourself giving the practice demo. Painful, huh? That just means you need to work on it. Tell a story . Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable. Keep it short . If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.
- Velocity can be calculated by Using historical data Running an iteration Making a forecast Example: In last iteration team completed 3 user stories (where Story 1 is having 5 story points, Story 2 had 4 and Story 3 had 2) then Velocity is 5+4+2 = 11 Story Points. Iteration can be planned using velocity. Release planning is based on Velocity