Agile & Scrum- An Introduction

Prepared and Presented by

Rajakrishnan S – MCA,MBA,PMP,CSM,ISTQB(Advanced),ITIL

Purpose of this Session

● To go through the Agile practices

● To go through the Scrum Method

Agenda

● What is Agile and its principles (20 minutes)

● When to use agile

● When to not use agile

● Agile pros and cons

● Scrum (40 minutes)

● Components of Scrum

● Estimation in Scrum

● Requirements Management in Scrum

What is Agile

● Iterative and Incremental development Model

● Time boxed iterative approach

● Encourages rapid and flexible response to change

● Self organizing and cross-functional teams

● Aim to delivery right product, at right price in right time

● Core values include

● Adaptability

● Transparency

● Simplicity

● unity

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

That is, while there is value in the items on the right, we value the

items on the left more.

Agile Manifesto...

● Individuals and Interactions –

- in agile development, self-organization and motivation are important, as are

interactions like co-location and pair programming.

● Working software –

– working software will be more useful and welcome than just presenting

documents to clients in meetings.

● Customer collaboration –

– requirements cannot be fully collected at the beginning of the software

development cycle, therefore continuous customer or stakeholder

involvement is very important.

● Responding to change –

– agile development is focused on quick responses to change and continuous

development.

When to use Agile

● Requirements are not complete

● There are changes in requirements expected

● Quick customer releases with high quality is the objective of the

organization

● Customer collaboration is possible

● When feature development heavily relies on stakeholders feedback

When to not use Agile

● Application users(Stakeholders) are NOT always accessible to you.

● You need to follow traditional software management processes and

procedures.

● Deliverable must pass through a chain of approvals and tollgates

● You have to formally document the requirements, design, code, and

testing cases during each phase of the software life cycle.

● Don’t try agile it you already decided against it :)

Pros and Cons of Agile

● Pros

● Early and frequent delivery of business value hence satisfied

stakeholders/customers

● More flexible than traditional model

● Involvement of QA throughout the process

● More visibility to each team member, increases motivation and

ownership

● More accuracy in estimation, since working in chunks

● Early feedback/acceptance of customer is possible

● Responsive to changes

Pros and Cons of Agile

● Decreases risks by having working software

● Increased control

● Less barriers in communication

● Small releases, easy to manage

● Cons

● Over-hype about agile will lead to lot of unrealistic expectation

● Approach of the people

Some Factors to succeed in

Agile● Dedicated product manager

● Experienced and self organized team

● Automation testing and developer testing

● Attitude towards scrum

● Adaptive to changes

● Readiness to do face-face communication

● Management Support

Various Agile Methods

● SCRUM

● Kanban

● Extreme Programming

● Agile Unified Process

● Feature Driven Development

Some of the major users of Agile

Google

Microsoft

Oracle

Dell

FIFA (Accepted as the official training process)

..

..

..

SCRUM

What is Scrum

● Scrum is an agile approach to Software Development

● Scrum is an iterative and incremental development process

● The project is split into a series of consecutive iterations (sprints)

● Scrum is a framework rather than a full process or methodology

● Scrum relies on self-organizing and cross-functional team

● Scrum teams are supported by Scrum Master and Product Owner.

There is no overall leader

History of Scrum

● Scrum (in rugby) to restart the game in situation when ball has

gone out of play

● 1986- Hirotaka and Ikunjiro described a new approach to product

development that would increase the speed and flexibility. They

called it a rugby approach, where a cross functional team work

together as a unit to reach the distance

● In 1990s: Ken Schwaber and Jeff sutherland used similar approach

and used the term scrum

● 1995: Sutherland and Schwaber presented a paper on scrum

methodology for the first time in Austin, Texas

Scrum Process – A graphical Representation

Team Organisation

Engineering Team(Dev, QA, Architect,

Designer)

PO

SM

Architects, Developers, Testers form the engineering team(scrum team)

Basics components of Scrum

Roles Ceremonies Artifacts

Product Owner

Scrum Master

Engineering Team

Release Planning

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

Backlog Refinement

Product Backlog

Sprint Backlog

Burn down Chart

Sprint (Iteration)

● Scrum Projects make progress in a series of sprints

● Each sprint(Iterations) no more than a month long

● Team members commit to deliver some number of features from

product backlog

● Features are coded, tested and integrated to the product or system

● Sprint Review Meeting is conducted at the end of the sprint and

each team demonstrates the new functionality to product owners

and other interested stakeholders

Product Owner

● Product Owner represents the business, customers and users

● Guides the team towards building the product.

● He is often someone from Product Management or Marketing, a

key stakeholder or a user

Scrum Master

● Scrum Master can be thought of as a coach/facilitator for the team

● The Scrum Master is responsible for making sure the team is as

productive as possible

● Helps team to use the scrum framework to perform at their highest

level

Scrum Team(Engineering Team)

● “We are all in this together”

● Scrum doesn’t include any of the traditional software engineering

roles such as programmer, designer,tester, or architect

● A typical scrum team is 6-10 in size

Product Backlog

● It’s a prioritized master list of all features(called stories) desired in

the product

● The Product Backlog is allowed to grow and change as more is

learned about the product and its customers.

● Product owner owns the product backlog

User Stories

● Requirements are captured in scrum as user stories

● A user story is a tool used in Agile software development to capture a description of

a software feature from an end-user perspective. The user story describes the type

of user, what they want and why. A user story helps to create a simplified

description of a requirement

● User Stories are pointers, and the details of stories can be provided in any

format(like requirement documents, wireframes etc..)

● Format :As a <type of user>, I want <some goal> so that <some reason>.

● Example: As a power user, I can specify files or folders to backup based on file size,

date created and date modified.

●

Sprint Backlog● It’s the list of tasks that the Scrum team is committing for the

current sprint

● Items are selected from product backlog based on the priority set by product owners and the perception on the team

● It can be maintained in an excel sheet or in tools like JIRA Agile, TFS, scrumworks, version1 etc.

● Each product backlog items selected for the current sprint will be added by expanding those with tasks and estimating hours

● The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burn down chart

Sample Sprint Backlog

Sample Burn down Chart

Sprint Planning Meeting

● The meeting to plan the items to be delivered in the sprint

● Attended by Product Owner, Scrum Master, the entire scrum team,

Any other interested management or customer representatives

● Product owner describes Objective of the sprint and the highest

priority stories to the team

● 4 hours time limit for a 2 week sprint

Daily Scrum Meeting

● The team hold a daily stand up meeting.

● Typically held in the same location and same time

● Team members who has committed to tasks will only talk

● Its not a problem-solving or issue resolution meeting

● Issues raised are taken offline and usually dealt with by the relevant

subgroup immediately after the daily scrum

Daily Scrum Meeting...

● During the scrum each team members provides answer to the

following questions

● What did you do yesterday?

● What will you do today?

● Are there any impediments in your way?

● 15 Minutes time limit for each team

● This is not a status update meeting in which boss is collecting

information about who is behind schedule

● It’s a meeting in which team members make commitments to each

other

Daily Scrum Meeting-

Role of a scrum master● Its scrum master’s responsibility to resolve the impediments raised

in the meeting

● If scrum master cannot resolve it directly(technical issues), he

should make sure that someone in the team does quickly resolve

the issue, by taking the responsibility.

Daily Scrum Meeting-

Sample Impediments● My ____ broke and I need a new one today.

● I need help debugging a problem with ______.

● I'm struggling to learn ______ and would like to pair with someone

on it.

● The department head has asked me to work on something else "for

a day or two."

● The environment is not ready to test

● The delivery of the item is getting delayed from ‘X’

Sprint Review Meeting(Exit Demo)

● Sprint Review Meeting is held at the end of each sprint

● Scrum teams shows what they have accomplished (Demo of new

features)

● Its very informal with rules avoiding the use of power point slides

and allowing no more than 2 hours of preparation time for the

meeting

● Sprint review meeting should be a natural result of the sprint

Sprint Review Meeting…

● Participants

● Product Owner

● The Scrum team

● Scrum Master

● Management

● Customers

● and Developers from other projects

● Project is assessed against the sprint goal determined during the

planning meeting

● Its important that team achieve the goal of the sprint

● 2 hours is the limit for a 2 weeks sprint

Sprint Retrospective

● All team members reflect on the past sprint

● Make continuous process improvements

● Main questions asked in the sprint retrospective are:

● What went right during the sprint

● What went wrong during the sprint?

● What could be improved in the next sprint?

● 1 hour is the time limit

Daily Scrum Meetings – Best Practices

● Stand up means stand up, no sitting, really

● Keep it short. 15 minutes max.

● Stand in front of the visual progress artifact

● Everybody should be present.

● No typing

● Concentrate on the second and third question, not on the first one.

● If team talks too much to Scrum Master, let him not too look at the team.

.

Requirements in Agile-Scrum

● Requirements are captured in the form of user stories

● User story has the following format

● As a <Actor>, I want to <Do this>, So I can <get this>

● Example: As a User, I want to log in, So I can access subscriber

content

● These user stories will be elaborated by the team along with the

product owner(customer representative)

Estimation in Agile-Scrum

● There are different estimation techniques in Agile-Scrum

● Planning Poker(Fibonacci Series-1,2,3,5,8,13,21)

● Power of 2(2,4,8..)

● T-shirt sizing (X-Small, Small, Medium, Large, X-Large)

Definition of Done

● Self review of code should be completed with the help of automated tools

● Code/Config should be reviewed

● Unit testing with coverage of 80% and above

● Developer Sanity testing(All Acceptance cases) should be completed in Dev env.

● Story Level Functional Test cases should be reviewed

● Test execution should be completed in QA environment

● All defects are closed

● Acceptance criteria should be met

● Demo to the Product Owner

● Signoff from Product Owner

● All tasks related to the story should be closed in optimus

● Deployment instructions are documented

Measuring Agility

● Velocity of the team can be used to measure the agility

● Velocity tells how much the team can delivery

● Velocity is calculated as an average

● Example of Velocity: 40 story points per sprint by the 5 member

team

Some Best Practices

● Early demo to PO

● Design(specially UI) can be demoed to the PO to get an early

feedback by the developer

● Once feature is developed in developer environment, a demo

can be done to the PO

● Test Scenarios/Cases can be reviewed by PO and peer

developer

● Buddy Testing

● Tester work with developer to validate the story in developer

environment prior to deploy in QA env.

For Further Reference

● http://www.agilealliance.org/

● Http://www.wikipedia.org

● http://agilemanifesto.org/

● http://www.agilemanifesto.org/principles.html

Q&A

Thank You