an introduction to scrum -...

Agile Training

Topics Covered

• Agile Fundamentals

• Jira Workflow

• Release Process

• Glossary

Agile Principles

The Agile Manifesto is based on 12 principles:

• Customer satisfaction by rapid delivery of useful software

• Welcome changing requirements, even late in development

• Working software is delivered frequently (weeks rather than

months)

• Close, daily cooperation between business people and

developers

• Projects are built around motivated individuals, who should be

trusted

• Face-to-face conversation is the best form of communication

(co-location)

Agile Principles

• Working software is the principal measure of progress

• Sustainable development, able to maintain a constant pace

• Continuous attention to technical excellence and good design

enhances agility

• Simplicity—the art of maximizing the amount of work not

done—is essential

• Self-organizing teams

• Regular adaptation to become more effective.

Agile Philosophy

Important

• Processes and tools

• Detailed documentation

• Contract negotiations

• Following a plan

More Important

• Individuals and interaction

• Functioning software

• Collaboration with the customer

• Adapting to changes

Why Agile?

• Business Value - The ROI and Time to Market is much quicker or faster in

Agile approach.

• Uncertainty and risk is reduced.

• Early Feedback

• Managed Complexity

• Inspect & Adapt

Scrum Characteristics

“Scrum is an iterative and incremental agile software development framework for managing product development.”

• Self-organizing teams

• Product progresses in a series of month-long “sprints”

• Requirements are captured as items in a list of “product backlog”

• No specific engineering practices prescribed

• Uses generative rules to create an agile environment for delivering projects

Scrum

Daily Scrum Meeting

• Done since last meeting

• Plan for today

• Obstacles?

24 hours

2-4 weeks

Product Backlog • Prioritized product features

• Add to at any time

Sprint Backlog expanded

by team

Sprint Planning Meeting

• Review Product Backlog

• Estimate Sprint Backlog

• Commit to iteration (2-4

weeks)

Potentially Shippable

Product Increment

Sprint Review Meeting

• Demo features to all

• Retrospective on the Sprint

Sprints

• Scrum projects make progress in a series of “sprints”

• Typical duration is 2–4 weeks or a calendar month at

most

• A constant duration leads to a better rhythm

• Product is designed, coded, and tested during the

sprint

No changes during a sprint

• Plan sprint durations around how long you can commit

to keeping change out of the sprint

Change

Scrum framework

•Product owner

•ScrumMaster

•Team

Roles

•Sprint planning

•Sprint review

•Sprint retrospective

•Daily scrum meeting

Activities

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts

Scrum framework

•Sprint planning

•Sprint review



Activities

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts

•Product owner

•ScrumMaster

•Team

Roles

Product owner

• Has Product Vision

• Define the features of the product

• Decide on release date and content

• Be responsible for the profitability of the product (ROI)

• Prioritize features according to market value

• Adjust features and priority every iteration, as needed

• Answers requirement questions

• Accept or reject work results

Represents the voice of the customer to ensure

the Scrum Team works with the right things from

a business perspective.

The ScrumMaster

• Represents management to the project

• Runs meetings and manages process

• Responsible for enacting Scrum values and practices

• Removes impediments

• Ensure that the team is fully functional and productive

• Enable close cooperation across all roles and functions

• Shield the team from external interferences

• Moderator,Trainer,Mentor,Mediator

• Fosters continuous improvement

The team

• Typically 5-9 people

• Cross-functional:

• Programmers, testers, user experience designers, product owner etc.

• Members should be full-time

• May be exceptions (e.g., database administrator)

• Teams are self-organizing

• Ideally, no titles but rarely a possibility

• Collective responsible for delivery.

•Product owner

•ScrumMaster

•Team

Roles

Scrum framework

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts

•Sprint planning

•Sprint review



Activities

Sprint planning meeting

Sprint prioritization

• Analyze and evaluate product

backlog

• Select sprint goal

Sprint planning

• Decide how to achieve sprint

goal (design)

• Create sprint backlog (tasks)

from product backlog items

(user stories / features)

• Estimate sprint backlog in hours

Sprint

goal

Sprint

backlog

Business

conditions

Team

capacity

Product

backlog

Technology

Current

product

Pro

du

ct

Ow

ne

r

Sc

rum

Te

am

Cu

sto

me

rs

Ma

na

gem

en

t

Sprint Planning Meeting

Sprint planning

• Team selects items from the product backlog they can commit to completing

• Sprint backlog is created

• Tasks are identified and each is estimated (1-16 hours)

• Collaboratively, not done alone by the ScrumMaster

• High-level design is considered

As a vacation planner, I want to see photos of the hotels.

Code the middle tier (8 hours)

Code the user interface (4)

Write test fixtures (4)

Code the foo class (6)

Update performance tests (4)

The daily scrum

• Parameters

• Daily

• 15-minutes

• Stand-up

• Not for problem solving

• Whole world is invited

• Only team members, ScrumMaster, product owner, can talk

• Helps avoid other unnecessary meetings

Everyone answers 3 questions

• These are not status for the ScrumMaster

• They are commitments in front of peers

What did you do yesterday? 1

What will you do today? 2

Is anything in your way? 3

The sprint review

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or underlying architecture

• Informal

• 2-hour prep time rule

• No slides

• Whole team participates

• Invite the world

Sprint retrospective

• Periodically take a look at what is and is not working

• Typically 15–30 minutes

• Done after every sprint

• Whole team participates

• ScrumMaster

• Product owner

• Team

• Possibly customers and others

Start / Stop / Continue

• Whole team gathers and discusses what they’d like to:

Start doing

Stop doing

Continue doing This is just one of many ways to

do a sprint retrospective.

•Product owner

•ScrumMaster

•Team

Roles

Scrum framework

•Sprint planning

•Sprint review



Activities

•Product backlog

•Sprint backlog

•Burndown charts

Artifacts

Product backlog

• The requirements

• A list of all desired work on the project

• Ideally expressed such that each item has value to the users or customers of the product

• Prioritized by the product owner

• Reprioritized at the start of each sprint

• DEEP-Detailed,Emergent,Estimated,Prioritized

This is the

product backlog

A sample product backlog

Backlog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports

(revenue-per-available-room) 8

Improve exception handling 8

... 30

... 50

The sprint goal

• A short statement of what the work will be focused on

during the sprint

Database

Application

Financial services

Life Sciences

Support features necessary for

population genetics studies.

Support more technical indicators

than company ABC with real-

time, streaming data.

Make the application run on SQL

Server in addition to Oracle.

Managing the sprint backlog

• Individuals sign up for work of their own choosing

• Work is never assigned

• Estimated work remaining is updated daily

• Any team member can add, delete or change the sprint backlog

• Work for the sprint emerges

• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

• Update work remaining as more becomes known

A sprint backlog

Tasks

Code the user interface

Code the middle tier

Test the middle tier

Write online help

Write the foo class

Mon

8

16

8

12

8

Tues

4

12

16

8

Wed Thur

4

11

8

4

Fri

8

8

Add error logging

8

10

16

8

8

A sprint burndown chart

Ho

urs

Scalability

• Typical individual team is 7 ± 2 people

• Scalability comes from teams of teams

• Factors in scaling

• Type of application

• Team size

• Team dispersion

• Project duration

• Scrum has been used on multiple 500+ person

projects

Scaling through the Scrum of scrums

The Procedure or The Ticket Lifecycle using JIRA


Requirements Gathering & Assignment

• The PO (Product Owner) comes up with a “New Feature /

Enhancement / Change Request“ and a PRD (Product Requirement

Description / Document). The PO creates a ticket in JIRA with these

details.

• The ticket is then “Prioritized“ for a “Sprint“ and assigned to a

smaller specific team based on the type of requirement (e.g.: Product,

Technology, Marketing, Operations)

• Grooming: Once “Prioritized“, the PO discusses the Ticket details

and requirements with the team. This is called Grooming

• Requirement Analysis: The Team sits together and analyses the

requirement. It further estimates the ticket in terms of Stories and

Story-points. The requirement is divided into smaller deliverable Story-

points.

• The Story is now divided into smaller Subtasks and assigned to

members of the Dev / QA team.

• Every JIRA Ticket (User Story), in the beginning, is in a state of

“Backlog”.


Development

• Now, after the ticket is assigned to the dev team, the Developer changes

main ticket’s state to “In-Development” while implementing the changes,

and changes the state of the Subtask to “Closed” after Completion.

• After Completion of all subtasks, the Story is “Unit Tested” and “Buddy

Tested” (Tested by another Dev member of team) on the Dev

Environment.

• Following this, the ticket state is set to “Awaiting Review” and assigned to

a Reviewer for Code-Review.

• The Reviewer will code-review the ticket and change the state to “In-

Review”. After the review is completed, he sets the state to “Ready for

QA” (if it is found satisfactory), and “In-Development” if it is not.

• The QA member of the team then changes the state of the ticket to “In-QA

Testsystem”. If any issue is found, he reopens the ticket by changing the

state back to “In-Development” and assigns the ticket to the Developer.

• Again, after resolving the issue, the ticket goes through the review process

and is assigned to QA in “Ready for QA” state.


QA & Test

• The QA changes the ticket state to “In QA – Testsystem”, deploys

and tests the ticket in a QA environment (a dedicated server assigned

for testing purpose only).

• If it passes, changes the state to “Ready for QA – Stage”.

• Also, once the ticket is QA Pass, it has to be integrated with the current

live code. For that, the QA announces on Skype – “INDFAS Releases”

Group chat that the ticket is “Ready for Prepare”

Note:

• If any issue is found, he reopens the ticket by changing the state back

to “In-Development” and assigns the ticket to the Developer.

• Again, after resolving the issue, the ticket goes through the review

process and is assigned to QA in “Ready for QA” state.


Integration Testing

• The Release Manager then creates a new “Prepare” branch from

current live code (also called Current TRUNK). The prepare branch is

a common branch in which all the QA tickets in “Ready for Prepare /

Ready for QA-Stage” state are added / integrated.

• Once Prepare branch is ready, it is deployed to one of the Staging

Test Environments and status of the ticket is set to “In QA – Stage”

• The QA team tests the integrated code using ‘Almost Live Data’ to

ensure complete compatibility on the Staging environment.

• If the ticket succeeds in the final QA Tests, the ticket is marked “Ready

for Release”.


UAT & Go Live • A PO and Automation Team signoff request email is sent to all the

stakeholders and automation team respectively, which lists out: o All the tickets & POs who will give the signoff for Go-Live for the

ticket. o The Team, Developer, QA & respective Automation POC for

different platforms (eg: Desktop, Mobile Web and Mobile Apps) and impact areas

o URL of staging server where the prepare branch is deployed for verification

• The QA team in parallel runs tests to verify each ticket. • The Sysad Manager provides the ideal time slot for the go live based

on website traffic and expected downtime of website during deployment (eg: in case of high impact changes and more than 5 minutes downtime, the release time is kept between 3 AM and 7 AM); and also the name of the sysad POC who will deploy the build to live servers.


UAT & Go Live - continued • Once a Go Ahead is obtained from POs and the automation team, the

QA Team emails “Release Notes” to sysad team (Please refer to glossary for Release Notes definition).

• The Release Manager then verifies the Release Notes for their accuracy and give go ahead for live.

• At the established time, with help from sysad POC, the build is deployed on Live Servers.

• After final tests and verification on Live Environment, the QA changes the ticket status to “Closed”

• The Release Manager now integrates the live “Prepare” branch to current MASTER branch in GIT repository.

Skype – Important Chat Groups & Purpose

• Indfas India : This is the common chat between the Tech Team members and

Sysad Team, for deployment requests to Dev / QA Environments.

• INDFAS Releases : This chat is required for co-ordination with Release

Manager for integration of Tickets with current code.

• INDFAS : This is the common chat between the Tech Team members and

Sysad Team, for deployment requests to Staging & Live Environments.

• QA India Ver 2.0 : This is the common chat between the QA Team members

(for co-ordination of branches going live)

Glossary

• Dev Environment : This is a common server assigned to Development team for

their verification of a ticket before being assigned to QA Team. The Dev Team

can do Unit, Sanity, & Buddy Testing on this environment.

• QA Environment : This is a common server assigned to QA Team members for

their verification of a ticket before going ahead for Integration Testing.

• Staging Environment : This is a common server assigned to QA Team / Tech

Team members for their verification of integrated tickets with Current TRUNK /

Live Code before the changes are sent Live.

• Live Environment : This is the final environment where customers come to

shop on Jabong.

• Prepare Branch : The prepare branch is a common branch in which all the QA

tickets in “Ready for Prepare” state are added / integrated. It is a copy of live

code except for the tickets integrated to it.

• Current TRUNK : It is the current Live Code running on Jabong.com

• Release Notes : This document consists of details of tickets that are ready to go

live. E.g.: Ticket ID, Summary, Developer Name, Tester Name, DB Changes (if

any), Configuration Changes (if any), Pre / Post Release steps (if any), Known

Issues (if any), Sanity Test Cases run, etc. This helps the sysad team to identify

special cases that might need taking care of during Go-Live.

Glossary

• ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizes it benefits.

• Team: A cross-functional group of people responsible for managing itself to develop the product.

• Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.

• Sprint Backlog: A list of tasks to be completed during the sprint.

• Product Backlog: A prioritized list of high level requirements.

• Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of backlog items that the Team has committed to.

• Burn Down Chart: Daily progress for a sprint over the sprint's length.

Thank you

an introduction to scrum -...

Documents