scrum process overview
TRANSCRIPT
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
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
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
Scrum Team• Typically 5-9 people• Cross-functional:
Programmers, testers, user experience designers, etc.
• Members should be full-time• Development to achieve sprint goals
The Product BacklogUser 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
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
Scrum Activities• Release Planning (Grooming)Meeting• Sprint Planning Meeting• Daily Meeting• Sprint Demo/Review Meeting• Sprint Retrospective Meeting• Ad-hoc meeting
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.
• TeamBreak-down each user story to tasksEstimate for each task.Commitment to complete the tasks.Update to sprint backlog
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
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 LogTo 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’.
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 date1 2 3
• Best Practice
• Action Need
Define for project• Definition Of Ready• Definition Of Done• Sprint Acceptance Criteria• Team Values• Jira issue types Hierarchy
(epic, story, task)
Definition Of ReadyI 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).
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, ...
Definition Of Done (Cont)• Sprint
Installed demo system for reviewThe Acceptance Criteria for the Sprint is metThe sprint must be accepted by the product ownerRelease package is based-lineRelease documentation is updated and completed such as Release note,
Product installation guide, User manual, ...
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 DescriptionSprint 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
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