Scrum Process Overview
Download as PPTX, PDF6 likes3,160 views
The document provides an overview of the Scrum process. Some key points: - Scrum is an agile process that focuses on delivering high business value in short iterations through inspecting working software every 2-4 weeks. The business prioritizes features. - Roles include the Product Owner who manages the product backlog, Scrum Master who facilitates the process, and cross-functional team. - Artifacts include the product backlog, sprint log/burndown chart, task board, and velocity/capacity metrics. - Activities include sprint planning, daily stand-ups, sprint demo/review, and retrospective meetings. Definitions of ready, done are established along with team values.
Scrum Process Overview
- 1. Scrum Process Overview Thien Nguyen – May 2016 thiennv1211@gmail.com
- 4. What is Scrum? • Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time • It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). • The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. • Every two weeks to a month customer can see real working software and decide to release it as is or continue to enhance it for another sprint
- 5. Why is it called Scrum?
- 9. To Start Up Sprint 0: To “setup” a project or product, to do non-functional work
- 10. Scrum Roles
- 12. Product Owner • Define the features of the product • Managing and prioritizing the Product Backlog • Decide on release date and content • Be responsible for the profitability of the product • Adjust features and priority every iteration, as needed • Accept or reject work results
- 13. Scrum Master • Responsible for enacting Scrum values and practices • Ensures that the process is followed • Removes impediments • Ensure that the team is fully functional and productive • Shield the team from external interferences
- 14. Scrum Team • Typically 5-9 people • Cross-functional: Programmers, testers, user experience designers, etc. • Members should be full-time • Development to achieve sprint goals
- 15. Artifact • The Product Backlog • Sprint log • Sprint Burndown Chart • Task Board • Velocity • Capacity
- 16. The Product Backlog User Story Description: As a <user role> I want to be able to <user wish/goal>, so that I can <business value> Business Acceptance Criteria Current and Suggested Mock-up Screens Workflows
- 17. Sprint log - MS Excel
- 18. Scrum Log - Jira
- 19. Scrum Log - TFS
- 21. Task Board
- 22. Velocity Velocity is the number of story points completed by a team in an iteration The velocity can be estimated as the average, over several recent sprints, of the sum of the estimates for the amount of work completed by a team per sprint — so in the chart above, the velocity = (37 + 47 + 50 +57) / 4 = 48. A team's recent velocity can be useful in helping to predict how much work can be completed by the team in a future sprint
- 23. Capacity
- 24. Scrum Activities • Release Planning (Grooming)Meeting • Sprint Planning Meeting • Daily Meeting • Sprint Demo/Review Meeting • Sprint Retrospective Meeting • Ad-hoc meeting
- 26. Release Planning meeting (cont)
- 28. Sprint Planning Meeting (cont) • Product Owner Present the Sprint goal and the highest priority Product Backlog. Review and clarify each item. Break each big story into smaller stories and clearly defined acceptance criteria. • Team Break-down each user story to tasks Estimate for each task. Commitment to complete the tasks. Update to sprint backlog
- 29. Sprint Planning Meeting (cont) Agreement what will be done in the sprint
- 30. Planning Poker • https://www.planningpoker.com • Card set Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, Pass, Break ) Modified Fibonacci ( 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pass, Break ) T-shirts ( xxs, xs, s, m, l, xl, xxl, ?, Pass, Break ) Powers of 2 ( 0, 1, 2, 4, 8, 16, 32, 64, ?, Pass, Break ) Others custom pointing scale
- 31. Daily Meeting
- 32. Daily Meeting (cont) Meet everyday to check the progress • Every one answer 3 questions
- 34. Sprint Demo/Review Meeting (Cont)
- 36. Sprint Retrospective Meeting (cont) • To check: What went well during the last sprint? What went wrong during the last sprint? What could be improved in the next sprint? Action need in the next sprint • Lessons Learnt and Best Practice Log To record during the project that can be usefully applied to other projects. As a minimum it should be updated at the end of each stage in the project. The Root Cause should explain why it happened, and the Lesson Learned should specify whether it was something that ‘worked well’, or identified as an ‘area for improvement’.
- 37. Sprint Retrospective Meeting (cont) • Lessons Learnt ID Area Description of Event/Situation Root Cause Lesson Learned 1 2 3 ID Process Area Description of Event/Situation Best Practice 1 2 3 ID Action Description Owner Due date 1 2 3 • Best Practice • Action Need
- 38. Define for project • Definition Of Ready • Definition Of Done • Sprint Acceptance Criteria • Team Values • Jira issue types Hierarchy (epic, story, task)
- 39. Definition Of Ready I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story. N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten. V Valuable A user story must deliver value to the end user. (vertical slicing) E Estimable The development team has to be able to estimate the size of a user story. S Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty. T Testable The user story or its related description must provide the necessary information to make test development possible (acceptance criteria).
- 40. Definition Of Done • User Story User story is provided or approved by Product Owner and they have to be based-line Selected User Story for the sprint is completed and understood by the team Tasks for selected user stories have been identified and estimated by the team (with consult by Technical lead) Technical Design Document is completed with respect to product theme and understood by the team (depends on user story) Technical Design Document is approved by Technical Lead (and stakeholders) and it have to be based-line (depends on user story) Code meets Coding Standard (e.g. as defined in Code Review Check list) Code is peer reviewed (or Technical lead reviewed) and checked in to SVN Code checked in there's no build errors on build server and not break any others existing code Code merged to another branch in case of enhancement or bug fix (depends on development process and source control tool used) Unit tests are written and executed to make sure that the code is covered and all unit test cases are passed (defined by the team in sprint planning) All test cases of the User Story are executed and passed Integration tests of the affected areas are conducted and passed All acceptance tests of the User Story are met Non-functional requirement fulfilled (browser capabilities, scalability, reliability, security etc..). All Tasks and sub tasks are set to done or removed Remaining hours for story set to zero Necessary Documentation is updated and completed such as design document, installation guide, ...
- 41. Definition Of Done (Cont) • Sprint Installed demo system for review The Acceptance Criteria for the Sprint is met The sprint must be accepted by the product owner Release package is based-line Release documentation is updated and completed such as Release note, Product installation guide, User manual, ...
- 42. Sprint Acceptance Criteria • All test cases of each user story are passed • There are no Critical or Major bugs • Define number of opened bugs before release to customer Type of defect Description Sprint 1 Blocker/ Critical Showstopper - An error that makes the whole or a significant part of the application inoperable or otherwise has a significant effect upon Customer's business. Tester cannot proceed with any tests e.g. system crash 0 Major An error that has a material effect upon the functionality, performance or user experience of the application function upon which Customer relies for the efficient conduct of its business. Tester can-not proceed with any tests in a functional area 0-1 Normal A major error (as defined above) that has an acceptable work around OR An error that has a nominal effect upon the functionality or performance of the application function upon which Customer relies for the conduct of the business. Does not stop testing - but limits it e.g. data validation wrong 0-2 Minor A minor or cosmetic error that and that causes a minimal effect upon the Customer's business. e.g. screen spelling or error message wrong 0-3
- 43. Team Values • Trust communication • Respect team mate and do not take critic personal • Think careful before saying something • Respect lunch time • Teamwork and support, sharing knowledge • On time for meeting, delivery • Never do deployment on Friday or before holidays • Questions and open discussion for un-clear things • Quality and performance • Work progress and tasks information updated
- 44. Jira issue types Hierarchy (epic, story, task)
- 45. Jira issue types Hierarchy (epic, story, task) (cont)