1

Agile Software Development

Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams.

It promotes adaptive planning, evolutionary development, frequent and early delivery, continuous improvement, and encourages rapid and flexible response to change with iterative and incremental approach.

2

Agile Manifesto

Individuals and Interactions

Processes and Tools

Working SoftwareComprehensive Documentation

Customer Collaboration Contract Negotiation

Responding to Change Following a Plan

Over

Over

Over

Over

3

Agile Principles• Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.• Welcome changing requirements, even late in development.

Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

4

Agile Principles• The most efficient and effective method of conveying

information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.• Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

5

Agile Principles• The best architectures, requirements, and designs emerge

from self-organizing teams.• At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behaviour accordingly.

6

Why Agile

• Accelerate Time To Market• Early and Continuous Delivery• Frequent Customer Feedback• Greater Visibility into Project Progress• Early Defect Detection and Prevention• Risk Reduction and Quality Improvements• Improve Team Morale

7

Waterfall Vs Agile

8

Development in AgileAgileAgile uses interdisciplinary teams in iterative cycle, reduces waste and increases productivity 1-4 Weeks Sprint(s)

Agile Release Planning

Code

Analysis

Test

Design Code

Analysis

Test

Design

9

Various Agile Methods

10

What is Scrum• Scrum is a process framework structured to support complex product

development.

• Scrum consists of Scrum Teams and their associated roles, events, artifacts and rules.

• Scrum is performed by cross-functional teams over multiple overlapping phases (such as, analysis, design, code, test, etc.)

• NOT a software engineering practices, supportive to agile manifesto and principles.

• Scalable to distributed and large teams

11

Why Scrum is the most successful• Scrum is improved process framework in Agile Methodology where complex project can be

developed in complex environment.

• Scrum is lightweight process.

• Scrum follows three pillars of “Empirical Process” in perfect manner :» Inspection» Adaption» Transparency

• Scrum follows guidelines/rules and roles/responsibilities strictly to execute the program.

• Scrum can manage larger distributed teams in collaborative manner and build self-managing team

• Scrum build trust between team members.

• Scrum is event-driven process, so visibility is higher between the team members.

• Scrum is timebox-driven, so the team members are disciplined.

12

Scrum Terms• Product Backlog (subset of Product Backlog is “Release Backlog”)

– The Product Backlog is the requirements for a system, expressed as a prioritized list of Product Backlog Items (PBI). Owner : Product Owner

• Product / Release Burndown Chart– In Scrum, the product/release burn down chart is a “big picture” view

of a project’s success. It shows how much work was left to do at the beginning of each sprint. Release Burndown is updated at every sprint.

• The Sprint – “A time-box iteration of work during which an increment of product functionality is implemented. Sprint Length can vary between 1-4 Weeks. Maximum sprint length is 1 Calendar Month (or 30 Calendar Days)

• Sprint Backlog – Defines the work for a sprint , represented by the tasks associated with each PBIs committed to deliver by the team for the current sprint as in terms of their sprint goal. Owner : Team

• Sprint Burndown Chart – A sprint burndown chart depicts the total task hours remaining per day. Sprint Burndown Chart is updated on a daily basis by team.

13

Sprint 0The activities of Inception Phase (Pre-Starting Sprint Cycle Phase):

Develop Product Vision

Create Product Roadmap

Have common product vision with stakeholders agreement

Set Up Product Backlog with Defined Scope

Set Up Standard Architecture

Initial Release Planning

Form Initial Team and Educate Them for Agile Way Working

Set Up Work Environment

14

Scrum Process

15

Scrum Flow– Sprint Cycle

16

Timebox Events

Events/Meetings/ Ceremonies

Maximum Duration For 4-Weeks Sprint

Maximum Duration For 2-Weeks Sprint

Maximum Duration For 1-Week Sprint

Release Planning Not Defined Not Defined Not Defined

Sprint Planning 8 Hours 4 Hours 2 Hours

Daily Scrum 15 Minutes 15 Minutes 15 Minutes

Sprint Review 4 Hours 2 Hours 2 Hours

Sprint Retrospective 3 Hours 1.5 Hours 1.5 Hours

Backlog Refinement Reserves 5-10% of entire teams time during every sprint

17

Sprint Abnormal Termination

• Product Owner can ONLY cancel the sprint. Team may request to cancel.

• The reasons for cancellation of sprint :– Sprint Goal becomes obsolete.– Sprint Goal seems to be impossible to achieve.

18

Scrum Roles• Product Owner (PO)

– Accountable for product success – Defines all product features – Responsible for prioritizing the product features– Owns and Maintains the Product Backlog – Ensures team working on highest valued features– Accept/Reject the development work results– Responsible for Product Refinement Meeting– Responsible for maximizing ROI and increasing value of the product for

the customer– Decides Release Dates and to release working product into production

when there is a value to customer

19

Scrum Roles

• Scrum Master (SM)

– Make sure daily 15 minutes Daily Scrum Meeting happens– Remove impediments/roadblocks– Facilitating team decision and ensuring that team is

delivering value– Shields the team from external interference – Facilitate Scrum Ceremonies– Is a facilitator, not a manager– Servant Leader to Team, and to PO.

20

Scrum Roles

• What Scrum Master (SM) Should NOT Do

– Manage the team– Direct the team members– Assign Tasks– “Drive” the team– Make the decisions on behalf of team– Overrule the team members– Direct product strategy

21

Scrum Roles

• Development Team

– Team consists 3-9 People– Self-organizing, cross-functional team– Owns and maintains Sprint Backlog– Splits each PBIs into tasks breakout in the Sprint

Planning Meeting and estimates in hours– Responsible to manage themselves to achieve the

sprint goal

22

Scrum Roles @ High Level

• Scrum Master3Ps

– Problem Solver (Remove Impediments)– Process Owner (Educate Team/PO about Scrum Rules, Practices and Guidelines)– Protector (Shields Team from external interfaces)

• Product Owner Value Maximizer (Establish Product Vision, Prioritize Business Features and Maximize the value of

development work)

• Development Team Self-Organizer (Self-Managing, Self-Awareness and Volunteers their own task independently) Cross-functional (Multi-skilled team, Skills overlapping, crossing the boundary)

23

Scrum Artifacts

• Product Backlog (PB)

– List of all desired and prioritized product features, called ‘Product Backlog Items (PBIs)’; items are prioritized based on business value, risks and dependencies.

– List can contain features, bugs, improvements, technical requirements etc.

– Each item should have a business value assigned– Maintain by the Product Owner

24

Sample Product Backlog

User Story Card : As a <user>, I want to do <function>, so that <desired result>

ID Title Short Description Priority Business Value Story Points Status

RBS_US01

Daily maximum intraday liquidity stage

As a supervisor, I want to monitor a bank's intraday liquidity usage in normal conditions, so that I can make available the sufficient fund in the bank 1 High 8 Done

RBS_US02

Available Intraday liquidity at the start of the business day

As a supervisor, I want to monitor the amount of intraday liquidity a bank has available at the start of each business day, so that I can maintain the meeting its intraday liquidity requirements at normal conditions 1 High 8 Done

RBS_US03 Total Payments

As a supervisor, I want to monitor the overall scale of bank's activity, so that I can have clear visibility of payment records for each section 2 Medium 13 In-Progress

RBS_US04Time-specific obligations

As a supervisor, I want to gain better understanding of a time-specific obligation, so that I can clearly find out the settlement which fails to meet such obligations for financial penalty, reputational damage to the bank or loss of future business. 3 Low 20 To-Do

RBS_BUG01

Form labels are NOT properly aligned

Some of the form labels are center aligned, all of the form labels should be left-aligned. 3 Low 3 To-Do

25

Scrum Artifacts

• Sprint Backlog (SB)

– To-do list from PBIs for the sprint– Created by the Scrum Team – Selected product backlog items as per the priority

defined by PO.

26

Sample Sprint Backlog

ID Title Task Description Effort Estimation (In Hours)

RBS_US01

Daily maximum intraday liquidity stage

User Interface Design 8

Database Design 12

Coding 20

Code Review 10

Unit Testing 15

Automated Testing 15

Total Effort 80

27

Scrum Artifacts

• Burn down Chart

– Chart showing how much work remaining in a sprint

– Calculated in hours remaining– Maintained in daily basis by team

28

Sprint 1 Planning Meeting

Sprint Length : 4 Weeks

Sprint Start Date :

Sprint End Date:

Story TasksStart Hours

Hours Spent - Day 1

Hours Spent - Day 2

Hours Spent - Day 3

Hours Spent - Day 4

Hours Spent - Days 5

Hours Spent - Days 6

Hours Spent - Days 7

Hours Spent - Days 8

Hours Spent - Days 9

Hours Spent - Days 10

Hours Spent - Days 11

Hours Spent - Days 12

Hours Spent - Days 13

Hours Spent - Days 14

Hours Spent - Days 15

Hours Spent - Days 16

Hours Spent - Days 17

Hours Spent - Days 18

Hours Spent - Days 19

Hours Spent - Days 20

Total Hours

RBS_US01

Task1 20 0 0 0 0 2 2 2 0 2 0 0 2 0 2 2 2 2 2 0 0 20

Task2 40 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 40

Task3 32 3 1 0 2 0 0 1 3 0 2 2 2 2 2 2 2 2 2 2 2 32

Task4 20 2 0 2 2 2 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 20

Task5 30 1 3 1 2 2 2 1 0 0 0 0 0 0 6 2 2 2 2 2 2 30

Task6 14 2 2 1 8 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14

RBS_US02

Task1 6 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6

Task2 8 1 3 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 8

Task3 10 0 0 5 0 3 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 10

Actual Remaining Hours 180 167 155 143 126 111 105 99 94 90 86 82 76 72 60 50 38 28 18 8 0

Estimated Remaining Hours 180 171 162 153 144 135 126 117 108 99 90 81 72 63 54 45 36 27 18 9 0

Sample Data for Sprint Backlog Tasks

29

Sample Sprint Burn-down Chart

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 200

20

40

60

80

100

120

140

160

180

200

Sprint Burndown Chart

Actual Remaining Hours Estimated Remaining Hours

Sprint - Days

Rem

aini

ng W

orki

ng H

ours

30

Scrum Artifacts

• Increments

Potentially shippable functionalities which contains list of PBIs are delivered for current sprint combined with increments of all the previous sprints.

It must be working software which is in a consumable solution.

31

Scrum Meetings

• Sprint Planning Meeting

Day 1 – 1st Half

– Prioritized Product Backlog Items are shown by Product Owner

– Product Owner demonstrate the stories to Team– Team selects items committed to complete ; Sprint Goal

is defined by the Team with mutual agreement of PO.

32

Scrum Meetings

• Sprint Planning Meeting

Day 1 – 2nd Half

– Product Owner is available for team to clarify/answer the questions

– Team breaks out each items (or each stories) into the multiple tasks

– Tasks are created for each item and estimate in hours

33

Scrum Meetings

• Daily Scrum Meeting

– Holds everyday during a sprint at same time and same place

– Meeting should not exceed 15 minutes– Team member reports to each other, NOT Scrum Master– Three Questions to be answered by each team member

– What you have done since last daily scrum ?– What will you do before the next daily scrum ?– What are your impediments ?

– Opportunity to team members to synchronize their work

34

Scrum Meetings

• Sprint Review Meeting

– Team presents items are “Done” state to PO and Stakeholders

– Stakeholders provides the feedback to the team – Product Backlog may or may not be reprioritized based on feedback

– Items which are “NOT Done” are not shown– Scrum Master sets the next Sprint Review

35

Scrum Meetings

• Sprint Retrospective Meeting

– Attendees – Scrum Master, Team and Product Owner

– Team provides the opinions to below questions– What went well ?– What didn’t go well ?– What can be improved ?

– Scrum Master helps team in discovery – do not provide answers

36

Product Refinement Meeting

• The ‘Product Backlog Refinement’ which is also called as ‘Product Backlog Grooming’ in reference to keep backlog clean and orderly.

• This is a meeting should happen PO with the team held near to end of the sprint to make sure that backlog is ready for upcoming sprint.

37

Product Refinement MeetingProduct Backlog

Fine-grained requirements (High Priority)

small user stories

Medium-grained requirements (Medium Priority) larger user stories

Coarse-grained requirements (Low Priority)

A Epic

38

Product Refinement Meeting

DEEP Product Backlog is the result of Product Refinement Meeting

D – Detailed AppropriatelyE – EstimatedE – EmergentP – Prioritized

39

Prioritization

Prioritization Factors of PBIs

Business Value Risk Dependency Operational Emergency Due Date

Please Note that, “High Risk and High Value Features” should be completed faster.

40

Prioritization

Prioritization Techniques :

MoSCoW Techniques

Business Value-based

Technical Risk-Based

Kano Model

41

Definition of Done (DoD)

Product Backlog Item (PBI) DoD

• All acceptance criteria have been met• Automated accepted tests confirm that the new feature works as

expected.• All regression tests verify successful integration with other functions.• Any relevant build/deploy scripts have been modified and tested• Working functionality has been reviewed and accepted by PO.• End-user documentation has been written and reviewed (if required)

42

Definition of Done (DoD)

Release Level DoD

• All code related to release has been successfully deployed at the production service

• The release passes all production smoke tests

• Final release has been reviewed and accepted by Product Owner

• Customer and Marketing teams have been trained with the new feature

43

Stories, Themes and Epics

44

User Story

The user story is the atomic functionality of what the user wants to achieve by delivering the business value under system constraints. It can be derived under two domains: the business domain or the technology domain.

INVEST

INVEST is the techniques to have the best way to write an excellent user story. Here is what the acronym means:

I - Independent - The story should be independently identified -- that is, defined at the atomic level. It has no inherent dependency with another user story.

N - Negotiable - The user story can always be rewritten to respond to change.

V - Valuable - The story should always deliver the business value.

E - Estimable - The story should always be estimated in terms of size, in order to maintain the team's velocity.

S - Small - It should be small enough to complete within the iteration. If its size is big, the story must be broken down into smaller stories as much as possible.

T - Testable - The user story should follow test-driven development. Based on acceptance criteria, the test scripts should be developed first, before code is written, as the story should provide the necessary information to make test development possible.

45

User StoryThe 3 Cs of User Story

• The author of the user story can follow the "3 Cs" for writing a well-structured user story:

Card: As a <user>, I want to do <function>, so that I can achieve <business value>.

• Conversation: The detailed description of the story needs to be included. This means its step-by-step execution, basic flow and alternate scenarios, mock-up design, etc.

• Confirmation: This describes the acceptance criteria of the story. This means that the story is passed and accepted if the specific criteria for the story are in fact fulfilled in execution.

46

AGILE ESTIMATION TECHNIQUES

• T-Shirt Size Estimation

• Ideal Days Estimation

• Story Point Estimation

47

T-Shirt Size Estimation

T-Shirt Size Estimating

T-Shirt size estimating is a process by which stories are categorized as Small, Medium and Large. XL Stories are deemed too big to fit into an iteration and so need to be de-composed into smaller stories.

48

Ideal Days Estimation

• A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions/meetings (elapsed time) and all resources necessary to complete the work were immediately available.

• Ideal Days usually estimated in Hours for each PBIs.

49

Story Point Estimation• What is Story Point

– Story point is a arbitrary measure used by Scrum teams. This is used to measure the complexity of the story.

– Story is sized based on A. Business ComplexityB. Efforts C. Doubts or Risks

– Story point estimation is rough, relative and consistent.

– Story Point estimation removes unit confusion ; based on base story reference in terms of story points, other stories are fixed with their story points.

50

Story Point follows Modified Fibonacci Series

Story Point Estimation

51

Story Sizing Meeting with Planning Poker

• Each estimator selects a set of cards.• PO or Customer reads/explains the item to be estimated.• The item is discussed.• Each estimator privately selects a card representing his or her story size. The card is not shown to

the other estimators. Size = Complexity + Effort + Doubts or Risks• Once each estimator has selected a card, all cards are revealed at the same time.• If everyone played the same card, that’s the estimate.• If everyone played the different card, the group discussion happens on the especially on any

outlaying values.• Repeat until team comes to consensus (agree to support each other) on an estimate.

52

Agile Planning Onion

53

Release Planning Meeting• A very high-level plan for multiple Sprints (e.g. three to twelve

iteration) is created during the Release planning. • It is a guideline that reflects expectations about which features will be

implemented and when they are completed. • It also serves as a base to monitor progress within the project. Releases

can be intermediate deliveries done during the project or the final delivery at the end.

To create a Release Plan the following things have to be available:

– A groomed, prioritized and estimated Product Backlog– The (estimated) velocity of the Scrum Team– Conditions of satisfaction (goals for the schedule, scope, resources)

54

Release Planning MeetingVelocity :

• The story points that are supposed to be achieved by team at each iteration.

• Velocity can be determined by the below methods:

a. Determine the velocity range by historical data if the team is old and experienced for the past agile project delivery.

b. Run at least three iterations and calculate the average velocity for new agile team.

55

Release Planning MeetingFixed-scope planning

Fixed-scope planning means, “When will all the story points be achieved?”

There are three steps involved here :

• Add up the product backlog items (project size in terms of total story points).• Estimate velocity as a range or average.• Use the sum of the product backlog items divided by the velocity range or average to determine the date range or average

date of delivery of the project.

Fixed-date planning

Fixed-date planning means, “How many story points we can achieve by a given date?”

There are three steps involved in fixed-date planning as well:

• Determine how many iterations you have.• Estimate velocity as a range or average.• Partition the backlog into "must have," "might have," and "won’t have at this moment" items, according to the number of

items the team can work on (velocity) within each iteration.

56

From the above graph, 90% confidence level for team to achieve velocity is between 20 – 25 story points. So, the velocity range would be 20-25 Story

Points.

Velocity Range Determination on Historical Data

Sprint Velocity1 202 203 254 125 256 407 208 25

1 2 3 4 5 6 7 80

5

10

15

20

25

30

35

40

45

Historical Data on Velocity

Velocity

Release Planning Meeting

57

Release Burndown ChartTotal Project Size (In Story Points) 150

Iteration No. (Sprint No.) Velocity (In Story Points) Remaining Story Points

0 0 150

1 29 121

2 40 81

3 33 48

4 28 20

5 20 0

0 1 2 3 4 50

20

40

60

80

100

120

140

160 150

121

81

48

20

0

Release Burn-down Chart

Sprints

Rem

aini

ng S

tory

Poi

nts

0 1 2 3 4 50

20

40

60

80

100

120

140

160 150

121

81

48

20

0

Release Burn-down Chart

Sprints

Rem

aini

ng S

tory

Poi

nts

58

Release Burndown ChartTotal Project Size (In

Story Points)   150 

       

Iteration No. Average Velocity (Estimated)

Accomplished Story Points (Velocity)

Remaining Story Points

1 30 29 1212 30 30 913 30 31 604 30 32 285 30 28 0

Release Burn-down Chart (X Axis: Remaining Story Points and Y Axis: Iteration No.)

59

Velocity ChartIterations No. of Story Points Accomplished

(Velocity)

1 202 223 134 255 30

1 2 3 4 50

5

10

15

20

25

30

35

Velocity Chart

No. of Story Points Ac-complished (Velocity)

60

Scaling Scrum – Scrum of Scrum (SoS)

• The primary way of scaling scrum to work with large teams is to co-ordinate a “Scrum of Scrum”

• With this approach each Scrum team proceeds as normal but each team also contributes a technical leader or representative who attends “Scrum of Scrum” meetings to co-ordinate the work of multiple scrum teams

61

Scaling Scrum – Scrum of Scrum (SoS)

• Top Three Dispersed Team Challenges in SoS :

Time Zone – The time differences across the globe challenges scrum meetings

Language – Various languages across the globe make communication barrier as common language understanding becoming more tougher

Culture- The culture across the globe, public holidays sometimes become challenges when large distributed team develop at cadence

62

Characteristics of High Performance Agile Team

• Has the right people• A committed and empowered team• Self-Organized Team• Has established trust between team members• Works at a sustainable pace• Reflects a consistent high velocity