Metrics in Agile: SCRUM, XP and Agile Methods

CPSC 547
SOFTWARE MEASUREMENT
Metrics in Agile
Scrum, XP and other agile methods
Group Members:
Mihir Thuse (802330290)
Yashodhan Apte (802328625)
Dhaval Shah (802344499)
Aakash Takale (802330225)
Alekhya Akula (802343731)
Guided by:-
Dr. Bin Cong
Department of Computer Science
California State University, Fullerton
Summer 2015

Metrics in Agile
(SCRUM, XP and other Agile Methods)
2
Table of Contents
1. Abstract........................................................................................................................................... 4
2. Introduction.................................................................................................................................... 5
3. Agile Metrics .................................................................................................................................. 7
3.1.Sprint Burndown........................................................................................................................... 7
3.2.Epic and Release Burndown......................................................................................................... 8
3.3. Velocity........................................................................................................................................ 9
3.4. Control Chart.............................................................................................................................. 11
3.5. Cumulative Flow Diagram ........................................................................................................ 12
4. ISO/IEC 15939 and Software Metrics Standards .................................................................... 14
5. SCRUM........................................................................................................................................ 17
3.3.5.1. What is SCRUM?................................................................................................................ 17
5.2. Why it is called SCRUM?.......................................................................................................... 17
5.3. What’s unique about SCRUM?.................................................................................................. 17
5.4. SCRUM Management................................................................................................................ 18
5.5. SCRUM Process......................................................................................................................... 19
5.5.1. Preparation (Pre-game) ....................................................................................................... 20
5.5.2. Mid-game............................................................................................................................. 21
5.5.3. Release (Post-game) ............................................................................................................ 21
5.6. SCRUM Values........................................................................................................................... 21
5.7. SCRUM Framework ................................................................................................................... 23
5.8. SCRUM Roles............................................................................................................................. 24
5.9. Artifacts in SCRUM.................................................................................................................... 28
5.9.1. Sprint Backlog ..................................................................................................................... 28
5.9.2. Product Backlog................................................................................................................... 29
5.9.3. Product Increment................................................................................................................ 30
5.10. Sprint cycle ............................................................................................................................... 30
6. Understanding Extreme Programming ........................................................................................ 31
6.1. Origin......................................................................................................................................... 31
6.2. Extreme Programming Practices................................................................................................ 32
6.3. Extreme Programming Values................................................................................................... 35
6.4. Application of Extreme Programming....................................................................................... 36

Metrics in Agile
3
7. The Essential Unified Process....................................................................................................... 38
7.1. Features of Essup ....................................................................................................................... 38
CASE STUDY 1 ........................................................................................................................................ 40
CASE STUDY 2 ........................................................................................................................................ 42
Conclusion ................................................................................................................................................. 47
References.................................................................................................................................................. 48

Metrics in Agile
4
ABSTRACT
Software measurement is a measure of determination or bit of programming which serves
to acquire the destinations and also the reproducible and computable measurements. Measurement
of agile development can be used by management level to make well-versed and knowledgeable
decisions. One can describe that agile processes are generative and not rigid. Procedures need to
develop as required, not be recommended in advance. A well-defined methodology creates
intricate and convoluted procedures, while a generative methodology starts with an arrangement
of straightforward procedures and includes others as they are required. In this paper we are going
to explain the application of software metrics in agile software process with the help of specific
agile process frameworks such as Scrum, XP and Essential Unified Process.
Agile software development is an assembly of software development policies based on
iterative and incremental development. In Agile advancement the necessities and arrangements
advance through joint effort between self-sorting out, cross-useful units. Agile methods or agile
processes usually endorses a disciplined project management process that energizes continuous
investigation and collaboration, self-association and responsibility, an arrangement of designing
best practices expected to consider quick conveyance of great programming, and a business
approach that adjusts improvement to client needs and organization objectives.
Essential unified process recognizes practices such as process practices, team practices,
iterative development, architecture driven advancement, use case. It comprises of picking those
practices that are material to the circumstance and join them into obliged procedure. This is viewed
as a change concerning Rational Unified Process (RUP). The Scrum methodology of agile
software development highlights communication and cooperation, functioning software, and the
elasticity to get a feel of developing business realities. Our project concisely illustrates software
metrics in agile development process using ISO/IEC 15939 for software measurement.

Metrics in Agile
5
INTRODUCTION
Software metric is defined as a method of quantitatively determining the extent to which
software possesses a certain attribute. This includes formula as well as chart used for presenting
metrics values, guidelines to use and understanding this chart in the context of specific projects.
Metrics can provide visibility and can also create transparency within development teams as well
as across the development teams to the other business units in the organization.
These are some useful important characteristics that are related with useful software
metrics. It must be:
Simple to understand so that the analysis and calculation of the metric values remain consistent.
Objective in order to reduce influence of personal comments to the calculation and analysis of
metric values.
Cost effective in terms to have a positive return on investment
Informative to make sure that changes in metric values have meaningful interpretations.
Software metrics can be classified into three categories: product metrics, process metrics,
and project metrics. Product metrics describe the characteristics of the product such as size,
complexity, design features, performance, and quality level. Process metrics can be used to
improve software development and maintenance. Examples include the effectiveness of defect
removal during development, the pattern of testing defect arrival, and the response time of the fix
process. Project metrics describe the project characteristics and execution. Examples include the
number of software developers, the staffing pattern over the life cycle of the software, cost,
schedule, and productivity. Some metrics belong to multiple categories. For example, the in-
process quality metrics of a project are both process metrics and project metrics.
Software quality metrics are a subset of software metrics that focus on the quality aspects
of the product, process, and project. In general, software quality metrics are more closely
associated with process and product metrics than with project metrics. Nonetheless, the project
parameters such as the number of developers and their skill levels, the schedule, the size, and the
organization structure certainly affect the quality of the product. Software quality metrics can be
divided further into end-product quality metrics and in-process quality metrics. The essence of

Metrics in Agile
6
software quality engineering is to investigate the relationships among in-process metrics, project
characteristics, and end-product quality, and, based on the findings, to engineer improvements in
both process and product quality. Moreover, we should view quality from the entire software life-
cycle perspective and, in this regard, we should include metrics that measure the quality level of
the maintenance process as another category of software quality metrics. In this chapter we discuss
several metrics in each of three groups of software quality metrics: product quality, in-process
quality, and maintenance quality. In the last sections we also describe the key metrics used by
several major software developers and discuss software metrics data collection.
There are different potential audiences and their interests are also different to use these
metrics:
Software users are interested in quality and software products value.
Senior Managers are interested in overall control and project improvement in the business.
Software Engineers are interested to control and improve the particular software
activities.
Software Quality Assurance engineers are interested in cross-section of what the four previous
audiences are interested in.
Following are some of the metrics that organizations measure to overcome the challenges when
scaling their agile process:
a) Business alignment: It measures how the development efforts are aligned to business
priorities.
b) Application and health risk should be measured without compromising the quality of the
product.
c) Customer satisfaction: It allows an organization to measure how successful their agile
implementation is.

Metrics in Agile
7
3. AGILE METRICS
Agile processes are generative, not prescriptive. Processes need to evolve as needed, not be
prescribed up front. A prescriptive approach generates complex and complicated processes,
whereas a generative approach begins with a set of simple processes and adds others as they are
needed.
Here are a few agile metrics:-
 Sprint Burndown
Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team
forecasts how much work they can complete during a sprint. A sprint burndown report then
tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis
refers to the amount of work left to complete, measured in either story points or hours. The goal
is to have all the forecasted work completed by the end of the sprint.
A team that consistently meets its forecast is a compelling advertisement for agile in their
organization. But don't let that tempt you to fudge the numbers by declaring an item complete
before it really is. It may look good in the short term, but in the long run only hampers learning
and improvement.
Burndown Chart

Metrics in Agile
8
Figure 1: Sprint Burndown
Anti-patterns to watch for
• The team finishes early sprint after sprint because they aren't committing to enough work.
• The team misses their forecast sprint after sprint because they're committing to too much work.
• The burndown line makes steep drops rather than a more gradual burndown because the work
hasn't been broken down into granular pieces.
• The product owner adds or changes the scope mid-sprint.
 Epic and Release Burndown
Epic and release (or version) burndown charts track the progress of development over a
larger body of work than the sprint burndown, and guide development for both scrum and
kanban teams. Since a sprint (for scrum teams) may contain work from several epics and
versions, it's important to track both the progress of individual sprints as well as epics and
versions.
"Scope creep" is the injection of more requirements into a previously-defined project. For
example, if the team is delivering a new website for the company, scope creep would be asking
for new features after the initial requirements had been sketched out. While tolerating scope
creep during a sprint is bad practice, scope change within epics and versions is a natural
consequence of agile development. As the team moves through the project, the product owner
may decide to take on or remove work based on what they're learning. The epic and release burn
down charts keep everyone aware of the ebb and flow of work inside the epic and version.

Metrics in Agile
9
Figure 2: Epic Burndown
• Epic or release forecasts aren't updated as the team churns through the work.
• No progress is made over a period of several iterations.
• Chronic scope creep, which may be a sign that the product owner doesn't fully understand the
problem that body of work is trying to solve.
• Scope grows faster than the team can absorb it.
• The team isn't shipping incremental releases throughout the development of an epic.
 Velocity
Velocity is the average amount of work a scrum team completes during a sprint, measured in
either story poins or hours, and is very useful for forecasting. The product owner can use velocity
to predict how quickly a team can work through the backlog, because the report tracks the
forecasted and completed work over several iterations–the more iterations, the more accurate the
forecast.

Metrics in Agile
10
Let's say the product owner wants to complete 500 story points in the backlog. We know that
the development team generally completes 50 story points per iteration. The product owner can
reasonably assume the team will need 10 iterations (give or take) to complete the required work.
It's important to monitor how velocity evolves over time. New teams can expect to see an
increase in velocity as the team optimizes relationships and the work process. Existing teams can
track their velocity to ensure consistent performance over time, and can confirm that a particular
process change made improvements or not. A decrease in average velocity is usually a sign that
some part of the team's development process has become inefficient and should be brought up at
the next retrospective.
Figure 3: Velocity chart
When velocity is erratic over a long period of time, always revisit the team's estimation practices.
During the team's retrospective, ask the following questions:
 Are there unforeseen development challenges we didn't account for when estimating this
work? How can we better break down work to uncover some of these challenges?

Metrics in Agile
11
 Is there outside business pressure pushing the team beyond its limits? Is adherence to
development best practices suffering as a result?
 As a team, are we overzealous in forecasting for the sprint?
Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it
doesn't mean that team B has higher throughput. Since each team's estimation culture is unique,
their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the
level of effort and output of work based on each team's unique interpretation of story points.
 Control chart
Control charts focus on the cycle time of individual issues–the total time from "in progress" to
"done". Teams with shorter cycle times are likely to have higher throughput, and teams
with consistent cycle times across many issues are more predictable in delivering work. While
cycle time is a primary metric for Kanban teams, scrum teams can benefit from optimized cycle
time as well.
Measuring cycle time is an efficient and flexible way to improve a team's processes because the
results of changes are discernable almost immediately, allowing them to make any further
adjustments right away. The end goal is to have a consistent and short cycle time, regardless of the
type of work (new feature, technical debt, etc.).

Metrics in Agile
12
Figure 4: Control chart
Control charts can appear fickle at first. Don't be so concerned with every outlier. Look for trends.
Here are two areas to watch out for:
 Increasing cycle time- Increasing cycle time saps the team of it is hard-earned agility. In
the team's retrospective take time to understand an increase. One exception: if the team's
definition of done has expanded, cycle time will probably expand too.
 Erratic cycle time– The goal is to have consistent cycle time for work items which have
similar story point values. Filter the control chart for each story point value to check for
consistency. If cycle time is erratic on small and large story point values, spend time in the
retrospective examining the misses and improving future estimation.
 Cumulative Flow Diagram
The cumulative flow diagram is a key resource for Kanban teams, helping them ensure the
flow of work across the team is consistent. With number of issues on the Y axis, time on the X

Metrics in Agile
13
axis, and colors to indicate the various workflow states, it visually points out shortages and
bottlenecks and works in conjunction with WIP limits.
The cumulative flow diagram should look smoothest from left to right. Bubbles or gaps in any
one color indicate shortages and bottlenecks, so when you see one, look for ways to smooth out
color bands across the chart.
Figure 5: Cumulative Flow Diagram
 Blocking issues create large backups in some parts of the process and starvation in others.
 Unchecked backlog growth over time. This results from product owners not closing issues
that are obsolete or simply too low in priority to ever be pulled in.

Metrics in Agile
14
4. ISO/IEC 15939 and Software Metrics Standards
ISO (the International Organisation for Standardisation) and IEC (the International
Electrotechnical Commission) form the specialised system for world-wide standardisation.
National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committees established by the respective organisation to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of
mutual interest. Other international organisations, governmental and non-governmental, in liaison
with ISO and IEC, also take part in the work. International Standards are drafted in accordance
with the rules given in the ISO/IEC Directives, Part 3.In the field of information technology, ISO
and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75% of the national bodies
casting a vote. International Standard ISO/IEC 15939 was prepared by Joint Technical Committee
ISO/IEC JTC1/SC7 Information Technology.
 Terms and Definitions
For the purposes of this international standard, the following terms and definitions apply within
the context of software measurement.
ISO/IEC Concept Meaning in ISO 15939
Acquirer individual or organization that procures a system, software product,
or software service from a supplier
Attribute property or characteristic of an entity that can be distinguished
quantitatively or qualitatively by human or automated means
Base measure measure defined in terms of an attribute and the method for
quantifying it
Data collection of values assigned to base measures, derived measures,
and/or indicators
Data provider individual or organization that is a source of data
Data store organized and persistent collection of data and information that
allows for its retrieval
Decision criteria thresholds, targets, or patterns used to determine the need for action
or further investigation, or to describe the level of confidence in a
given result
Derived measure measure that is defined as a function of two or more values of base
measures
Entity object that is to be characterized by measuring its attributes
Indicator measure that provides an estimate or evaluation of specified attributes
derived from a model with respect to defined information needs

Metrics in Agile
15
Indicator value numerical or categorical result assigned to an indicator
Information need insight necessary to manage objectives, goals, risks, and problems
Information product one or more indicators and their associated interpretations that
address an information need
Measure (noun) variable to which a value is assigned as the result of measurement
Measure (verb) to make a measurement
Measurable concept abstract relationship between attributes of entities and information
needs
Measurement set of operations having the object of determining a value of a
measure
Measurement analyst individual or organization that is responsible for the planning,
performance, evaluation, and improvement of measurement
Measurement
experience base
data store that contains the evaluation of the information products and
the measurement process as well as any lessons learned during the
measurement process
Measurement
function
algorithm or calculation performed to combine two or more base
measures
Measurement
librarian
individual or organization that is responsible for managing the
measurement data store(s)
Measurement method logical sequence of operations, described generically, used in
quantifying an attribute with respect to a specified scale
Measurement
procedure
set of operations, described specifically, used in the performance of a
particular measurement according to a given method
Measurement process the process for establishing, planning, performing and evaluating
software measurement within an overall project or organizational
measurement structure
Measurement process
owner
individual or organization responsible for the measurement process
Measurement sponsor individual or organization that authorizes and supports the
establishment of the measurement process
Measurement user individual or organization that uses the information products
Model algorithm or calculation combining one or more base and/or derived
measures with associated decision criteria
Observation instance of applying a measurement procedure to produce a value for
a base measure
Operator individual or organization that operates the system
Organizational unit the part of an organization that is the subject of measurement
Process set of interrelated activities that transform inputs into outputs
Scale ordered set of values, continuous or discrete, or a set of categories to
which the attribute is mapped
Software product set of computer programs, procedures, and associated documentation
and data
Software service performance of activities, work, or duties connected with a software
product, such as its development, maintenance, and operation

Metrics in Agile
16
Stakeholder individual or organization that sponsors measurement, provides data,
is a user of the measurement results or otherwise participates in the
measurement process
Supplier organization that enters into an agreement with the acquirer for the
supply of a system, software product or software service under the
terms of that agreement
System integrated composite that consists of one or more of the processes,
hardware, software, facilities and people, that provides a capability to
satisfy a stated need or objective
Unit of measurement particular quantity, defined and adopted by convention, with which
other quantities of the same kind are compared in order to express
their magnitude relative to that quantity
User individual or organization that uses the system to perform a specific
function
Value numerical or categorical result assigned to a base measure, derived
measure, or indicator

Metrics in Agile
17
5. SCRUM
 What is SCRUM
Scrum is a management and control process that cuts through complexity to focus
on building software that meets business needs. Management and teams are able to get
their hands around the requirements and technologies, never let go, and deliver working
software, incrementally and empirically. Scrum itself is a simple framework for effective
team collaboration on complex software projects. Now, coming to actual definition of
SCRUM, according to Scrum Alliance, “Scrum is an agile framework for completing
complex projects. Scrum originally was formalized for software development projects, but
it works well for any complex, innovative scope of work. The possibilities are endless. The
Scrum framework is deceptively simple.” From the definition it becomes quite clear that
Scrum is useful for handling and managing the projects which are comparatively hard or
complicated. Scrum was solemnized in software industries for the enlargement and
improvement of software projects then it came into consideration that it is well suited for
complex which in other words we can say hard and complicated work. It has got large
amount of possibilities.
 Why it is called SCRUM?
It is an iterative and incremental agile software development methodology for
managing product development. The history of Scrum is as follows, the first Scrum process
was created in 1993 by Jeff Sutherland. He borrowed the term “scrum” from an analogy
put forth in 1986 study by Takeuchi and Nonaka, published in the Harvard Business
Review. The study which Takeuchi and Nonaka did was to compare high-performing, cross
functional teams to scrum formation used by Rugby teams. Today, Scrum is leading agile
development method, used by Fortune 500 companies around the world. The Scrum
Alliance exists to change the way we handle complex undertakings, bringing the Scrum
system and agile principles past programming improvement to the more extensive world
of work.
 What’s unique about SCRUM?
Of all the agile methodologies, Scrum is unique because it introduced the idea of
“empirical process control.” That is, Scrum uses the real-world progress of a project — not
a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects

Metrics in Agile
18
are divided into concise and neat work rhythms, known as sprints, which are typically one
week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and
team members meet to assess the progress of a project and plan its next steps. This allows
a project’s direction to be adjusted based on accomplished work, not guesswork or
assumption or supposition.
Ethically, this emphasis on current valuation of completed work is largely
responsible for its admiration and approval with managers and developers alike. But what
allows the Scrum methodology to really work is a set of roles, responsibilities, and
meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an
appealing option, the stability of its practices give teams something to lean on when
development gets disorganized.
 SCRUM Management
At the center of every Scrum task is an excess of work to be finished. This backlog
is populated during the planning phase of a release and defines the scope of the release.
After the team completes the project scope and high-level designs, it divides the
development process into a series of short iterations called sprints. Each sprint aims to
implement a fixed number of backlog. Before each sprint, the team members identify the
backlog items for the sprint. Every sprint means to actualize an altered number of backlog.
Prior to every sprint, the colleagues distinguish the backlog things for the sprint. Toward
the end of a sprint, the group surveys the sprint to understandable lessons learned and check
progress. Amid a sprint, the group has a day by day meeting called a scrum. Every
colleague portrays the work to be done that day, progress from the day preceding, and any
obstructs that must be cleared. To keep the meetings short, the scrum is supposed to be
conducted with everyone in the same room standing up for the whole meeting. When
enough of the backlog has been implemented so that the end users believe the release is
worth putting into generation, administration closes advancement. The team then performs
integration testing, training, and documentation as necessary for product release. It is also
a loose set of guidelines that govern the development process of a product, from its design
stages to its completion. There are some common failures of traditional development
process which are stated as follows: Unrealistic estimates of time, cost, and quality of the
product, developers are forced to lie about how the project is progressing and chaos due to

Metrics in Agile
19
changing requirements. We will discuss all of the above briefly one by one. The first one
says that the project management and the developers tend to underestimate how much time
and resources a project will take, and how much functionality can be produced. Second,
says when management miscalculates the time and cost needed to reach a certain level of
quality, the developers must either lie about how much progress has been made on the
product, or face the fury or anger of the management. Last tells us that requirements of a
project usually change drastically from the time the product is designed to when it is
released. Under most product development methods, all design is done at the beginning of
the project, and then no changes are allowed for or made when the requirements change.
All of the above are common failures as I have stated that before, so the Scrum helps us to
cure this types of traditional failures. After seeing what scrum management is we will
proceed to see what scrum process is.
 SCRUM Process
The below figures shows scrum process.

Metrics in Agile
20
Figure 6: Scrum Process
There are three stages in scrum process namely:
1. Preparation (Pre-game)
2. Mid-game
3. Release (Post-game)
1. Preparation (Pre-game) phase: This is the first stage of scrum process. It is mainly associated
with planning i.e. preparation and system architecture. The Planning task aims in portraying
the new release transferring with current product excess with its suitable cost and timetable
estimation. This task further transfers on whether the new release another stock item or
headway to existing item. For the previous case, arranging includes conceptualization and
examination of new stock item for its successful execution release and for later, this involves
only narrowed limited analysis. This planning includes definition of project team, tools, and
other resources, risk assessment and controlling issues, training needs and verification needs

Metrics in Agile
21
and confirmation administration support. The System Architecture task is to develop high-
level design of system and to plan system architecture based on existing Product backlog. All
the changes, required for implementing backlog items and the problems involved in
implementing them are identified. This task involves making decisions in design review
meetings over implementation proposals and preparing preliminary plans for releasing
products are prepared.
2. Mid-game phase: In this phase, Sprints, which worries about the usefulness of new release are
produced, regarding distinctive environmental and technical variables like time, requirements,
resources, budget, etc., A Sprint is only a cycle that conveys all through an improvement action
for a month or less yet for steady period. These Sprints improvement procedure is an iterative
and incremental procedure i.e., for every iteration Sprint functionality will keep increasing, in
developing new release functionality. This Sprint improvement procedure continues as like
conventional advancement transform and includes every one of the stages - necessities
elicitation, examination, plan, usage, testing, and conveyance and includes assignments like
Develop, Wrap, Review and Adjust. Every Sprint normally goes on for 2-4 weeks in length
and there can exists, numerous quantities of sprints in new release advancement.
3. Release (Post-game): This is the last phase of scrum process. It is important phase of the
process. This stage alludes to 'Closure' of new release. When all environmental and technical
variables of new release's improvement procedure have controlled, regarding its sought
usefulness, then it goes into post-gaming stage. It incorporates undertakings like integration,
testing and documentation.
 SCRUM values

Metrics in Agile
22
Figure 7: Scrum values
The five Scrum values are:
1. Focus: Team focus and Sprint goals are important responsibilities for the Scrum Master. The
Scrum Master should remove all impediments from the Team and protect the Scrum
members from external influence. The Product Owner and Scrum Master should be
responsible for ensuring a well refined (groomed) backlog which is both estimated and
ordered and the team should be fully be focused on delivering the work committed to in the
sprints.
2. Openness: This really is one of the core values that makes Agile so different from other
project management styles. The Product Owner should be open and willing to accept change
and to embrace new ideas. The Back log should be fully qualified and visible so that
everyone is aware of what work is up and coming. Remember openness is in both directions.
The retrospective which is often overlooked should also be fully open, with problems openly
discussed.

Metrics in Agile
23
3. Respect: This is perhaps one of the important values in Agile. I believe that this is value that
is not followed up to the mark. The Product Owner gets to dictate what work gets done and
in what sequence and it's the responsibility of the Scrum team to respect those decisions.
However The Product Owner must trust and respect the team to decide how they will
accomplish this and respect the team when they push back or if they believe the Product
Owner is encouraging them to overcommit. The Scrum Master should be aware that they are
not management but the servant leader responsible for ensuring that the Scrum team is able
to run at maximum efficiency and to coach stakeholders, Product Owner and the Scrum team
on all things agile.
4. Courage: The Scrum Master needs to have the courage to stand firm against stakeholders and
the Product Owner when it's right to do so. Whilst at the same time the Scrum team needs the
courage to commit to as much work as possible within the Sprint whilst respecting the
definition of done.
5. Commitment: The Scrum team commits to what they will complete each sprint. They also
commit to how the work will be ‘done’ and to meet the Definition of Done. The Team
commits to doing whatever is collectively necessary in order to meet their goals. The wider
organization also commits to support the scrum team and to respect the values of Agile.
 SCRUM Framework

Metrics in Agile
24
Figure 8: Scrum Framework
SCRUM is an agile framework and defined with following roles and ceremonies.
 SCRUM Roles
1. Product owner: Product Owner speaks to partner or client. The assignment of product owner
is get ready client useful necessities rundown of creating item, called 'user stories', adding them
to product backlog and after that organizing them. Subsequently, he is in charge of determining
what undertakings to done in a specific sprint and evaluating its time and exertion needed for
doing this. Product owner will likewise be in charge of encouraging scrum arranging meeting
and guaranteeing the benefit or ROI (Rate of Investment) of the project. He has right to
acknowledge or reject the work consequences of sprint and can change components and need
as required.

Metrics in Agile
25
2. Scrum team: Scrum team is a project development team that has obligation of making
important activities and arranging itself for accomplishing each sprint goals. When all is said
in done, a Scrum group can be 5 to 10 individuals, and for software project team includes
analysts, developers, interface designers, and testers. His scrum group includes exertion
estimation for every sprint, making sprint build-up, exploring item excess and proposing the
vital hindrances that must be uprooted for enhancing the advancement of product improvement
progress.
3. Scrum master: The part of scrum expert is to guarantee that scrum developing team is in stick
with picked procedure and in charge of its right execution, expanding the advantages and for
taking out their obstruction issues in accomplishing sprint objectives. For accomplishing this
obligation, Scrum Master empowers great association over every one of the elements of the
emphasis and shields group from outer interfaces. The Scrum Master conducts scrum daily
meetings, produces sprint reviews, then examining the advancement and gives fundamental
assets to better results.
There are Ceremonies like,
1. Sprint Planning Meeting
2. Daily Scrum Meeting
3. Sprint Review/Demonstration Meeting
4. Sprint Retrospection Meeting
Figure 9: Scrum Ceremonies

Metrics in Agile
26
1. Sprint Planning Meeting:
Time Box: 4 hours (2 weeks sprint) / 8 hours (4 weeks sprint)
Attendees: Scrum Master, Product Owner and Scrum Team
This meeting consists of 2 parts:
“What” is to be developed?: In first part Product owner describes and presents the ordered Product
Backlog items and Sprint goal to the entire Scrum Team, who collaborates about understanding
the work of the Sprint.
“How” it will deliver the Sprint Goal?: In second half of this meeting scrum team plans in detail
which tasks are necessary to fulfill the Sprint Goal and deliver the forecasted Product Backlog
items according to capacity of team.
Inputs to Sprint Planning Meeting: Product Backlog and Team Capacity
Output of Sprint Planning Meeting: Sprint Backlog and Sprint Goal
2. Daily Scrum Meeting:
The Daily Scrum is the key inspect and adapt meeting during a Sprint. During the Sprint execution,
the scrum Team meets every day, for Daily Scrum meeting and inspects the progress and ensures
communication flow inside the Team. It is a short (15 minutes) meeting.
Time box: 15 Minutes
Attendees: Scrum Master, Product Owner (Optional) and Scrum Team
It is held at the same time at same place each day. During the meeting, each Team member
explains:
 What have I accomplished since the last meeting?
 What am I going to do before the next meeting?
 What obstacles are in my way?
The Daily Scrum improves communication, eliminates other meetings, identifies & removes
impediments to development, highlights and promotes quick decision-making, and improves
everyone’s level of project knowledge. The responsibility for conducting the Daily Scrum is with
the Team and Scrum Master facilitates the same. The Scrum Master ensures the all the
impediments are noted and he/she will get these resolved. He coaches the Team to keep the Daily
Scrum short and making sure that people speak briefly.
3. Sprint Review/Demonstration Meeting:
Time box: 1.5 hours (2 weeks sprint) / 3 hours (4 weeks sprint)

Metrics in Agile
27
Attendees: Scrum Master, Product Owner and Scrum Team, All the Stakeholder/Sponsors,
Customers.
A Sprint Review/Demo meeting is held at the end of the Sprint to inspect the Increment. The Team
demonstrates the Increment with focus on the Sprint Goal according to the Definition of Done.
The Product Owner reviews and accepts the delivered Increment. During the Sprint Review,
Product Owner, Team and stakeholders review what was done. This meeting should not have
Slides, with the presentation of the results but should have working demonstration of the work
planned in sprint planning.
After the demonstration the Product Owner and other relevant stakeholders tell their impressions
and clarify their requirements (user stories) if a requirement was not implement right. The Product
Owner identifies what has been done and what hasn’t been done (according to the Definition of
Done). The Product Owner accepts the user stories that have been done. Results of this meeting
can be new requirements in the Product Backlog, and a new prioritization of existing Product
Backlog items.
4. Sprint Retrospection Meeting:
Time box: 2 hours (2 weeks sprint) / 4 hours (4 weeks sprint)
Attendees: Scrum Master, Product Owner and Scrum Team
In the Sprint Retrospective the Scrum Team revises their way of work in the past in order to make
it more efficient and effective in the future. The Scrum Master encourages the Scrum Team to
search for best practices and to identify improvement measures that it will implement in the next
Sprint. After the Sprint Review and before the next Sprint Planning, the Team has a Sprint
Retrospective.
Whereas the Sprint Review is about the product, the Sprint Retrospective is about the process –
the way in which the Scrum team works. It is never omitted.
In the Sprint Retrospective meeting, the Scrum Master encourages the Development Team to
inspect, within the Scrum framework and practices, how the last Sprint went in regards to people,
relationships, process and tools. The Team should identify and prioritize the major items that went
well, and those items that, if done differently, could make things even better. By the end of the
Sprint Retrospective, the Team should have identified actionable improvement measures that they
will implement in the next Sprint.

Metrics in Agile
28
 Artifacts in SCRUM
Basically there are three types of Artifacts in Scrum,
1. Sprint Backlog
2. Product Backlog
3. Product Increment
 Sprint Backlog: The sprint backlog is a rundown of assignments distinguished by the Scrum
group to be finished during the Scrum sprint. During the sprint planning meeting, the group
chooses some number of product backlog items, more often than not as client stories, and
recognizes the undertakings important to finish every client story. Most groups additionally
gauge how long every undertaking will go up against somebody the group to finish.
It's discriminating that the group chooses the things and size of the sprint backlog. Since
they are the individuals focusing on finishing the assignments, they must be the individuals
to pick what they are focusing on amid the Scrum sprint.
The sprint backlog is ordinarily kept up as a spreadsheet, yet it is additionally
conceivable to utilize your defect tracking system or any of a number of software products
designed composed particularly for Scrum or Agile. A case of a sprint backlog in a
spreadsheet resembles this:
Figure 10: Sprint Backlog
During the Scrum sprint, team members are expected to update the sprint backlog as new
information is available, but minimally once per day. Many teams will do this during the daily

Metrics in Agile
29
scrum. Once each day, the estimated work remaining in the sprint is calculated and graphed by the
Scrum Master, resulting in a sprint burn down chart like this one.
The team does its best to pull the right amount of work into the Scrum sprint, but sometimes
too much or too little work is pulled in during planning. In this case, the team needs to add or
remove tasks.
Let's take an example using the sprint burn down chart above. As you can see, the team in
this scenario pulled in too much work initially into the sprint backlog, and still had nearly 600
hours to go on day 13 of a 20-day sprint. The product owner was consulted and agreed to remove
some user stories from the sprint. This resulted in the big drop on the chart between days 13 and
14. From there, the team made consistent progress and finished the Scrum sprint successfully.
 Product Backlog: The agile product backlog in Scrum is an organized elements rundown,
Containing short depictions of all usefulness wanted in the item. At the point when applying
Scrum, it's not important to begin a task with an extensive, forthright push to report all
prerequisites. Ordinarily, a Scrum group and its product owner begin by writing down everything
they can think of for agile backlog prioritization. This agile product backlog is almost always more
than enough for a first sprint. The Scrum product backlog is then permitted to develop and change
as more is found out about the item and its clients.
The Product Backlog is the property of the Product Owner. He is responsible for its content,
its availability and prioritization. Business value is set by the Product Owner. Development effort
is set by the Team. All items in the Product Backlog are prioritized and sorted by business value.
The top priority items drive the next development activities. Higher priority items are clearer and
have more detailed information than lower priority items.

Metrics in Agile
30
The Product Backlog items are initially established and calculated during Release
Planning. Afterwards they are updated in Sprint Planning or Backlog Grooming’s. The top priority
items are selected for development during Sprint Planning developed in the Sprint and reviewed
in the Sprint Review.
 Product Increment: At the end of a Sprint the new Increment must be in a usable condition
and meet the Scrum Team’s Definition of Done. In Scrum, the Development Team delivers each
Sprint an Increment. The increment must consist of thoroughly tested code that has been built into
an executable, and the user operation of the functionality is documented either in Help files or user
documentation. These requirements are documented in the Definition of Done. If everything works
fine and the Development Team has estimated well, the Increment includes all items, which were
planned in the Sprint Backlog, tested and documented.
 Sprint Cycle
The sprint cycle is an iterative cycle of around 30 days, in which the actual development of the
product is done. It begins with a Sprint Planning Meeting to choose what will be done in the present
sprint. Then the development is done. A sprint is shut with a Sprint Review Meeting where the
advancement made in the last sprint is illustrated, the sprint is looked into, and conformities are
made to the task as fundamental. The sprint cycle is rehashed until the products advancement is
finished. The product is finished when the variables of time, quality, competition, and expense are
at an offset.
Figure 11: Sprint Cycle

Metrics in Agile
31
6. Understanding Extreme Programming
Extreme Programming (XP) is a software engineering methodology, the most prominent
of several agile software development methodologies. Like other agile methodologies, Extreme
Programming differs from traditional methodologies primarily in placing a higher value on
adaptability than on predictability. Proponents of XP regard ongoing changes to requirements as
an often natural and often inescapable aspect of software development projects; they believe that
being able to adapt to changing requirements at any point during the project life is a more realistic
and better approach than attempting to define all requirements at the beginning of a project and
then expending effort to control changes to the requirements. XP prescribes a set of day-to-day
practices for managers and developers; the practices are meant to embody and encourage particular
values.
Proponents believe that the exercise of these practices—which are traditional software
engineering practices taken to so-called "extreme" levels—leads to a development process that is
more responsive to customer needs ("agile") than traditional methods, while creating software of
similar or better quality. XP consists of 12 related practices and works best for small teams of 5 to
15 developers. Rather than focus on paper-based requirements and design documentation, XP
concentrates on producing executable code and automated test drivers. This focus on source code
makes XP controversial, leading some to compare it to hacking. This comparison is unjustified
because XP highly values simple design, and counters hacking claims by emphasizing refactoring,
strong regression testing, and continuous code inspections through pair programming.
 Origins
Software development in the 1990s was shaped by two major influences: internally, object-
oriented programming replaced procedural programming as the programming paradigm favored
by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized
speed-to-market and company-growth as competitive business factors. Rapidly-changing
requirements demanded shorter product life-cycles, and were often incompatible with traditional
methods of software development. The origin of extreme programming (XP) started in 1990s by
Kent Black as a method which was created as a reaction to the old methodology XP. It uses
different approaches that distinguishes itself from waterfall model.

Metrics in Agile
32
Information about the principles and practices behind XP was disseminated to the wider
world through discussions on the WikiWikiWeb. Various contributors discussed and expanded
upon the ideas, and some spin-off methodologies resulted. Eventually, XP concepts have been
explained, for several years, using a hyper-text system map on the XP website. XP created quite a
buzz in the late 1990s and early 2000s, seeing adoption in a number of environments radically
different from its origins. The high discipline required by the original practices often went by the
wayside, causing certain practices to be deprecated or left undone on individual sites. Agile
development practices have not stood still, and XP is still evolving, assimilating more lessons from
experiences in the field.
Extreme Programming is described as being:
 An attempt to reconcile humanity and productivity
 A mechanism for social change
 A path to improvement
 A style of development
 A software development discipline
The main aim of XP is to lower the cost of change. In traditional system development methods
(like SSADM) the requirements for the system are determined at the beginning of the development
project and often fixed from that point on. This means that the cost of changing the requirements
at a later stage will be high.
 Extreme Programming Practices
The Extreme Programming software development process starts with planning, and all
iterations consist of four basic phases in its life cycle: designing, coding, testing, and listening.
The overriding values that drives the XP life cycle are continual communication with the customer
and amongst the team, simplicity by harping on the minimalist solution, frequent feedback through
unit and acceptance testing, and the courage to take on problems proactively and integrate testing
and changes in the development phase.

Metrics in Agile
33
Figure 12: Extreme Programming Practices
1. Planning:
The first phase of Extreme Programming life cycle is planning, where customers or users
meet with the development team to create ‘user stories’ or requirements. The development team
converts user stories into iterations that cover a small part of the functionality or features required.
A combination of iterations provides the customer with the final fully functional product.
The programming team prepares the plan, time, and costs of carrying out the iterations, and
individual developers sign up for iterations. One planning approach is the critical path method,
grouping iterations essential for project progress in a linear fashion, and arranging for completion
of other iterations parallel to the critical path.
2. Designing:
An iteration of XP programming starts with designing. The guiding principles of this stage
are:
 Thrust on simplicity by expressing a thing only once and not adding functionality
in anticipation.

Metrics in Agile
34
 Using systems metaphor or standards on names, class names and methods, and
agreeing on uniform styles and formats to ensure compatibility among the work of
different team members.
 Using Software Class Responsibilities and Collaboration (CRC) Cards that allow
for a departure from the traditional procedural mindset and make possible object
oriented technology. Such cards allow all members of the project team to contribute
ideas, and collate the best ideas into the design.
Creating spike solutions or simple programs that explore potential solutions for a specific
problem, ignoring all other concerns, to mitigate risk.
3. Coding:
Coding constitutes the most important phase in the Extreme Programming life cycle. XP
programming gives priority to the actual coding over all other tasks such as documentation to
ensure that the customer receives something substantial in value at the end of the day.
Standards related to coding include:
Developing the code based on the agreed metaphors and standards, and adopting a policy
of collective code ownership.
Pair programming or developing code by two programmers working together on a single
machine, aimed at producing higher quality code at the same or less cost.
Strict adherence to 40-hour workweeks with no overtime. This ensures the developers work
in the peak of their mental and physical faculties.
Frequent integration of the code to the dedicated repository, with only one pair integrating
at a time to prevent conflicts, and optimization at the end.
4. Testing:
Extreme program integrates testing with the development phase rather than at the end of
the development phase. All codes have unit tests to eliminate bugs, and the code passes all such
unit tests before release. Another key test is customer acceptance tests, based on the customer
specifications. Acceptance test run at the completion of the coding, and the developers provide the
customer with the results of the acceptance tests along with demonstrations.
5. Listening:

Metrics in Agile
35
The basis of extreme programming is a continuous mechanism of customer involvement
through feedback during the development phase. Apart from the customer, the developer
also receives feedback from the project manager. The basis of feedback is the customer
acceptance tests. Each feedback of the customer that specifies revised requirement becomes
the basis of a new design, and the process of design-coding-tests-listening repeats itself. If
the customer remains satisfied with the test results the iteration ends there, and the design for the
new iteration starts, which again follows the design-coding-testing-listening cycle.
 Extreme Programming Values
XP is a values-based methodology. The values are Simplicity, Communication, Feedback
and Courage. XP’s core values are best summarized in the following statement by Kent Beck: Do
more of what works and do less of what doesn’t.
Highlights of the four values are itemized below:
Simplicity encourages:
• Delivering the simplest functionality that meets business needs
• Designing the simplest software that supports the needed functionality
• Building for today and not for tomorrow
• Writing code that is easy to read, understand, maintain and modify
Communication is accomplished by:
• Collaborative workspaces
• Co-location of development and business space
• Paired development
• Frequently changing pair partners
• Frequently changing assignments
• Public status displays
• Short standup meetings
• Unit tests, demos and oral communication, not documentation

Metrics in Agile
36
Feedback is provided by:
• Aggressive iterative and incremental releases
• Frequent releases to end users
• Co-location with end users
• Automated unit tests
• Automated functional tests
Courage is required to:
• Do the right thing in the face of opposition
• Do the practices required to succeed
 Application of Extreme Programming
Extreme Programming remains a sensible choice for some projects. Projects suited to Extreme
Programming are those that:
Projects suited for more traditional methodologies are those that:
 Involve stable technology and have fixed requirements, where it is known that few changes
will occur
 Involve mission critical or safety critical systems, where formal methods must be employed
for safety or insurance reasons
 Are large projects which may overwhelm informal communication mechanisms
 Involve new or prototype technology, where the requirements change rapidly, or some
development is required to discover unforeseen implementation problems
 Are research projects, where the resulting work is not the software product itself, but
domain knowledge
 Are small and more easily managed through informal methods

Metrics in Agile
37
 Have complex products which continue beyond the project scope to require frequent and
significant alterations, where a recorded knowledge base, or documentation set, becomes
a fundamental necessity to support the maintenance

Metrics in Agile
38
7. The Essential Unified Process
The Essential Unified Process (EssUP) is a new process that stands on the shoulders of
modern software development practices. EssUP cautiously integrates successful practices from the
unified process camp, the agile methods camp, and the process improvement camp, each
contributing different capabilities.
Why we need a new process:
• Traditional software processes are too heavy. No one reads large and lengthy process
descriptions.
• Process must focus to support developers, not just process experts. • Process must assist teams
to get product quality as well as process quality; thus not only pass CMMI appraisals, but also
deliver good software. The focus of any software development process must be on producing good
software.
• Process must provide agility with discipline, balancing the need for governance without stifling
creativity.
• The approach must let project teams (developers without the help of process engineers) easily
add good practices on top of existing processes.
• Process should empower the team.
 Features of Esup
EssUP is very different from other processes or methods in how it is presented. It embodies an
idea new to the process industry—Separation of Concerns (SOC), as in aspect-oriented thinking.
When we apply this idea to process development, we generate a fundamentally different process
one that makes it easier and more intuitive to select your tailor-made software process. Most
importantly, it will be more natural and intuitive to plan and execute a software project. To
illustrate, here are a number of situations where we have applied the idea of SOC:
• Each practice is kept separately from the other practices. You choose only the practices
you need without having to deselect activities and artifacts. Just select the practices you want and
compose them with one another and with your existing process.

Metrics in Agile
39
• You can easily separate elements from your existing process and from the elements of
the EssUP. This lets you improve what you already have, one practice at a time, in an evolutionary
way. Starting from a generic platform, you describe your own process using a very simple
technique inspired by the game industry. Based on this, you can add practices without requiring a
revolutionary adoption of all practices. You take what you need and what you think your
organization can adopt without severe risks.
• EssUP separates two different views of the process—the process authors' and software
developers' view. In the past, processes have almost entirely focused on the authors' needs. EssUP
prioritizes the developers' perspective. It uses techniques from the game industry to develop, teach,
apply, and use the process to make it lightweight and agile. And, we promise, much more fun.
• We separate the essentials from the non-essentials. This lets us create a core lightweight
process with unprecedented growth potential (hundreds of practices).
The Essential Unified Process:
 Concentrates on the essentials applicable to all your projects.
 Enables you to build on the skills that you already possess.
 Provides guidance on implementing a consistent approach.
 Focuses on enhancing the skills of the people involved in development.
 Adds just enough process to address your project risks.

Metrics in Agile
40
CASE STUDY 1
Situation:
Bill Holst, president and principal consulting software engineer for Prescient Software
Engineering, managed two projects for Colorado Springs Utilities -- an electric project and a gas
project. Both projects were distribution design systems very similar in scope. Holst contracted out
the development work and used the same team for both projects. The electric project was a fixed
price bid and was done using a traditional waterfall approach. The gas project was done next with
the same development team -- a team that was new to Agile -- with T&M (Times and Materials)
pricing. In both cases the customers of the project were field engineers. The waterfall approach
dictates that requirements are complete before coding begins. Typically, once the requirements
phase has completed, the users don’t get involved again until the user acceptance test (UAT) phase
nears the end of the project. With an Agile approach, the users remain involved throughout the
lifecycle, with regular reviews and updates to the requirements.
Using waterfall yields unsatisfactory results
Holst felt that the electric project, which was done first, had many deficiencies. There was
a long lag time between expected delivery and actual delivery. The software didn’t match what the
customers felt they had asked for. There was a lot of churn throughout the project with
disappointing results. Frustration was felt all around.
Initial transition: “We suck at Agile”
The team knew they needed to do something differently, so they decided to try an Agile
approach for the gas project. They hired some Agile trainers to coach them through the transition,
but there was a lot of initial team resistance. The field engineers didn’t like it, thinking the
methodology was too touchy-feely. “We want to build a system and these guys are talking about
commitment,” was the general sentiment. Holst joked that they team suggested getting coffee mugs
that said, “We suck at Agile.”
The project suffered through many problems. The test cases didn’t match the logic, which
was convoluted and confusing. Six iterations went forward, but a look at velocity and burn-down

Metrics in Agile
41
charts showed that progress was getting worse rather than better. The team made a tough decision:
Stop and regroup.
The turnaround
The team decided to use the 7th
iteration to re-examine the requirements. The developers
took two weeks off and the field engineers who had defined the requirements using pseudo-code,
recognized that their original requirements needed to be redone. They took the original 800 lines
of pseudo-code and, now, with a better understanding of the system, what was working and what
wasn’t, were able to rework it down to around 200 lines of pseudo-code in much more logical way.
This redesign of the requirements was the turning point of the project.
This change in direction was only possible because of the Agile nature of the project. “The
cost to change the system this far downstream would have been too high [using the traditional
model],” says Holst. Having the more flexible pricing model, along with the ability to change
requirements midstream was a major key to success.
The results
With the reworked requirements, the team was set to start practicing Agile in the manner
it was meant to be practiced. Velocity increased as the backlog decreased and, even with the two-
week delay to regroup, the project ended up being finished early and under budget.
In all respects, the project was a success. In comparing it to the first project, if this were a
competition, the Agile project would have scored higher in every category. The quality was better,
and the test cases were cleaner. “There were fewer test cases, but more coverage,” said
Holst. Usability was much better, too. “Usability is a key ‘ility’ that’s hard to define in
requirements,” said Holst, but joked that “like pornography, you know it when you see it.”
The bottom line was that the Agile project came in early, under budget, and the users loved it.
Keys to success
Holst attributes success to two important factors: Agile training and the regroup effort.
“We hired some consulting training to come in and ground the team in Agile methodology.” This
was important because none of the project team had worked with Agile before, so getting the
training and having the necessary support was key.
Regarding the regroup effort, Holst says, “We had a major shift in what the product team
wanted about halfway through the project and we were able to reform the project and redo logically

Metrics in Agile
42
what we wanted the software to do mid-stream.” Holst believes that the flexibility provided with
an Agile methodology that allowed for this regroup was one of the primary keys to success.
Will Agile always prevail?
Even though in this case Agile was the clear winner if this had been a competition between
the Agile and Waterfall methodologies, it does not mean that every Agile project will succeed or
that Agile is clearly the better methodology. Even the Agile project started out very poorly and
had the team continued down that path, that project most likely would have had results just as poor
as the waterfall project. However, the ability to inspect and adapt, taking time to regroup and
rework requirements, allowed this team to get back on track.
How does the team feel? Let’s just say they want a new coffee mug slogan. They’re no longer
saying, “We suck at Agile,” but instead, “Let’s do it again.”
CASE STUDY 2
Situation:
BT employs some 8,000 IT professionals in a variety of roles including project & delivery
management, architecture & design, software engineering, integration & testing, operational
support and service management. Much of its internally-focused development work has
traditionally been channeled through a number of business-focused delivery projects or
programmers, ranging from quite small, simple developments to large-scale and complex business
solutions, the latter tending to be the norm.
The predominant delivery approach, certainly for the larger delivery programmed, was
very much waterfall-based. The use of agile development practice, notably DSDM and Scrum,
was limited to a small number of fairly small, self-contained development teams. BT was in fact
one of the founding members of the DSDM Consortium and took an active part in shaping the
method in its early days.
Despite successfully delivering a number of large, complex solutions into a dynamic,
competitive yet highly regulated business environment, many significant transformation
programmed were struggling to deliver any notable results in an acceptable timeframe. As part of
a CMMI-inspired improvement strategy, efforts had been made to formalize acknowledged best
practice processes into a standard delivery methodology. In 2004, this standard methodology was

Metrics in Agile
43
in the process of being rolled out when the new CIO made it clear that an entirely new agile
approach was needed.
Drawbacks of the waterfall
Reinforcement of current waterfall-based practices was not really the answer however.
Many of the delivery problems experienced at BT, and no doubt other large organizations, stem
from the nature of the waterfall lifecycle itself. Some examples of these problems are given here.
For a more complete demolition of waterfall practices, refer to Craig Larman’s excellent work [1].
Poor requirements capture
Capturing requirements certainly isn’t a bad thing. On typical large programs however,
 Individual business stakeholders are anxious to incorporate all of their known requirements
into the first / next release
 "Gold users" generate hundreds, if not thousands of detailed requirements that often bear
little relationship to the business problems that needs to be addressed
 Most if not all requirements are given a high priority
 The requirements themselves, at best, represent today’s view, which will certainly have
changed by the time the requirements are actually implemented
Disconnected design
Given the sheer number of requirements, the design community finds itself spending most
of its time trying to figure out what they mean. Meanwhile,
 The requirements analysts move on to other projects, taking with them important tacit
knowledge.
 Some stakeholders become concerned that their requirements are not being adequately
addressed, and therefore refuse to sign off the designs
 Other stakeholders unearth more requirements or raise change requests, diverting scarce
design expertise onto impact analyses
Development squeeze
With the design stage having slipped, development teams find themselves under intense
pressure to deliver components into the integration environment by the originally agreed date. In
fact, they often take the decision, reluctantly, to start development against an unstable design,
rather than do nothing or divert resources to other programs. Inevitably, system testing is cut short
so that original timescales are met and the program is seen to be on target.

Metrics in Agile
44
The integration headache
The integration team has a set number of weeks during which it needs to integrate what it
expects to be fully functional and relatively bug-free code. Because of the instability of the
component code, and the lack of any effective regression test capability, effort is instead diverted
to trying to resolve elementary bugs in the delivered code, liaising with a development team that
is now engaged in the next major release. Actual integration therefore runs into months, creating
a knock-on effect on other programs requiring the services of the Integration team, not to mention
frustrations within the business community who had been busy preparing themselves for an on-
time delivery.
The deployment nightmare
It is now at least 6, or even 12 – 18 months since the business originally identified the need
for this particular solution. Compromises and oversights made during the requirements and design
phases, followed by de-scoping during development has resulted in a solution that bears little
relationship with what was originally envisaged. Besides, the world has actually moved on in the
meantime. The business then finds that the solution is not fit-for-purpose and refuses to adopt it.
Worse, they adopt it and soon find that it is slow, error-prone and lacks key features, and eventually
revert to the old system. The end result – more shelf ware!
Early in each delivery cycle, the programmer sets out clear targets for what it expects to
achieve for the business during that cycle. These targets invariably include a strong emphasis on
the end-customer experience, such as overall response times, transaction success rates, and so on.
At the end of the cycle, the programmer is assessed against these targets, and the outcome of this
assessment will influence the timing of bonus payments for the programmer team members.
Programmers failing to deliver business value over a series of cycles face being closed down
altogether.
This of course places a certain amount of pressure on the (internal) customer to be clear
about the business priorities and the features that would provide the greatest return on investment.
It also requires that the customer is ready and able to deploy the solutions into the business and
realize the intended benefits. In practice, programmers often take two or more 90-day cycles to
progress a particular solution to a point where it is fit for deployment. Even so, there is an
opportunity at the end of each cycle to assess what has been delivered so far, and to provide
feedback based on what has already been developed.

Metrics in Agile
45
Scaling to the Enterprise – The BT Agile Approach
At BT, the drive towards agile delivery started with an uncompromising determination to
introduce shorter delivery cycles across the entire delivery programmer portfolio, establish a
ruthless focus on delivering real business and end-customer value, and to nurture a strong
collaborative ethos between the IT and Business communities.
90-day cycles
With more or less immediate effect, all delivery programmes were required to adopt a
standard 90-day delivery cycle. That is, having picked up one or more distinct business problems
on day 1, a working solution is expected to be available, fully-tested, for deployment by the end
of the remaining 90 calendar days. For BT, this represented a seismic shift from the 12+ month
delivery cycles that were previously commonplace.
Each 90-day cycle is kick-started by an intensive 3-day "hot house" in which cross-
functional teams explore one or more business problems in some detail, with the main
stakeholder(s) usually being at hand to resolve any queries. Out of each hot house, the intention is
that one or more working prototypes are produced which, if accepted by the stakeholder, forms
the basis of the development activity for the remainder of the cycle.
For the remainder of each cycle, the intention is that wherever practical, programmes
pursue agile development practices such as more fine-grained iterative development (e.g. 2 – 4
weeks),
Step 2 – Focus on Delivering Business Value
Early in each delivery cycle, the programmed sets out clear targets for what it expects to
achieve for the business during that cycle. These targets invariably include a strong emphasis on
the end-customer experience, such as overall response times, transaction success rates, and so on.
At the end of the cycle, the programmed is assessed against these targets, and the outcome of this
assessment will influence the timing of bonus payments for the programmed team members.
Programmers failing to deliver business value over a series of cycles face being closed down
altogether.
This of course places a certain amount of pressure on the (internal) customer to be clear
about the business priorities and the features that would provide the greatest return on investment.
It also requires that the customer is ready and able to deploy the solutions into the business and
realize the intended benefits. In practice, programmers often take two or more 90-day cycles to

Metrics in Agile
46
progress a particular solution to a point where it is fit for deployment. Even so, there is an
opportunity at the end of each cycle to assess what has been delivered so far, and to provide
feedback based on what has already been developed.
Step 3 – Install a Collaborative approach
Truly successful programmers require a strong partnership approach between the business
customer and the development community. Within BT, close collaboration is established at the
outset of each project through attendance at the hot houses. The onus is then on the programme
teams to ensure this collaboration continues throughout the delivery cycle through design
walkthrough sessions, prototype reviews, and so on.
In practice, the end-user representatives you want to have at your hot house are also the
ones who are hardest to release from operational duties. With several programs running numerous
hot houses during the course of a year, this problem can quickly become compounded and often
makes it extremely difficult to achieve true collaboration on a day-to-day basis. However,
collective ownership of the eventual solution needs to become the accepted norm, and any practical
steps to enhance collaboration should be taken.
Conclusion
Re-orienting a large IT organization from pursuing well-established waterfall-based
delivery approach to being a truly agile delivery unit takes patience and time, as well as a lot of
commitment. In BT, where the initial steps towards enterprise agile delivery were taken late 2004,
there has been a noticeable and decisive shift away from waterfall-based thinking. It has also
transformed, quite radically, the traditional function of the IT department as a supplier of IT
services to one where IT is now seen as integral to all major business initiatives. Above all else, it
has created an attitude, bordering on obsession, of delivering real value to the business through IT.
Despite the early successes however, it is clear within BT that there is still a long way to go before
it can consider itself to be truly agile. For any large organization, the journey from waterfall to
agile can be very long and challenging. As with other proponents of Agile Development however,
few at BT would want to turn back to the old ways.

Metrics in Agile
47
CONCLUSION
Hence, we came to know that software metrics measures the detail or bit of programming
and serves to acquire the destinations and in addition the reproducible and quantifiable
measurements. This project represents information about the software metrics program; hence the
metrics implemented in this project are basic but very effective for an agile company. We could
perceive how the measurements are and the real handling of Scrum is and how successful scrum
arranging is. Agile organizations need metrics to control their processes as all other types of
software organizations do as well.
Also other agile methods such as Extreme Programming and Essential Rational unified
process can be seen through this. Extreme programming makes an attempt to reconcile humanity
and productivity, a mechanism for social change, a path to improvement and a style of
development. It can also be seen how EssUP cautiously integrates successful practices from the
unified process camp, the agile methods camp, and the process improvement camp, each
contributing different capabilities.
In developing this metrics project we followed a simplified version of the process described
in the ISO/IEC 15939 software measurement standard. Even thought our experience shows the
suitability of the standard for immature organizations interested in starting a metrics program, the
proposed process is too burdensome for small organizations in which most development teams are
less than ten people.
From the case studies we saw how the data clearly confirmed the hypothesis that the plans
are less accurate at the beginning, but improve from iteration to iteration. In the first Sprint the
planned velocity estimates were too optimistic and only one team out of 13 (i.e., team T04) actually
completed all functionality committed at the Sprint planning meeting. Thus analysis of results at
the Sprint retrospective meeting revealed two important reasons for such a great difference
between plans and actual achievement: non-compliance with the concept of ‘done’ and insufficient
communication with the Product Owner on the part of students.

Metrics in Agile
48
References:
1. https://www.scrumalliance.org/community/articles/2013/july/agile-project-reporting-and-
metrics
2. https://blog.sei.cmu.edu/post.cfm/agile-metrics-seven-categories-264
3. https://www.atlassian.com/agile/metrics
4. Information technology – Software engineering – Software measurement process, ISO/IEC
15939:2001, Secretariat, Canada (SCC)
5. https://www.scrumalliance.org/why-scrum
6. https://en.wikipedia.org/wiki/Scrum_(software_development)
7. http://christianleemiles.blogspot.com/2014/11/the-5-core-values-of-scrum.html
8. https://www.mountaingoatsoftware.com/agile/scrum/product-backlog
9. https://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog
10. https://gurtejpsingh.wordpress.com/2013/07/04/scrum-ceremonies-and-artifacts/
11. http://www.selectbs.com/process-maturity/what-is-extreme-programming
12. http://www.unf.edu/~broggio/cen6016/ExtremeProgramming%28XP%29Article.pdf
13. A Survey of Empirical Studies of Extreme Programming, by John Noll, Computer
Engineering Department, Santa Clara University
14. http://www.brighthubpm.com/methods-strategies/88996-the-extreme-programming-life-
cycle/#imgn_0
15. http://searchsoftwarequality.techtarget.com/tip/Waterfall-vs-Agile-development-A-case-
study
16. http://www.versionone.com/about-us/case-studies/
17. "Agile & Iterative Development" by Craig Larman, Addison-Wesley (2004) ISBN: 0-13-
111155-8
18. "Agile Software Development with Scrum" by Ken Schwaber & Mike Beedle, Prentice
Hall (2002) ISBN: 0-13-067634-9
19. "User Stories Applied for Agile Software Development" by Mike Cohn, Addison Wesley
(2004) ISBN: 0321205685
20. "Extreme Programming Explained" by Kent Beck & Cynthia Andres, Addison Wesley
(2004) ISBN: 0321278658

Metrics in Agile
49
21. "Lean Software Development – An Agile Toolkit" by Mary Poppendieck & Tom
Poppendieck, Addison Wesley (2003) ISBN: 0321150783
22. Agile Manifesto – http://www.agilemanifesto.org

Metrics in Agile: SCRUM, XP and Agile Methods

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Metrics in Agile: SCRUM, XP and Agile Methods

Similar to Metrics in Agile: SCRUM, XP and Agile Methods (20)

Recently uploaded

Recently uploaded (20)

Metrics in Agile: SCRUM, XP and Agile Methods