Agile & Scrum (Software Development)

AGILE & SCRUM

Table of Contents:

• Agile & Scrum
• Scrum Events
• Scrum Team
• Scrum Artifacts
• Reports & Charts

Agile Menifesto

Four values of Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

What is Scrum?

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

• Scrum is not a method.
• It’s a lightweight framework.

Empiricism: (Empirical Approach)

• Transparency
• Inspection
• Adaption

Cross Functionality:

• Depending on the team needs, taking responsibility by each member of the team.

The History of Scrum

1995

• As a new lightweight framework Scrum. (Jeff Sutherland & Ken Schwaber)
• The combination of Scrum & Extreme Programming (Mke Beedle)

1996

• First formal introduction in an International Conference

2001

• The first publication of Agile Software Development and Scrum (Ken Schwaber ve Mike Beedle)
• Scrum has been being used by many companies actively.

The Reason For Choosing?

Avarage Life of Product:

• 1980 24 years
• 2021 2 years

Pareto Principle:

• 80 / 20 rule
• The 20% part of the product/service should be focused on by the team
• The most important part is that 20% of the product.
• Once the 20% part of the product is done, the other 80% part will be useful.
• Indeed, user only uses approximately that 20% of the product.
• It’s good for ROI ( Return of Investment )
• In summary “You can get what you pay for”

Minimum Viable Product

Minimum Viable Product

The most basic and fastest product that will be appeared

An Example:

• From A to B we want to go. This is our Product Goal.
• The product goal does not have to be an “Car”.
• It can be a motorcycle.
• Firstly we need to meet the needs of the client with a quick solution.
• Then, it’s developed step by step.

Classical Waterfall vs Agile Software

Waterfall Project Management

Quality Triange:

• Scope
• Date
• Budget

Meeting the needs:

An Example:

• A project takes 11 month and therefore it does not meet the needs.
• In UAT the “blame game” begins.
• Everyone blames each other.
• “That’s not what we expect.”

Other Methods

Agile:

• Exterme Programming (XP)
• Scrum

Others:

• Feature Driven Development
• Lean Software Development
• Kanban

…

Plan Driven:

• Rational Unified Process
• CMMI

Hybrid:

• Boehm-Turner Risk Model
• Manzo (AgileTek)

SCRUM EVENTS

Weekly Plan:

Daily Scrum

Timebox:

• 15 min / day

How?

3 questions

• What did you do yesterday?
• What will you do today?
• Anything blocking your progress?

Participant?

• Product Owner
• Developer
• Scrum master

Report:

• Sprint Burndown?
• How much work remains?
• How much work is done?
• The amount of work (Instant Progress)

Scrum Sprint Review

Timebox:

• 2 hours / Once in a (Two-Weeks) Sprint

Participant:

• Developer
• Stakeholders / The Client
• Product Owner
• Scrum Master

The purpose of the Sprint Review is to;

• Inspect the outcome of the Sprint
• Determine future adaptations.

The presentation of the “Done” — The Increment :

• Demo Meeting
• The Scrum Team (Developers) presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. (QA team can aslo present it)

Customer Feedback:

• Shareholders / The clients give the feedback.
• Current and prioritized needs are asked to Customer / Shareholders.
• Based on these needs, the Sprint Planning meeting is conducted. (Sprint Backlog)

Scrum Sprint Planning

• The story points of the completed sprints are listed in the following table below.
• The story point of active / future sprint is also listed in this table.
• If the story point of the active sprint is too low or high, scrum team can add or remove a new issue from backlog based on these values.

Timebox:

• 4 hours / Month (Max 8 hours)

Participant?

Scrum Team

• Developer
• Product Owner
• Scrum Master

How?

• The works / backlog items that are prepared and listed in previous Backlog Refinement meetings are added into Sprint Backlog based on their priorities in this meeting.

Discussion?

Sprint Planning Event Flow

• Why:

Why this sprint will be run?

The most important goal of this sprint? (Sprint Goal)

Why is this sprint valuable (to stakeholders)

• What:

Which works / tasks / backlog items?

What can be done this Sprint ?

• How:

How will the chosen work get done ?

For each selected Product Backlog item;

Decomposing Product Backlog items into smaller work items of one day or less.

• Prioritization:

MoSCoW Prioritization

Must Have

Should Have

Could Have (Nice to have)

Will not Have

• Scaling?

Story point verilir / Story Point Poker Game

(Backlog Refinement’da verilmeyen işler için)

• Report:

Velocity

project in ( [project_name] ) 
AND Sprint in ( [sprint_number] ) 
AND status was in (Done) during (2021-11-24, 2021-11-25) 
AND assignee = [developer_jira_id]

Story Point (Planning Poker)

How Story Points are given?:

• Firstly, the story is read out loud.
• Secondly, the team discusses the story.
• The Story Point is estimated by developer team.
• Each dev team member gives her/his story point at the same time.
• If there is a gap, it’s asked to the developer. Team discusses it again.
• Finally, a consensus is built and the story point is given.

How Story Point is estimated?

• Fibonacci sequence is used to estimate it.
• Relative Estimation technique is used to estimate it.
• Reference Point:
• For Example:
• The easiest task is refferenced.
• Adding a property in the object.
• Time box definitely is not used to estimate it.

Backlog Refinement

Timebox:

• 2 hours / 2 times in a Week

Participant:

• Product Owner
• Developer Team
• Scrum Master

Definition of Backlog Refinement:

• Product Backlog is an emergent, ordered list of what is needed to improve the product.
• It is the single source of work undertaken by the Scrum Team.

The purpose of the Backlog Refinement:

• Based on the needs of the shareholders / clients, adding details, estimating, and sorting the backlog items in the Product Backlog
• The team focuses the details to order the items.
• The stories / epics … are broken into small pieces.
• The scrum team does not focus on “What”.
• The scrum team focuses on “How”.
• Creating / Improving the stories & tasks & epics with the following items.
• User Story will be mapped.
• Who
• What
• Why
• Acceptance Criteria wlil be updated.
• Story Point will be estimated by the scrum team.

Reports:

• Velocity
• Burndown

Sprint Retrospective

Timebox:

• 3 hours / Sprint

The purpose of the Sprint Retrospective?

• The purpose of the Sprint Retrospective is to plan ways to increase the following items.
• Quailty
• Effectiveness

The Scrum Team discusses:

• What went well? | What went well during the Sprint?
• What could improve? | What problems it encountered?
• What will you change or retain? | How those problems were (or were not) solved.

Participant:

The Scrum Team

• Product Owner
• Scrum Master
• Developers
• (Shareholders / The Customers are not allowed to participate)

The Scrum Team inspects:

• Individuals
• Processes
• Tools
• Interactions

Example:

• How was the relationship with
• Other teams
• The client / Shareholders

Improving of Definition of Done:

Example:

• It can be improved and new D.O.D. items can be added or removed

Reports:

• CFD
• Control Chart
• Velocity
• Burndown

SCRUM TEAM

Scrum Team:

• Product Owner

“Maximizing the Value of the Product “

“Product Backlog

• Developers

“Creating Done Increments”

“Sprint Backlog”

• Scrum Master

“Promote and Support Scrum”

Scrum Team Size:

• Ten or less

Product Owner

“Maximizing the Value of the Product “

Accountable for:

• Accountable for maximizing of the value of the product resulting from the work of the scrum team.
• Represents the needs of stakeholders
• Product Goal
• Product Backlog management.
• Delegating PBI
• Ordering PBI
• Creating PBI
• User Story (P.O.)
• Acceptance Criteria (Scrum Team) *
• Definition of Done (Developers) *

Product Backlog

What?

• Product Backlog is an ordered list.
• PBIs are ordered based on the Product Goal.
• Each work should have the folllowing three items.
• PBIs:
• User Story
• Acceptance Criteria
• Definition Of Done

Product Goal

Definition: (Scrum Guide)

• It’s a long-term goal.
• Expected result at the end of the process.

Who defines?:

• Product Owner & Client
• It’s a part of Product Backlog

User Story

The client / shareholder and Product Owner defines together. (with the people who requests it.)

Natural language description of a customer requirements

The three process of the User Story:

Card:

• It’s created firstly.

Conversation:

• The following questions are asked to the client secondly.

Who:

• As a type of user…

What:

• I want to be able to…

Why:

• So that…

For example:

Who:

• As a user

What:

• I want to be able to sort by price range

Why:

• so that, I can decide where to eat

Confirmation:

• Once the client confirms this story, this card is moved forward to backlog

Acceptance Criteria

Who defines?
Scrum Team (Product Backlog Meeting)

What is this Acceptance Criteria:
The Acceptance Criteria is the requirement that has to be met to be considered the User Story completed by Product Owner, Stakeholders and the Client.

How it’s defined?
Each User Story should have a unique Acceptance Criteria. (not like D.O.D.)

Benefist:
Feature Scope is defined with this Acceptance Criteria.
What’s included
What’s excluded)
For an obvious fail/pass condition for User Story
Acceptance criteria is the main source for UAT.
Acceptance criteria helps the team to break the user story down if it’s needed.

For Example:

User Story:

• As a user
• I want to be able to filter my search results on map.
  so that I will be able to filter it on map directly.

Acceptance Criteria:

• Display the current filtered results on map
• Display the results without leaving the map view page.
• Refresh the map page without leaving the page.
• The filtered restaurants should be viewed on map.
• The filtered restaurant’s details should be viewed in the model view (popup view)
• The filtered restaurants should be clickable and once its clicked the user should be redirected to the restaurant page in a new tab.
  It should be compitable with Web & Mobil (responsive)

Definition of Done (D.O.D)

Who?

• Developer Team.

When?

• It’s improved in Sprint Retrospective meetings.

What?:

• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
• It creates transparency by providing a shared understanding of what was completed

What’s the difference between acceptance criteria and definition of done?

• The same DOD is used for all User Stories in a sprint.
• This time dev team creates and improve them.

For Example (DOD):

• Acceptance Criterias are met
• Unit Tests are done.
• Code Review is done.
  …

Developers

“Creating Done Increments”

Accountable for:

• The usable & useful piece of software work and (Increment) at the end of the sprint.
• Finding solutions to overcome the blocker issues, roadblocks during the development process.
• Adding the “Prioritized Product Backlog Items” into the Sprint Backlog. Sprint Backlog List is created by the developers.
• Choosing the ticket. (No Assignation). Team normally choose which tasks to work on, rather than being assigned work by a P.O.
• Estimating the “Story Point
  (Agile Poker / Planning Poker)
• Improving the Definition of Done. It’s improved in Sprint Retrospective events.

Definition of Done (D.O.D)

Who?

• Developer Team.

When?

• It’s improved in Sprint Retrospective meetings.

What?:

• The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
• It creates transparency by providing a shared understanding of what was completed

What’s the difference between acceptance criteria and definition of done?

• The same DOD is used for all User Stories in a sprint.
• This time dev team creates and improve them.

For Example (DOD):

• Acceptance Criterias are met
• Unit Tests are done.
• Code Review is done.
  …

Scrum Master

“Promote and Support Scrum”

Accountable for:

• Establishing Scrum as defined in the S.Guide
• Helping scrum team and also organizing the events
• The effectiveness of Scrum Team
• If Scrum Master is needed can enable practices for the Scrum Team
• Scrum Master can be a member of the Scrum Team or not.
• Scrum Master manages the progress.
  Managing Progress? YES.
  Managing Team? NO.

SCRUM ARTIFACTS

Product Backlog

• Who: By Product Owner.
• Produc Owner creates and improve it.
  Maximum Value of Product
• Product backlog is the refference point for the Developlerlar team
  Commitment: Product Goal

Sprint Backlog:

• Who: By Developer Team
  Commitment: Sprint Goal

Increment:

• Who: By Dev Team.
• It is the useful & usable piece of software work of the product that is revealed at the end of the sprint.
• This functional and revealed software work / feature is named as “Increment”..
• This piece of software work is presented to the Client in Sprint Review meeting.
• Developers are accountable for the quailty of this piece of software work / Increment.
  Commitment: Definition of Done

Product Backlog

Product Backlog

• Who: By Product Owner.
• Produc Owner creates and improve it.

Maximum Value of Product

• Product backlog is the refference point for the Developlerlar team

Commitment: Product Goal

Sprint Backlog

Sprint Backlog:

• The Sprint backlog is the part of the product backlog.
• In the Backlog Refinement meetings, sprint backlog is ordered by the priority of the issues.
• The issues are broken into smaller pieces if it’s needed.

Who: By Developer Team

Commitment: Sprint Goal

Increment

Increment:
Who: By Dev Team.
It is the useful & usable piece of software work of the product that is revealed at the end of the sprint.

This functional and revealed software work / feature is named as “Increment”. denir.
This piece of software work is presented to the Client in Sprint Review meeting.

Developerlars are accountable for the quailty of this piece of software work / Increment.

Commitment: Definition of Done

REPORTS & CHARTS

Sprint Report:

• Commitment
• Completed Issues
• Added Issues After Start Time
• Removed Issues After Start Time

Jira Queries (JQL):

• Increment
• Blocked Issues (During Sprint)
• Code Review & QA Failed Issues (During Sprint)

Sprint Charts:

Burn-down:

• Daily Scrum
• Sprint Retrospective

Control Chart:

• Sprint Retrospective

Velocity Report:

• Sprint Review
• Sprint Retrospective
• Sprint Planning

Sprint Report

Jira Queries

BurdownChart

ControlChart

Velocity