Scrum Process Overview

Thien Nguyen – May 2016thiennv1211@gmail.com

Agile Methodologies

Waterfall vs Agile

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

Why is it called Scrum?

Scrum Overview

Scrum Overview (cont)

Project Road Map

To Start UpSprint 0: To “setup” a project or product, to do non-functional work

Scrum Roles

Scrum Roles (cont)

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

Artifact• The Product Backlog• Sprint log• Sprint Burndown Chart• Task Board• Velocity• Capacity

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

Sprint log - MS Excel

Scrum Log - Jira

Scrum Log - TFS

Sprint Burndown Chart

Task Board

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

Capacity

Scrum Activities• Release Planning (Grooming)Meeting• Sprint Planning Meeting• Daily Meeting• Sprint Demo/Review Meeting• Sprint Retrospective Meeting• Ad-hoc meeting

Release Planning meeting

Release Planning meeting (cont)

Sprint Planning 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

Sprint Planning Meeting (cont)

Agreement what will be done in the sprint

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

Daily Meeting

Daily Meeting (cont)Meet everyday to check the progress• Every one answer 3 questions

Sprint Demo/Review Meeting

Sprint Demo/Review Meeting (Cont)

Sprint Retrospective Meeting

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

Jira issue types Hierarchy (epic, story, task)

Jira issue types Hierarchy (epic, story, task) (cont)