Introduction To Agile Using Scrum

IBM Global Business Services
Introduction to Agile
Using Scrum
1 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Course Objectives
After completion of this course, you would

be able to:
 State in own words a short overview on
Scrum
 Explain Scrum Basics with the aid of Scrum
graphs and templates / document tools
 Describe the activities that occur and the
documents used in a Sprint
 Describe how to estimate and plan a release
in Scrum
 Discuss how to use Scrum in a Multi-
Location Development
 Discuss Scrum and Metrics

Course Agenda
 Module 1: Overview of Agile

 Module 2: Scrum Basics
 Module 3: And the Sprint Begins!
 Module 4: Scrum and Metrics
 Module 5: Release Planning and Estimation in Scrum
 Module 6: Using Scrum for Multi-Location Development

Scrum Master Duration
Day 1
Introduction & Overview 15 min
Module 1: Overview of Agile 45 min
Module 2: Scrum Basic 3 hrs

Exercise 1 – 30 min
Lunch Break
Day 2
Module 2: Scrum Basic - Sprint Planning Meeting 1:10 min

Module 3: Sprint Begins 2 hours
Lunch Break 45 min
Module 3: Sprint Begins 45 min

Module 4: Scrum and Metrics 30 min
Module 5: Release Planning and Estimation in Scrum 30 min
Module 6: Using Scrum for Multi-Location Development 30 min

Module 1: Overview of Agile

Why Agile ?
Software development is to be adopted for new way of working and technology
changes
Multi Platform Collaborative Cloud Intelligent/

Delivery development Deliver Connected Systems
y
Impacts on Business and Software Development
 Demand for Rapid product lifecycles  New skills and competencies needed
 Increasing interactions with customer  Increased security and privacy requirements
 Move to adjacent or new markets  Greater need to align with strategic priorities

What Agile is NOT!

Activity
Challenges with current

Process and Methodologies?

The Agile Manifesto – 2001
We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
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 Framework
Agile Framework
Agile is a conceptual framework for undertaking software

engineering projects
Extreme Dynamic Systems

Scaled Agile Feature
Programming (XP) SCRUM Unified Process Crystal Development Kanban
Framework Driven Dev
Method (DSDM):
•Based on values •Small teams of •Simplified version •Frequent •interactive •3 primary phases: •Develop feature •Incremental,
of simplicity, Delivery knowledge base Pre-Project, list, Plan, Design, Evolutionary
8-12 people of Rational Unified
communication, for implementing Project Life-Cycle , Build by Feature Change
Process – reduced •Reflective agile practices
feedback, •“Backlog” defined improvement Post-Project
courage, at enterprise •Kanban board
requirements that scale help team
and respect will be addressed understand how
in each Sprint •Based on Lean they are doing
•Start with simple
and Agile and also what to
solution, add •Daily 15 min. principles do next
complexity Scrum meeting
through to discuss
refactoring work for the day
Agile Techniques: The above methods involve a range of techniques including:

Test-driven development Continuous integration Static Analysis
Planning game Design improvement Coding standard
Pair Programming Small releases Sustainable pace
Refactoring Simple design Whole team
10

The Waterfall
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Documentation,
Signoffs, Handoff
Advantage: Highly Logical Documentation,

Disadvantage: People are involved Signoffs, Handoff

Empirical Processes
Inputα Outputβ
Process
Inspect & Adapt

Iterative Development
Adaptability
Visibility
Time
All-At-Once Development
Time
All-At-Once Development

Incremental Development
Value
Incremental All-At-Once
Delivery Delivery
Risk / Uncertainty
Time
Incremental
Delivery All-At-Once
Delivery
Time

Agile Foot Prints

Agility is becoming a norm for the development life cycle for companies of all sizes
AP EMEA N America
•Over 73% of the worldwide developer population (11.2 million)

use Agile development techniques
•While Waterfall and V-model design methods remain popular with embedded
systems engineers, they expect their use of Agile to increase.
Agile Foot Prints Contd …

Version one - 2013 survey on agile

Module 2: Scrum Basics

What Is Scrum?
Basics
 In the sport of rugby, a scrum is when the players form up as a tight, integrated pack
 The ball is put into play and the team works to achieve the goal of moving the ball
A Rugby Scrum

What Is Scrum?
 Scrum refers to a holistic or “rugby” approach—where teams goes the distance as

a unit, passing the ball back and forth—as opposed to the traditional sequential or
“relay race” approach for managing new product development

Link
Scrum Project Roles

Product Owner

Product Owner
 Responsible for the overall project vision and goals
 Responsible for managing project ROI vs. risk
 Responsible for taking all inputs into what the team should produce and turns it into a
prioritized list (the Product Backlog)
 Participates actively in Sprint Planning and Sprint Review meetings and is available
for the team throughout the Sprint
 Determines release plan and communicates it to upper management and the
customer

Product Backlog

Product Backlog
Product Owner lists items in descending order of priority (highest priority item is
listed first, next-highest is second, etc.)

User Stories: Components

A User Story describes functionality that will be useful to a stakeholder of the system.
User Stories are comprised of three things
1 2 3
A brief description of
Conversations about Tests that convey
the story used for
the story and document details
planning
4 5
Assumptions Estimating Elements
IBM Customized Additional Elements

User Stories – an example
Success would be…

User Story • Acceptance Test #1
• Acceptance Test #2
As a sys admin at Success would be…

Wal*Mart, I want to WAS is configured
configure WAS so I No critical errors occurred
can manage my in the process
applications No data was lost

Splitting stories into smaller stories
As a user, I want to cancel a

reservation so I am not charged
for a travel arrangement I no
longer need
As a premium site
As a non-premium
member, I want to cancel
member, I want to cancel As a site visitor, I want to
a reservation up to the
up to 24 hours in receive a confirmation
last minute with no
advance so I am not of any cancelled
cancellation fee so I am
charged for a travel reservation so I can have
not charged for a travel
arrangement I no longer proof of cancellations
arrangement I no longer
need
need

Exercise 1 (30 min)
Problem Statement : Write a mobile application where users could select various
facilities provided by Railway reservation system
 Form the Scrum Team

 Identify and define the various User Stories for above problem
 Prioritize the User Stories and create the Product Backlog

Product Backlog – User Stories Estimation

Planning Poker
An iterative approach to estimating
Steps
Each Customer/
estimator Product Estimators Cards are Discuss
Re-estimate
gets a deck owner reads select cards turned over differences
of cards a story
Each estimator Customer/ Each estimator Cards are Discuss Re-estimate

is given a deck Product owner selects a card turned over so differences until estimates
of cards, each reads a story that’s his or her all can see (especially converge
card has a valid and it’s estimate them outliers)
estimate written discussed
on it briefly
© Mountain Goat Software, LLC

Exercise 2 (20 min)
Estimate the Story Points for various User Stories identified in the previous
exercise using Planning Poker

The Team

The Team
 7 people, + or – 2
– Can be shared with other teams (but it is better when not)
– Can change between Sprints (but better when they don’t)
– Can be distributed (but better when collocated)
 Cross-functional
– Possesses all the skills necessary to produce an increment of potentially shippable
product
– Team takes on tasks based on skills, not just official “role”
 Self-managing
– Team manages itself to achieve the Sprint commitment

Exercise 3 (15 min)
Self Organizing Team

 The goal of the game is to walk around the room, taking as many steps as
possible in two minutes.

The Sprint
 Sprint Length
– 2-3 weeks is standard
 Factors in deciding your Sprint length
– Duration of the project
– Customers/stakeholders
 How often can they provide feedback and guidance
 Scrum familiarity
 Environmental factors like regulatory
– The Scrum team
 Scrum experience
 Technical capabilities (such as automated acceptance testing, TDD, automated
releases, etc.)
 Team and Product Owner work together to decide Sprint length

The Role of the Scrum Master

What the Scrum Master Does

 Serves the team
– The Scrum Master takes action to help remove impediments to the team’s effectiveness
– The Scrum Master facilitates the team’s group interactions to help the team achieve its full
potential
 Protects the team

– The ScrumMaster protects the team from anything that threatens its effectiveness, such as
outside interference or disruption
– The ScrumMaster will need to confront uncomfortable issues, both inside and outside the
team
 Guiding the team’s use of Scrum
 The ScrumMaster teaches Scrum to the team and organization

– The ScrumMaster ensures that all standard Scrum rules and practices are followed
– The ScrumMaster organizes all Scrum-related practices

What Does the Scrum Master NOT Do?
 The Scrum Master does not manage the team

 The Scrum Master does not direct team-members
 The Scrum Master does not assign tasks
 The Scrum Master does not “drive the team” to hit its goals
 The Scrum Master does not make decisions for the team
 The Scrum Master does not overrule team-members
 The Scrum Master does not direct product strategy, decide
technical issues, etc.

Scrum Project Roles

Sprint Planning Meeting

Sprint Pre-Planning Meeting

 Scheduled to determine user stories for next Sprint
 Takes place few days before the end of a Sprint (and start of the next Sprint)
 Activities during pre-planning meeting
– Backlog Grooming
 Re-prioritize the backlog if required
 Any User Stories that are no longer relevant to be removed
– Product Owner walks the team through the items at the top of the Product Backlog
– Team asks questions and requests clarification to gain clarity on the potential user
stories
– Team identifies any User Stories that will not fit into the Sprint
– Team ensures Acceptance Criteria is defined for all user stories being considered

Sprint Planning
What’s on the Product
 Team understands details of what Product Owner has Owner’s “shopping list”?
prioritized on Product Backlog
How much “money” do we

 Team decides how much productive time it has available
have in our bank account?
during the Sprint
 Team decides how many Product Backlog items it can How many items on the
commit to complete during Sprint shopping list can we afford to
“buy” with that “money”?

Sprint Cycle: 2-Week Sprint

Mon Tues Weds Thurs Fri
1 2 3
1-Hr Pre-
5 6 7 8 Sprint Review
Meeting for
& Retrospective
Next Sprint
6 7 8 9 10
Sprint
Planning 1 2 3 4
Meeting
13 14 15 16 17
1-Hr Pre-
5 6 7 for
Meeting 8 Sprint Review
Next Sprint & Retrospective
20 21 22 23 24
Sprint
Planning 1 2 3 4
Meeting
27 28 30 31
1-Hr Pre-
29
5 6 Meeting7 for 8 Sprint Review

Next Sprint & Retrospective

Defining “Done”
 In Scrum, “Done” is defined as “Potentially Shippable”
RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE
SPRINT SPRINT SPRINT SPRINT SPRINT SPRINT
RELEASE
SPRINT SPRINT SPRINT SPRINT S P R I N T PRE-RELEASE

SPRINT
 How many teams are able to achieve

potentially shippable from Sprint 1?

The Sprint Backlog

Day of Sprint
Backlog Initial
Task Owner 1 2 3 4 5 6
Item Est.
Design business logic Sanjay 4
Design user interface Jing 2
Implement back-end
Tracy 2
code
Enable all users
Implement front-end
to place book in Tracy 6
code
shopping cart
Complete
Joe 8
documentation
Unit testing Philip 4
Regression testing Philip 2
Implement back-end
Tracy 5
code
Upgrade
transaction Complete
Joe 6
processing documentation
module Unit testing Philip 3
Regression testing Philip 3
Total 214
Available Time During Sprint
Sprint Length 2 weeks
Workdays During Sprint 8 days
Avail Days During Total Avail Hrs in

Team Member Avail Hours Per Day
Sprint* Sprint
Tracy 8 4 32 28 25
Sanjay 7 5 35 31
Phillip 8 3 24
Jing 5 5 25
*Net of holidays and other

days out of the office
Exercise 4 (40 min)
 Identify one User Story from previous exercise

 Define “Definition of Done” for the User Story
 Create WBS ( Each task should not exceed 6 hours)
 Use Poker planning for estimation

Module 3: And the

Sprint Begins!

The Sprint

Daily Scrum Meeting

Daily Scrum Meeting

 Every weekday
 Whole team attends
 Everyone stands
 Lasts 15 minutes or less
 Everyone reports 3 things only to each
other
– What was I able to accomplish since
last meeting?
– What will I try to accomplish by next
meeting?
– What is blocking me?
 No discussions or conversations until
meeting ends
 Product Owner can attend and report
 Update of artifacts after standup
 Following the Scrum meeting, team
updates the Product Backlog and Scrum
Master updates the Burndown Chart

Updating the Sprint Backlog

Day of Sprint
Backlog Item Task Owner Initial Est. 1 2 3 4 5 6
Design business logic Sanjay 4 2 0
Design user interface Jing 2 2 2
Implement back-end code Tracy 2 4 2
Enable all users to

place book in Implement front-end code Tracy 6 6 6
shopping cart
Complete documentation Joe 8 6 6
Unit testing Philip 4 3 3
Regression testing Philip 2 2 2
Implement back-end code Tracy 5 10 8
Upgrade
transaction Complete documentation Joe 6 6 6
processing module
Unit testing Philip 3 3 3
Regression testing Philip 3 2 2
Total 214 220 205

Burndown Chart

Task Board
TO DO IN PROGRESS DONE

Task Board
Task: Configure database Task: Configure database Task: Configure database Task: Configure database
and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs 4 hrs
Task: Configure database Task: Configure database Task: Configure database

and SpaceIDs for Trac and SpaceIDs for Trac and SpaceIDs for Trac
Owner: Sanjay Owner:` Sanjay Owner: Sanjay

Time Remaining: Time Remaining: Time Remaining:
4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner:` Sanjay Owner: Sanjay Owner: Sanjay


Owner: Sanjay Owner: Sanjay Owner: Sanjay

4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner: Sanjay Owner:` Sanjay



4 hrs 4 hrs 4 hrs



Owner: Sanjay Owner: Sanjay Owner:` Sanjay

4 hrs 4 hrs 4 hrs
Owner: Sanjay Owner: Sanjay Owner:` Sanjay Owner: Sanjay


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Task Board



4 hrs 4 hrs 4 hrs



4 hrs 4 hrs 4 hrs




4 hrs 4 hrs 4 hrs


Getting To “Done” – Not a Good Way
DESIGN CODE TEST
SPRINT

Getting To “Done” – A Good Way
DESIGN CODE TEST
SPRINT

Developer’s Day
 You are the owner and accountable for the task
 Work on one task at a time
Start Planning
 Cross functional
for the day
 Refactoring
 Unit testing all scenarios
 Reviews Is it time
 Check in at-least twice a day
Need new task Pick up a task for scrum
Attend
Update task board meeting Scrum Meeting
 Raise an alarm, if stuck on an activity for an hour
Yes End of NO
Go Home
the Day
Peacefully
Write Unit
Work on existing task
test case
Yes
Write-
Is CI NO Fix
Refactor-
Successful build
Review
code
Check-in Local Build

Successful

Technical Best Practices For Teams
 Test-driven development
 Automated builds and continuous
integration
 Collective code ownership
 Continuous refactoring
 Frequent design and code reviews
 Highly collaborative team processes
 High customer contact and max
transparency
 Automated acceptance and regression
tests

Development and Test Flow

Daily Tests Nightly Tests
Developer
Check in
Version Regression
Dashboard Control
Ping and pull code/test
CI
Compile
Run UT,MT
performance
Inform the result
Run Dependent
Run Smoke test test
Test Env
Test Env Run Stability
Inform the result Epic
Run Smoke
Tests

No Changes During Sprint

No changes during Sprint
 Once team has committed, no changes

 No Changes to Deliverable
– Once team has committed, there are no changes in the deliverable
– If something major comes up, Product Owner can terminate the Sprint and start a new
one
– Details and clarifications will emerge during Sprint, but no new work or substantially
changed work
 No Changes to Sprint Duration
– Sprint ends on planned date whether team has completed its commitment or not
 Product Owner can make any changes to the remaining Product Backlog before the start
of the next Sprint

Impact of Change
What happens if the Product Owner gets to add just a small amount of work, or
swap work in and out during the Sprint?
What if the Team is Responsible for “Emergency Response”

(P1 Bugs, etc.)?
 This is not a Scrum standard!

– Proceed at your own risk
 Following approach some teams
use
– “Designated Responder”

Designated Responder
“Scrum Work” “P1 Bugs”

(items from the (emergency
product backlog that requests that needs
the team has to be responded to
committed to do) immediately)
Scrum Team D. R.
“Product Backlog work” “P1 Bugs”
(items from the product (emergency requests
backlog that the team has that needs to be
committed to do) responded to quickly)

Exercise 5 (30 min)
 Create tasks using post it

 Scrum meeting
 Execution of tasks
 Scrum meeting
 Update the sprint backlog
 Create the burndown chart
 Note: Use post it

Sprint Review

Sprint Review
 Purpose of the Sprint Review is

– Demo what the team has built
– Generate feedback which the Product Owner can incorporate in the Product
Backlog
 Attended by Team, Product Owner, ScrumMaster, functional managers, and
any other stakeholders
 A demo of what’s been built and not a presentation about what’s been built
– No Power Points allowed!
 Usually lasts 1-2 hours
 Followed by Sprint Retrospective

Sprint Retrospective

Sprint Retrospective aka Review and Improve
 What is it?
– 1-2 hour meeting following each Sprint Demo
– Attended by Product Owner, Team and ScrumMaster
– Usually a neutral person will be invited in to facilitate
– Presents what’s working and what could work better
 Why does the Retrospective matter?
– Accelerates visibility
– Accelerates action to improve

Sprint Retrospective Contd ..
 Retrospectives
– Steps
 Set the stage
 Gather data
 Generate Insight
 Decide what to do
 Close the Retropective
- Plus / Delta
- Helped, Hindered and Hypothesis
- Return on Time Invested (ROTI)
- Appreciations

Sprint Retrospective Contd ..

 Retrospectives
– Steps
 Set the stage
 Gather data
- Timeline – Helps participants think about project from time based perspective – Good, Problematic, Significant
- Triple nickels – Top five ideas are elaborated by five groups five times – Five issues that occur during iteration
- Color code dots – Group based affinity clustering technique
- Mad, sad, glad – Explores emotive elements of project
- Locate strengths – Participants look for what went well
- Satisfaction histogram – Participants review what their feeling were throughout the project
- Team radar – Multi-disciplines assessment tool
- Like to like – Strength diagnostic tool
 Generate Insight
- Brainstorming – Free for all, Round robin, Quiet time
- Five whys
- Fishbone
- Prioritize with dots
- Identify themes
 Decide what to do
- Short subjects
- SMART goals
- Retrospective planning games
- Circle of questions

Four Square Method

Sprint Retrospective – A Good Approach
At the end of the meeting, mark each item

on the What’s Working / What Could
Work Better lists as either:
C = caused by Scrum (would not be happening
without Scrum)
E = exposed by Scrum (would be there even if
team were not using Scrum)
U = unrelated to Scrum (like the weather)
– Then, add up the C, E, and U in each
column

Exercise 6 (15 min)
 Prepare the points for the review ( team)

 Retrospective
 Note: Use post it

Module 4: Scrum and

Metrics

Principles of Agile Metrics
 Affirms and reinforces Lean and Agile principles

 Measures outcome, not output
 Follows trends, not numbers
 Don't produce metrics that no one wants
 Don't introduce metrics that require significant work to produce.
 Provides feedback on a frequent and regular basis
 Be honest about how management uses metrics. Don't use metrics to
compare teams or individuals
 Take team maturity into account when selecting metrics
 Use metrics as a basis for discussion, not as a final decision point

Reflections: Deployment Evaluation Framework

 Teams adopt only few Agile practices and expect 100% benefits. This
measure provides inputs on the extent of usage of Agile practices

Agile – Metrics @IBM

Following Metrics have been identified for Agile Projects, based on recommendations from AgileatIBM.
Projects will submit Agile Metrics as an Attachment to SWE Sheet

Name of Metric What does it Indicate Mandatory/Optional

Defects per user story Quality of Deliverable Mandatory
This will measure our
Number of times code checked in Continuous Integration (CI) Optional
% of CI Build failures CI build quality Mandatory

Automated Code Review errors, warnings /sprint or per build Static Code Analysis Mandatory
Team's progress during the
Burndown , Burnup chart sprint Mandatory
Team efficiency , E = Velocity/Number of Person Days worked Teams Productivity Mandatory
Pair programming – number of task done with static/dynamic pair
programming Optional
Effective WBS during sprint
Number of new tasks added/removed during the sprint Planning Optional
Availibility of Product Owner – How long it took for the queries to
be replied Access to product owner Optional
Code Quality and Unit test
Code coverage coerage Mandatory
Time box iteration – change of scope of duration during a sprint Change Management Optional
Effective Team facilitation by
Time taken to solve impediments of the Team members/Team Scrum master Optional

Agile – Metrics @IBM Contd …

Name of Metric What does it Indicate Mandatory/Optional
Number of Open impediments every sprint Optional
If team members are not
Attendance in sprint meetings attending any sprint meeting Only, if required by team
Time taken to resolve defect Defect resolution time Mandatory
Regression above 90% / per sprint Quality of Deliverable Mandatory
Regression above 90% / per Sprint working day Quality of Deliverable Mandatory
% of completed User Stories to % of committed user stories Mandatory
Number of defects closed in a sprint and Number of defects open
in a sprint Mandatory
Number of user stories
complete vs planned over Similar to iteration burn
Release Burn down the sprints down but on release level
how much software an agile

team has declared “done”
compared with how much
the team needs to have
completed if the team is to
deliver all functionality
planned by the project end
date.
Release Progress Index Mandatory
Take feedback after each
sprint from each team
http://w3.tap.ibm.com/w3ki/display/agileatibm/DEF member Mandatory

Module 5: Release Planning

and Estimation in Scrum

5 Levels of Agile Planning

Release Planning

Release planning

Velocity – Based on Historical Data
Team’s Recent Sprints
90 points
120 points
100 points
~105 size points per Sprint

How to Plan a Release in Scrum
 Prioritize the tasks – MoSCoW Principle

 Calculate velocity then apply to the Product Backlog:
Team’s velocity is
~105 points per
Sprint
This is 620 points
Therefore, in 6 of Product Backlog
Sprints, the team
should be able to
complete 6 x 105
= 630 points worth of
Product Backlog

Module 6:
Using Scrum for
Multi-Location Development

Team Space
 Co located Teams
– Caves and Common
– Osmotic Communication
– Tacit Knowledge
 Distributed Teams
– Videoconferencing
– Web based meeting facilitators
– Survey applications
– Instant messaging (IM) and VoIP
– Presence based applications
– Interactive whiteboards
– Collaboration – Jean Tabaka • Keep on track
 Maintain a metaphor • Keep on time
• Keep track of who is on the call
 Apply frequent communications • Keep the decisions flowing
 Intensify facilitation • Keep the answers coming
• Keep it fair
 Collaboration practices for conference calls • Keep it facilitated
• Keep it documented

Scrum of Scrums

Agile Tools Evolving Inventory
Static Code Analyzer FT Load Test

Planning / Collaboration Design SCM
• PMD • RFT • LoadRunner
• JIRA + GreenHopper • RAD • CVS
J2EE • Beam • QTP • JMeter
• Rational Team • SVN
Concert • PurifyPlus • Seleniu • RPT
Dev Env. • VSS
• ScrumWorks m • Batch Scripts
• Eclipse • ClearCase
• • Watir
Mingle • Open STA
• intelliJ CI • soapUI
• Cruise Control Code Audit Defect Mgt
UT Acceptance Test
• Bamboo • CheckStyle • Jira
• JUnit • Cucumber
• Hudson • BugZilla
• NUnit • JBehave
• BuildForge • QC
Code Coverage • SpecFlow
• Apache Ant • RQM
• Corbetura
• Apache Maven
• Emma
• Jcoverage
Life Cycle Management: Rational Team Concert
95 95 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Agile Myths Busted

 Agile is just for “small teams”
 Agile doesn’t apply to regulatory situations
 Agile and CMMI don’t work together
 Most agile teams are doing “greenfield development”
– 78% of the projects are working with Legacy applications
 Most agile teams are co-located
 Agile teams don’t provide up-front estimates
– 36% projects provide High-level estimate based on reasonable guess of experienced
person(s)
 Agile teams just start coding
 Agilists don’t do up-front requirements modeling
 Agilists don’t do up-front architecture
 Agilists don’t write supporting documentation
– Documents like User Manuals, Training material, System overview doc, Operations doc etc
are created

Scrum Advantages
 Accelerate Time to Market

 Early and Continuous Customer Validation
 Greater Visibility into Project Progress
 Early Defect Detection and Prevention
 Risk Reduction and Quality Improvements
 Improve Team Morale

Scrum Disadvantages
 It’s hard!
 Makes all dysfunction visible
– Scrum doesn’t fix anything. The team has to do it
– Feels like things are worse at the beginning
 Bad products will be delivered sooner, and doomed projects will fail faster
 High risk of turnover
– Some people will refuse to stay on a Scrum team
– Some people will refuse to stay if Scrum is abandoned
 Partial adoption may be worse than none at all
 If adoption fails, time will have been wasted, and some people may leave

Agile Community @ IBM

Agile@IBM India
https://w3-connections.ibm.com/communities/service/html/communityview?communityUuid=64ceab0e-e
cc2-48bd-87a1-5fa261340f10&successMessage=label.action.confirm.community.join

Agile Projects @ IBM

Reference documents
 Agile Trainings
https://w3-connections.ibm.com/wikis/home?lang=en#!/wiki/W9d84733e3267_45
65_a7b4_7ff0f9177fa5/page/Trainings
 Agile Books
https://w3-connections.ibm.com/wikis/home?lang=en#!/wiki/W9d84733e3267_45
65_a7b4_7ff0f9177fa5/page/Agile Books
 Agile Survey records
http://www.ambysoft.com/surveys/

Thank You!

Introduction To Agile Using Scrum

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Agile Using Scrum

Uploaded by

Copyright:

Available Formats

IBM Global Business Services

1 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

After completion of this course, you would

2 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

 Module 1: Overview of Agile

3 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Scrum Master Duration

Introduction & Overview 15 min

Module 1: Overview of Agile 45 min

Module 2: Scrum Basic 3 hrs

Module 2: Scrum Basic - Sprint Planning Meeting 1:10 min

Module 3: Sprint Begins 45 min

Module 4: Scrum and Metrics 30 min

Module 5: Release Planning and Estimation in Scrum 30 min

Module 6: Using Scrum for Multi-Location Development 30 min

4 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Module 1: Overview of Agile

5 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Multi Platform Collaborative Cloud Intelligent/

Impacts on Business and Software Development

6 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

What Agile is NOT!

7 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Challenges with current

8 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

The Agile Manifesto – 2001

We are uncovering better ways of developing

Individuals and interactions over processes and tools

That is, while there is value in the items on

9 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Agile is a conceptual framework for undertaking software

Extreme Dynamic Systems

Agile Techniques: The above methods involve a range of techniques including:

Planning game Design improvement Coding standard

Pair Programming Small releases Sustainable pace

Refactoring Simple design Whole team

10 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Advantage: Highly Logical Documentation,

11 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Inspect & Adapt

12 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

13 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

14 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Agile Foot Prints

•Over 73% of the worldwide developer population (11.2 million)

Agile Foot Prints Contd …

16 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

Module 2: Scrum Basics

17 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

18 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

 Scrum refers to a holistic or “rugby” approach—where teams goes the distance as

19 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

20 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

21 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

22 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

23 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

24 Introduction to Scrum | 2013 © Copyright IBM Corporation 2013

User Stories: Components

User Stories are comprised of three things

Assumptions Estimating Elements

IBM Customized Additional Elements

User Stories – an example

Success would be…