Agile Software Development: Education, Training and Assessment We Enable You To Leverage Knowledge Anytime, Anywhere!

Agile Software Development
Education, Training and Assessment

We enable you to leverage knowledge anytime, anywhere!
2
Copyright Guideline
© 2015-2016 Infosys Limited, Bangalore, India. All Rights Reserved.
Infosys believes the information in this document is accurate as of its publication date; such
information is subject to change without notice. Infosys acknowledges the proprietary rights of
other companies to the trademarks, product names and such other intellectual property rights
mentioned in this document. Except as expressly permitted, neither this documentation nor
any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by
any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the
prior permission of Infosys Limited and/ or any named intellectual property rights holders
under this document.
Copyright © 2015-2016, Infosys Limited PUBLIC

7
Learning Objectives
Recognize the Agile manifesto, the principles and its ceremonies
Compare & differentiate between waterfall/conventional approach and Agile
Write user stories using INVEST principles
Perform the Scrum ceremonies, roles and principles of Adapt and Inspect
Perform activities and artifacts involved in sprint planning and execution
Recognize the best practices in scaling and distributed Scrum

4
Topics Covered
• Fundamentals of Agile
• Agile Scrum Framework
• Agile Testing
• Agile Software Design and Development

5
Agile in the industry

Drivers for Agile Adoption Industry statistics
• As per leading industry statistics, Agile
would be mainstream since 2015 and
Innovation Galore 80% of the projects would be in Agile
mode
Have Breakfast or Agile
• A lot of projects are following Agile and
be the breakfast Adoption the number is increasing

6
Challenges
Short Time to Market
Evolving &
Changing Innovation
Requirements
Lack of clarity
on Market &
requirements Challenges Trends

7
Agile Manifesto
Agility prioritizes
Individuals and
interactions Processes and tools
Working Software Comprehensive

documentation
Responding to
change Following a plan
Over
Customer Contract negotiation
Collaboration
Twelve principles of Agile

8
Traditional vs. Agile(1 of 2)

Value to Customer / ROI
Incremental
Delivery
Visibility &
Adaptability Iterative Development
All-At-Once
Delivery
Time
All-At-Once Development Time

9
Traditional vs. Agile(2 of 2)

Cycle times in months/quarters as against weeks
All or none into production
Decision Making and Line of sight effect
Lack of responsiveness
Focus on documentation and signoffs

10
Agile – Flavours
Kanban Scrum Lean
Extreme
FDD
Programming(XP)

11
SCRUM
• “Scrum” is inspired from the team game
–Rugby
• Is a balanced package and is popular
• Statistics from State of Scrum report
• 87% say Scrum improves teams' quality
of work life
• 81% believe certifications improves the
practice
• On average, Scrum is successful 62%
of the time
• 95% will continue to use Scrum
Source: State of Scrum report 2015, published by Scrum Alliance

12
Plan-Produce-Inspect-Adapt (Scrum cycle)

SPRINT
Plan Produce Inspect
Adapt

13
Scrum – Basics
Cross Functional teams
Self Organizing Teams
One sprint is planned at a time
Team decides what and how much should be the delivered in each sprint
Sprint targets are shared, clear and does not change during a sprint
Sprints are time-boxed ie. have a specific duration
Every sprint produces a “potentially shippable increment”
Process and the product is inspected and improved after every sprint
In every sprint , the “Definition of Done” is met

17
Roles
Product Owner Development Team Scrum Master
• Vision & goals • Responsible for the •Who

Process Owner
Who can be a PO? Who can be part of can be a Scrum
• ROI for the work work done •master?
Problem Solver
Dev team?
• Date and scope of • Comprises of 5 – 9 •• Experienced
Protector
• Customer • Architects
release members
• Product Managers • Coders member of the
• Are cross-functional
• Product Marketing • Testers team
& self-organizing
Managers • Business Analysts • Ex-Project Manager
• Program Manager • UI Designers
• Project Manager • Document Writers
• Business Analysts

15
The big picture – Activity view
Creation of Start of
Release Agile Base Infrastructure sprints –
product Estimation
planning orientation architecture setup
backlog 1 to n
Sprint 0 /Initiation

16
Sprint – Details
Inputs from stakeholders
Product Daily Scrum
Backlog Meeting
Grooming
Dev Team Scrum Master
Sprint
Detailed plan 2–4
Product Owner Team decides Review Retrospective
for Sprint weeks
how much to
target
Sprint Planning Potentially

Meeting Sprint Shippable
Backlog Increment
Product
Backlog Sprint Burn-down
chart
Release Burn-
down chart

17
Creation of product backlog - User stories

• Describes the functionality that is valuable to
– User of the system
– Purchaser of the system
• Suggested Format:
As a <type of user>, I want <some goal> so that <some reason>
• Simple means of communicating requirements of customers

• Helps get information as early and as often possible
As a online user who has booked a train ticket, I want to cancel my booking, so
that I can receive refund

18
User stories - Format

• Card
• Confirmation (Acceptance criteria)
• Conversation As a online user who has booked a train ticket, I want
to cancel my booking, so that I can receive refund
Acceptance Criteria:
• Verify that ticket price minus applicable cancellation
fee is refunded to credit card
• Verify that the cancellation fee percentage is as per
the difference between the date of cancellation and
date of travel
• Verify that there is no refund in case of late
Three C’s associated cancellations
with user stories • Verify that confirmation email is sent
• Verify that seat reservation is released

19
INVEST Attributes
Independent
Negotiable
Valuable
INVEST in User Stories
Estimate-able
Developers must understand the attributes of good user stories
Small
Testable
Bill Wake coined the term INVEST. More information in XP123.org

20
Prioritization of stories
• All stories cannot be developed at once, hence prioritization is required
The following table provides the factors and the technique used for prioritization
Prioritization Factors Technique
Feature Urgency MoSCoW

Business Value High value features and low value when feature is
developed
Risks Categorize as High Risk ,Medium Risk, Low Risk of

developing or not developing a certain feature
Dependency Dependent item cannot be developed later than the

depending item

21
Sprint – Details
Inputs from stakeholders
Product Daily Scrum
Backlog Meeting
Grooming
Dev Team Scrum Master
Sprint
Detailed plan 2–4
Product Owner Team decides Review Retrospective
for Sprint weeks
how much to
target
Sprint Planning Potentially

Meeting Sprint Shippable
Backlog Increment
Product
Backlog Sprint Burn-down
chart
Release Burn-
down chart

22
Artifacts
Product Backlog Sprint Backlog
Owned by the Product Owner Owned by the Development Team
List of items to be developed List of tasks with effort estimation for the stories
chosen for the current sprint
Decided by the product owner with input from stakeholders
Decided by the Development team with
inputs/clarifications from product owner
Items may be written in the form of user stories
Is arrived during the sprint planning meeting
Items are prioritized by the Product Owner
Potentially Shippable Increment

Owned by the Development Team
Working version of the software at the end of the sprint
Reviewed by the Product Owner and stakeholders at the end of the sprint
Can be wireframes, skeleton code proving the design, module that can be deployed etc.

23
The product backlog…

User story # Description
US-01 As a Bank admin, I can register customers for E-Banking (EB) application so that customer
can use e-Banking
US-02 As a Bank admin, I can disable customer accounts from accessing EB application so that
unauthorized access can be verified
US-03 As a Bank customer and user of EB, I can change my password using the e-banking
application so that I can prevent hacking when I detect an unauthorized access or when I
forget the password

24
The sprint backlog…

Effort
estimation in
User story # Description Story points Tasks hours
US-01 As a Bank admin, I can register customers for 5 Design of UI(wireframe) 4
E-Banking (EB) application so that customer
Creation of UI and validations on UI
can use e-Banking facility
fields 6
Back-end design 5
Back-end implementation 5
Business logic implementation 10

Review 3
Rework and refactoring 3
Unit testing 3
Documentation 1
Integration to existing application 4

44 hours

25
Shippable increment
Can be -
• Working version of the software
• Prototypes, skeleton code, algorithms that prove the working
• Designs mapping to specific design patterns that prove the design
Cannot be –
• Documents (SRS,Design documents etc)

The ceremonies...
27
Sprint Planning meeting
Conducted and time-boxed by Scrum master

Dev team arrives at the list of tasks for the chosen stories for the sprint
PO to provide required clarifications

Dev team commits to the tasks
Half a day in a 2-week sprint
Generally done in 2 parts a) Seek clarifications from product owner on the

chosen user stories b) Divide the user stories into tasks and estimate effort

28
Sprint planning
Capacity planning
Sprint goal
Pick requirements and seek clarification if any
Ideal Sprint burndown chart
Commitment to tasks

29
Team capacity planning - Example
Available Days in Available Work Total Hours Available in

Name
the Sprint Hours per Day the Sprint
John 5 6 30
Mathew 9 6 54
Thomas 9 5 45
Mary 9 4 36
Tom 9 6 54
Peter 7 3 21
240
Buffer Time(5-10%) = -20

Product Backlog Grooming (5-10%) = -20
Total Available Work Time in the Sprint = 200

30
Understanding Sprint goal

• Teams would pick up user stories from the product backlog based on priority and
sprint goal
• Seek clarification if any from product owner (facilitator plays the PO role)
• Create the sprint backlog as shown in the following section

31
Sprint backlog creation

Effort
User story Story estimation in
# Description points Tasks hours
US-01 As a Bank admin, I can register 5 Design of UI 5
customers for E-Banking (EB) Validations on UI fields 4
application so that customer can use
Back-end design 6
e-Banking facility
Back-end implementation 5
Business logic implemetation 10

Review 3
Rework and refactoring 3
Unit testing 3
Documentation 1
Integration to existing
application 4
44 hours

32
Sprint burndown chart

Illustrates progress of the No. of hours of work pending
team in terms of
Ideals line shows the number of hours of work to be burnt down
to achieve zero pending on the last day of the sprint
Useful to the development team to make daily course corrections
200
180
Total hours of Work Left

100
Ideal
Line
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Initial Estimate
End of Sprint
Available Time in the Sprint = 200 hours
Allocated Time in the Sprint = 180 hours
If the progress line is above the ideal line, shows that team is lagging and below the
ideal line suggests team is able to complete before time

33
Commitment to tasks
• Team members should commit to tasks
• Could be based on skill set and comfort level in taking up the tasks
• Names may be written against the tasks
• A sample visual board looks as follows:

User story # Not Started In Progress Done
102 ………….10(Tom)
…………….10(Peter)
………10 (Mathew)
Total = 40
mins …………….5(Thomas)
……………5(Marie)

Sprint planning & Execution
35
Sprint Execution
Performing tasks
Daily standup meeting
Update sprint burndown chart
Product backlog grooming
Review
Retrospection

36
Performing tasks
• Team members can move the tasks between the columns of the visual board
102
………….10(Tom)
Total = 40 mins …………….10(Peter)
…………….5(Thomas)
………10 (Mathew)
……………5(Marie)

37
Daily standup / Scrum meeting
Mechanism for the Dev team to update each other on a daily basis
Ensure the constraints/blocks are brought to scrum master and team’s notice
Happens everyday at a pre-decided time for 15 min

Everybody listens and there is no discussion
Conducted by Scrum master with the Dev team
Every team members says the three things –

• What did I do since the last scrum meeting?
• What am I going to do today?
• What is blocking me?

38
Update sprint burndown chart (1 of 2)

n
…..
…..
Total = x mins
Time remaining
….
= Not started + In
Progress
…..

39
Update sprint burndown chart (2 of 2)

200
180
Total Minutes of Work Left
100
Actuals
Day Day Day Day Day Day Day Day Day Day 10
1 2 3 4 5 6 7 8 9
Initial Estimate
End of Sprint

40
Product Backlog grooming
Conducted in every sprint

Looking at upcoming 2-3 sprints worth of product backlog items(sprinting ahead)
Dev team tries to get a detailed understanding of these items through

interactions with PO
Conducted by Scrum master with the Dev team

The product backlog could also be revisited/reprioritized,changes brought in by
the product owner in consultation with the Dev team
5-10% of time in a sprint is spent

41
Review and Retrospective
Conducted at the end of the sprint by the PO and stakeholders

Sprint review
Inspection of the quality of what is produced by the team
Check the “Done-ness” of the items produced (Inspect) and

suggest improvements(adapt)
Sprint Inspect and Adapt the process

retrospective
Share experiences and observations during the sprint(what to start
doing ,stop doing and what to continue doing from next sprint)
Plan for improvements in future sprints

An importance practice in each sprint
42
Sprint Burndown chart – Ideal

200
180
Total mins of Work Left 100
Day Day Day Day Day Day Day Day Day Day 10
1 2 3 4 5 6 7 8 9
Initial Estimate
End of Sprint
Available Time in the Sprint = 200 mins
Allocated Time in the Sprint = 180 mins

46
Sprint Burn Down Chart - Actuals
200
180
Total Minutes of Work

100
Left
Da Da Da Da Da Da Da Da Da Da
y1 y2 y3 y4 y5 y6 y7 y8 y9 y
10
Initial Estimate End of Sprint

44
The big picture – Activity view
Creation of Start of
Release Agile Base Infrastructure sprints –
product Estimation
planning orientation architecture setup
backlog 1 to n
Sprint 0 /Initiation

Sprint 0 / Initiation Phase
46
Estimation of user stories – Story Points

• Used for estimation of user stories
• Units of measure which represent the size of a story
• Are relative and hence easier to estimate
• Create baseline for story point estimation
– Define stories which can represent 1 point, 2 points etc, ex. Login page- 1 story point
• Some factors to be considered while assigning story points to stories
– Size of the story relative to the baseline story(ies) e.g. this story is almost double the
baseline story
– Effort required to develop the story
– Risks involved
• Uses Fibonacci sequence(non-linear series)

47
Poker Planning Estimation Activity - Instructions

Activity Sequence
• Product Owner or representative will read out a story to the entire team
• Product Owner will clarify questions if any
• Each team member privately estimates and chooses a poker card with a
point value
• All team member will simultaneously turn over his/her poker card for all
members to see
• In case of consensus, the story point is recorded against the story.

• If no consensus, the high and low estimators provide explanation and
polling is conducted again
• Continue this process until consensus is reached, up to maximum of three
(3) iterations.
• If no consensus, Scrummaster will decide value.

48
Iteration length
• Iteration/Sprint length – 2 to 4 weeks
• Factors impacting fixing up duration of length
– Longevity of the project/release
– Urgency of releases
– Uncertainties in the project
– Availability of stakeholders and easiness to get their feedback
– Overhead in iterations
– Frequency of priority changes
• Once fixed, sprint duration is not changed during the life cycle of the project

49
Velocity of team
• The number of story points that a team can deliver in iteration is called the “velocity”
• Velocity is determined using one of the following three methods:
– Historical data – same team, same technology and domain
– From actual values – running few sprints
– Guessing velocity from effort – capacity planning
• Assumptions:
• Velocity is specific to a team and hence cannot be baselined or reused
• Velocity cannot be generalized across projects
• Velocity depends on the capabilities of the specific team

50
Estimating release date

• Assumptions
– Estimation of product backlog by the team
– Estimation of velocity (is a forecast not a promise)
• Product Owner estimates the release date

– Divide the total story points for the product backlog by the velocity to get the number of sprints
– Multiply the number of sprints by the sprint duration(in weeks)
– Estimate the release date
• Add Buffer
– Uncertainty (for example: 15%)
– Improvement and rework (for example: 10%)
– Pre-release sprint (to go from potentially shippable to actually “shipped”)

51
Release Burn down Chart
End of Release
Development

52

End of Release
Development
Two Extra sprints will be

needed to deliver the entire
release backlog

53

End of Development Release
To deliver the release on

schedule, remove 15 points
from the product backlog

54
Distributed Scrum
• Features • Challenges
– Product owner not collocated
– Applicable where GDM is practiced
– Stark difference in time zones
– Practices of Scrum remain the same – Communication gaps
– Need to make the scrum practices – Late response to questions asked

work in a distributed fashion – Unfamiliar accents and culture
• Can be addressed by using the practices mentioned under the following categories:
Roles and Ceremonies &

Team structure Tools
Responsibilities Artifacts
Infrastructure Planning

55
Mindset change
Promote working in
collaborative teams
Evolving product - Move from Manager to

abstraction “Servant-Leader” role
Mindset
change Create conducive
Accept changes and environment for
adapt Scrum execution
Promote Communication
Promote concept of
/conversation & self- Done/Not done
organization

59
In Conclusion….
• Inspect and Adapt
• People
• Incremental development
• Working software as a measure of progress
WELCOME CHANGE …..

60
References
Books
“Succeeding with Agile”, Mike Cohn
“Agile Estimation and Planning”, Mike Cohn
“Agile Project Management”, Ken Schwaber
“User stories Applied “,Mike Cohn

Thank You
© 2013 Infosys Limited, Bangalore, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change
without notice. Infosys acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except
as expressly permitted, neither this documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing,
photocopying, recording or otherwise, without the prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.

Agile Software Development: Education, Training and Assessment We Enable You To Leverage Knowledge Anytime, Anywhere!

Uploaded by

Copyright:

Available Formats

Agile Software Development: Education, Training and Assessment We Enable You To Leverage Knowledge Anytime, Anywhere!

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

Agile Software Development: Education, Training and Assessment We Enable You To Leverage Knowledge Anytime, Anywhere!

Uploaded by

Copyright:

Available Formats

Agile Software Development

Education, Training and Assessment

Copyright © 2015-2016, Infosys Limited PUBLIC

Compare & differentiate between waterfall/conventional approach and Agile

Write user stories using INVEST principles

Perform activities and artifacts involved in sprint planning and execution

Recognize the best practices in scaling and distributed Scrum

Copyright © 2015-2016, Infosys Limited PUBLIC

• Agile Scrum Framework

• Agile Software Design and Development

Copyright © 2015-2016, Infosys Limited PUBLIC

Agile in the industry

Copyright © 2015-2016, Infosys Limited PUBLIC

Short Time to Market

Copyright © 2015-2016, Infosys Limited PUBLIC

Working Software Comprehensive

Copyright © 2015-2016, Infosys Limited PUBLIC

Traditional vs. Agile(1 of 2)

All-At-Once Development Time

Copyright © 2015-2016, Infosys Limited PUBLIC

Traditional vs. Agile(2 of 2)

All or none into production

Decision Making and Line of sight effect

Focus on documentation and signoffs

Copyright © 2015-2016, Infosys Limited PUBLIC

Kanban Scrum Lean

Copyright © 2015-2016, Infosys Limited PUBLIC

Copyright © 2015-2016, Infosys Limited PUBLIC

Plan-Produce-Inspect-Adapt (Scrum cycle)

Plan Produce Inspect

Copyright © 2015-2016, Infosys Limited PUBLIC

Self Organizing Teams

One sprint is planned at a time

Sprints are time-boxed ie. have a specific duration

Every sprint produces a “potentially shippable increment”

In every sprint , the “Definition of Done” is met

Copyright © 2015-2016, Infosys Limited PUBLIC

Product Owner Development Team Scrum Master

• Vision & goals • Responsible for the •Who

Copyright © 2015-2016, Infosys Limited PUBLIC

The big picture – Activity view

Copyright © 2015-2016, Infosys Limited PUBLIC

Dev Team Scrum Master

Sprint Planning Potentially

Copyright © 2015-2016, Infosys Limited PUBLIC

Creation of product backlog - User stories

– Purchaser of the system

• Simple means of communicating requirements of customers

Copyright © 2015-2016, Infosys Limited PUBLIC

User stories - Format

Copyright © 2015-2016, Infosys Limited PUBLIC

Bill Wake coined the term INVEST. More information in XP123.org

Copyright © 2015-2016, Infosys Limited PUBLIC

Prioritization Factors Technique

Feature Urgency MoSCoW

Risks Categorize as High Risk ,Medium Risk, Low Risk of

Dependency Dependent item cannot be developed later than the

Copyright © 2015-2016, Infosys Limited PUBLIC

Dev Team Scrum Master