MODULE:2

AGILE
METHODOLOGY
Agile Processes – Lean Principles, Feature driven, behavior driven and test
driven
development, Scrum master, Product owner, Scrum and XP team, Agile
metrics
What is agile?

■ Agile is a process that allows a team to

more efficiently manage a project by
breaking it down into several stages,
each of which allows for consistent
collaboration with stakeholders to
promote steady improvements at every
stage.
■ In software development, agile practices
involve discovering requirements and
developing solutions through the
collaborative effort of self-organizing and
cross-functional teams and their
customer/end user.
Some of the real life examples of
agile model:

■ Restaurant orders:
– Preparation of some of the food before
opening the shop (sprint planning)
– continuous delivery of orders (adhoc stories)
– number of successful orders (velocity)
■ cricket team:
– Run rate (velocity)
– team (scrum team self sufficient)
– over (sprint length)
– captain/ coach (scrum master)
■ "Agile process model" refers to a software development approach
based on iterative development.
Phases of Agile Model:

■ Requirements gathering
■ Design the requirements
■ Construction/ iteration
■ Testing/ Quality assurance
■ Deployment
■ Feedback
■ Requirement Gathering:- In this step, the development team must gather the requirements, by
interaction with the customer. development team should plan the time and effort needed to build
the project. Based on this information you can evaluate technical and economical feasibility.
■ 2. Design the Requirements:- In this step, the development team will use user-flow-diagram or
high-level UML diagrams to show the working of the new features and show how they will apply to
the existing software. Wireframing and designing user interfaces are done in this phase.
■ 3. Construction / Iteration:- In this step, development team members start working on their
project, which aims to deploy a working product.
■ 4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing, and
System Testing. A brief introduction of these three tests is as follows:
■ 5. Unit Testing:- Unit testing is the process of checking small pieces of code to ensure that the
individual parts of a program work properly on their own. Unit testing is used to test individual
blocks (units) of code.
■ Integration Testing:- Integration testing is used to identify and resolve any issues that may
arise when different units of the software are combined.
■ System Testing:- Goal is to ensure that the software meets the requirements of the users and
that it works correctly in all possible scenarios.
■ 5. Deployment:- In this step, the development team will deploy the working project to end
users.
■ 6. Feedback:- This is the last step of the Agile Model. In this, the team receives feedback
about the product and works on correcting bugs based on feedback provided by the customer.
■ The time required to complete an iteration is known as a Time Box.
Time-box refers to the maximum amount of time needed to deliver an
iteration to customers. So, the end date for an iteration does not
change. However, the development team can decide to reduce the
delivered functionality during a Time-box if necessary to deliver it on
time. The Agile model’s central principle is delivering an increment to
the customer after each Time-box.
 3 C’s of Agile
■ Card
A card in user stories in Agile is a way of breaking down user stories into smaller,
more manageable tasks that can be easily monitored and identified. Each card may
include additional information such as priority level or estimated completion date for
further support of project management.
Conversation
The second C of Agile is a conversation, which emphasizes frequent communication
between team members to identify any possible changes or issues before they
become problems during development.
Confirmation
third C of Agile is confirmation, which allows customers to review and test features
before making them available in production environments. This helps to ensure
applications are error-free while also giving developers valuable insights into
customer preferences so they can make necessary improvements before release.
What are the 12 principles of
agile?
■ Customer satisfaction
■ Early and continuous delivery
■ Embrace change
■ Frequent delivery
■ Collaboration of businesses and developers
■ Motivated individuals
■ Face-to-face conversation
■ Functional products
■ Technical excellence
■ Simplicity
■ Self-organized teams
■ Regulation, reflection and adjustment
Agile methodology

■ Agile methodology is a type of project management process, mainly used for

software development, where demands and solutions evolve through the
collaborative effort of self-organizing and cross-functional teams and their
customers.
■ Agile software development refers to a group of software development
methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-
functional teams. Agile methods or Agile processes generally promote a
disciplined project management process that encourages frequent inspection
and adaptation, a leadership philosophy that encourages teamwork, self-
organization and accountability, a set of engineering best practices intended
to allow for rapid delivery of high-quality software, and a business approach
that aligns development with customer needs and company goals.
Examples of Agile Methodology

■ Agile Scrum Methodology.

■ Lean Software Development.
■ Kanban.
■ Extreme Programming (XP)
■ Crystal.
■ Dynamic Systems Development Method (DSDM)
■ Feature Driven Development (FDD)
scrum

■ The software development term scrum was first used in a 1986 paper titled "The New
Product Development Game". The term is borrowed from rugby, where a scrum is a
formation of players. The term scrum was chosen by the paper's authors because it
emphasizes teamwork.
■ Scrum is a subset of Agile. It is a lightweight process framework for agile development,
and the most widely-used one.
■ Scrum is an agile project management methodology or framework used primarily
for software development projects with the goal of delivering new software capability
every 2-4 weeks.

■ Scrum is an agile framework for developing, delivering, and sustaining complex

products, with an initial emphasis on software development, although it has been used
in other fields including research, sales, marketing and advanced technologies.
Agile scrum methodology

■ Agile scrum methodology is a project management system that relies on incremental

development. Each iteration consists of two- to four-week sprints, where each sprint's
goal is to build the most important features first and come out with a potentially
deliverable product. More features are built into the product in subsequent sprints
and are adjusted based on stakeholder and customer feedback between sprints.
■ Whereas other project management methods emphasize building an entire product in
one iteration from start to finish, agile scrum methodology focuses on delivering
several iterations of a product to provide stakeholders with the highest business
value in the least amount of time.
■ Agile scrum methodology has several benefits. First, it encourages products to be
built faster, since each set of goals must be completed within each sprint's time
frame. It also requires frequent planning and goal setting, which helps the scrum
team focus on the current sprint's objectives and increase productivity.
Lifecycle of Scrum:

■ Sprint:
A Sprint is a time-box of one month or less. A new Sprint starts
immediately after the completion of the previous Sprint.
■ Release:
When the product is completed then it goes to the Release
stage.
■ Sprint Review:
If the product still have some non-achievable features then it
will be checked in this stage and then the product is passed to
the Sprint Retrospective stage.
■ Sprint Retrospective:
In this stage quality or status of the product is checked.
■ Product Backlog:
According to the prioritize features the product is organized.
■ Sprint Backlog:
Sprint Backlog is divided into two parts Product assigned
features to sprint and Sprint planning meeting.
How Scrum Works

■ In a rugby scrum, all the players literally put their heads together. When it comes to software
development, a scrum can be characterized by
developers putting their heads together to address complex problems.
■ Scrum software development starts with a wish list of features — a.k.a. a product backlog. The
team meets to discuss:
– The backlog.
– What still needs to be completed.
– How long it will take.
■ Scrum relies on an agile software development concept called sprints:
– Sprints are periods of time when software development is actually done.
– A sprint usually lasts from one week to one month to complete an item from the backlog.
– The goal of each sprint is to create a saleable product.
– Each sprint ends with a sprint review.
– Then the team chooses another piece of backlog to develop — which starts a new sprint.
– Sprints continue until the project deadline or the project budget is spent.
■ In daily scrums, teams meet to discuss their progress since the previous meeting and make plans
for that day.
– The meetings should be brief — no longer than 15 minutes.
– Each team member needs to be present and prepared.
■ The ScrumMaster keeps the team focused on the goal.
How Scrum Works
Introduction to Scrum Terms

■ An introduction to Scrum would not be complete without knowing the

Scrum terms you'll be using. This section in the Scrum overview will
discuss common concepts in Scrum.
■ Scrum team: A typical scrum team has between five and nine
people, but Scrum projects can easily scale into the hundreds.
However, Scrum can easily be used by one-person teams and often is.
This team does not include any of the traditional software engineering
roles such as programmer, designer, tester or architect. Everyone on
the project works together to complete the set of work they have
collectively committed to complete within a sprint. Scrum teams
develop a deep form of camaraderie and a feeling that “we’re all in
this together.”
Who is in the Scrum?/Scrum
Terms
■ Product owner: The product owner is the project’s key stakeholder and
represents users, customers and others in the process. The product owner is
often someone from product management or marketing, a key stakeholder or
a key user.
■ Scrum Master: The Scrum Master is responsible for making sure the team is
as productive as possible. The Scrum Master does this by helping the team
use the Scrum process, by removing impediments to progress, by protecting
the team from outside, and so on.
■ Product backlog: The product backlog is a prioritized features list containing
every desired feature or change to the product. Note: The term “backlog” can
get confusing because it’s used for two different things. To clarify, the product
backlog is a list of desired features for the product. The sprint backlog is a list
of tasks to be completed in a sprint.
■ Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held,
during which the product owner presents the top items on the product backlog to the team.
The Scrum team selects the work they can complete during the coming sprint. That work is
then moved from the product backlog to a sprint backlog, which is the list of tasks needed to
complete the product backlog items the team has committed to complete in the sprint.
■ Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each day’s work and helps the team stay
on track. All team members are required to attend the daily scrum.
■ Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a demonstration of the new
features, but in an informal way; for example, PowerPoint slides are not allowed. The
meeting must not become a task in itself nor a distraction from the process.
■ Sprint retrospective: Also at the end of each sprint, the team conducts a sprint
retrospective, which is a meeting during which the team (including its ScrumMaster and
product owner) reflect on how well Scrum is working for them and what changes they may
wish to make for it to work even better.
■ Each of the Scrum terms has its own page within the Scrum section, so be sure to check out
all the pages in the navigation.
Scrum Master
■ A Scrum master is responsible for ensuring that the Scrum team
follows the processes that were agreed upon. Keeping obstacles and
distractions out of the team's path is one of the responsibilities of the
Scrum master. In this role, the individual acts as the interface
between the Scrum team and other people or teams.
■ n practice, however, a Scrum Master is working behind the scenes
and is not involved in product ideation or strategy. They work more as
a conduit between product/line-of-business owners and development
teams as a project manager. Because agile processes are entirely
dependent on people and collaboration.
■ A Scrum Master, on the other hand, maintains a high-level view,
helping teams to understand both organizational and technical
dependencies while avoiding chokepoints. This creates a culture of
accountability and enables teams to meet critical deadlines.
Scrum Master
Responsibilities
■ Implement Project Management/Best Practices
The Scrum Master is responsible for creating and onboarding project teams,
integrating them into the organization and providing a clear vision of the product.
The Scrum Master also facilitates communication and information exchange
between external groups and the project team. They also monitor project
progress, provide timely feedback, and drive a culture of agility and learning.
■ Keep all Parties on Track and Informed
The Scrum Master hosts daily team meetings to get updates on the progress of
the project, address potential roadblocks, and ensure that the project is on track.
They also host regular sessions to share updates with product stakeholders about
how the project is progressing (or not). Ultimately, it’s a Scrum Master’s job to
ensure that the team is meeting deadlines with the desired outcome.
Scrum Master
Responsibilities
■ Introduce Agile Engineering Practices
To improve efficiency, Scrum Masters encourage the use of continuous
integration (CI) and automation. With CI tools, developers integrate
chunks of code into a central repository frequently, from which
automated builds and tests run in successive iterations.
■ Coach Team Members
The Scrum Master serves as the coach for the development team and
the product owner. One of their key responsibilities is to ensure that the
team is adequately trained to understand Agile processes, the team
members know their specific roles and are dedicated to the project. Like
a true coach, the Scrum Master makes sure that the teams are self-
managed. They constantly look for ways to improve team performance
and productivity.
 Scrum Master
■
Responsibilities
Host Daily Stand-up Meetings
The Scrum Master keeps the team organized and on track by hosting daily stand-up meetings, sprint
planning meetings, sprint reviews, etc. In these brief meetings, teams discuss their accomplishments,
what they’re planning to do on that day, and if they are facing any obstacles while completing the
tasks. It’s the Scrum Master’s duty to ensure that all team members, even those working remotely
can attend and participate in the meetings.
■ Assist the Product Owner With the Product Backlog
Product backlog refers to the list of tasks that the team needs to do. It is the product owner’s
responsibility to create and maintain the product backlog, which keeps changing based on current
status of the work and development needs. The Scrum Master helps the product owner refine and
maintain the backlog by using information gathered from standup meetings. They schedule review
meetings and prioritize work on user stories.
■ Remove Roadblocks
The Scrum Master helps the team stay focused on tasks needed to be done in each iteration. For this,
the Master removes any distractions or roadblocks that can hinder the progress of the team. For
instance, if team members are forced into attending too many unimportant meetings, that can
hamper work. The Scrum Master can coordinate with the meeting organizers to ensure only those
members who are absolutely essential are required to attend each meeting. Alternatively, if someone
from the team is being asked to work on multiple teams, the Scrum Master can collaborate with
product owners and stakeholders to ensure the workload is redistributed
Scrum Master
Responsibilities
■ Teach Scrum Practices and Principles
The Scrum Master is well proficient in key Scrum practices and
processes. They play the role of a mentor to ensure smooth onboarding
of new employees and team members. The Scrum Master helps new
members understand the scope and vision of a product and ensures work
does not slow down. It is their task to make sure that the team follows
Scrum practices and rules while working. They teach the team ways to
stay self-organized and focused, which in turn improves productivity.
Scrum Master Roles
The scrum master's role in supporting product owners in the following aspects:
■ Find methods to effectively manage the product backlog.
■ Help communicate the owner’s wishlist to the project team.
■ Arrange and optimize product backlog.
■ Organize scrum events as necessary.

The scrum master's role in the organization in the following aspects:

■ Lead and coach scrum adoption.
■ Plan scrum implementation.
■ Implement changes and steps to increase the team’s productivity.
■ Collaborate with other scrum masters to improve the methodologies’
efficiency.
 A Visual Introduction to Scrum

This graphic is an introduction to the

essential elements of using Scrum for agile
software development. On the left, we see
the product backlog, which has been
prioritized by the product owner and
contains everything desired in the product
that’s known at the time. The two to four
week sprints are shown by the larger green
circle.
■ At the start of each sprint, the team selects some amount of work
from the product backlog and commits to completing that work during
the sprint. Part of figuring out how much they can commit to is
creating the sprint backlog, which is the list of tasks (and an estimate
of how long each will take) needed to deliver the selected set of
product backlog items to be completed in the sprint.
■ At the end of each sprint, the team produces a potentially shippable
product increment — i.e. working, high-quality software. Each day
during the sprint, team members meet to discuss their progress and
any impediments to completing the work for that sprint. This is known
as the daily scrum, and is shown as the smaller green circle above.
■ Scrum is the type of Agile framework. It is a framework within
which people can address complex adaptive problem while
productivity and creativity of delivering product is at highest possible
values. Scrum uses Iterative process.
Key Features of Scrum
Methodology
■ Scrum has a short fixed schedule of
release cycles with adjustable scope
known as sprints to address rapidly
changing development needs. Each
release could have multiple sprints.
Each Scrum Project could have
multiple Release Cycles.
■ A repeating sequence of meetings,
events, and milestones
■ A practice of testing and implementing
new requirements, known as stories,
to make sure some work is released
ready after each sprint
Who can benefit from scrum?

■ While scrum can benefit a wide variety of businesses and projects, these
are the most likely beneficiaries:
■ Complicated projects: Scrum methodology is ideal for projects that
require teams to complete a backlog.

■ Companies that value results: Scrum is also beneficial to companies

that value results over the documented progress of the process.

■ Companies that cater to customers: Scrum can help companies that

develop products in accordance with customer preferences and
specifications.
What are the benefits of agile scrum
methodology?

■ Here are some of the collective benefits of agile scrum methodology:

■ Flexibility and adaptability
■ Creativity and innovation
■ Lower costs
■ Quality improvement
■ Organizational synergy
■ Employee satisfaction
■ Customer satisfaction
Benefits of Scrum
■ Rugby players try to gain control of the ball in the scrum and move it downfield.
Software developers use scrum to move their projects quickly. And the benefits
trickle down to software developers:
■ Developers who want the freedom to make decisions thrive in scrum teams. Team
morale tends to be high.
■ Each sprint produces a product that is ready for market even though the project is
ongoing. The highest priority requirements are addressed first so a high-quality, low-
risk product can be on the market.
■ The incremental process shortens the time to market by about 30 percent to 40
percent. Because the product owner is part of the scrum team, requirements can be
delivered as they are needed.
■ Scrum projects often realize a higher return on investment (ROI). This is attributed to:
– Decreased time to market.
– Early and regular feedback that prompts course corrections early when they are
less costly.
– Defects that are fewer and less costly.
– Projects failing early and quickly when it’s less costly.
■ Reviewing each sprint before the team moves on to the next sprint spreads testing
throughout development.
■ Project focus and goals can change with evolving business goals.
Disadvantages of Scrum

■ While a rugby scrum may get rough and bloody, software developers
shouldn’t have to worry about that. Nonetheless, scrum is not for all
developer teams or software development projects. There are
disadvantages to implementing scrum projects:
■ There is a danger of scope creep if stakeholders keep adding
functionality to the backlog. This could be encouraged by the fixed
deadline.
■ Scrum works best with small teams of experienced software
developers. They need to be able to work quickly.
■ Scrum teams do not work well when the scrum master micromanages
their work.
■ Losing any team members can hurt the progress of the project.
Scrum Best Practices
■ Teamwork wins rugby games and helps software developers create
quality products. To get the best quality out of scrum:
■ Define requirements just in time to keep product features as relevant as
possible.
■ Test and incorporate product owner feedback daily.
■ Sprint reviews with stakeholders need to be regular.
■ The scrum team needs to use the sprint retrospectives to improve how
they work.
■ Conduct face-to-face conversations to reduce miscommunications.
■ Trust the teams to do the best job possible.
■ Allow the teams to self-organize around people’s skills, work styles and
personalities.
■ Don’t burn out the team members. Respect the balance between their
personal and professional lives to ease stress.
When you should use Scrum

■ Scrum is excellent for dealing with complex projects in changing

environments. Like many Agile methodologies, Scrum is good for
industries that are continuously changing or pioneering new projects.
 EXTREME
PROGRAMMING
■ XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and
fun way to develop a software.
■ eXtreme Programming (XP) was conceived and developed to address the
specific needs of software development by small teams in the face of vague
and changing requirements.
■ Extreme Programming is one of the Agile software development
methodologies. It provides values and principles to guide the team
behavior. The team is expected to self-organize. Extreme Programming
provides specific core practices where −
■ Each practice is simple and self-complete.
■ Combination of practices produces more complex and emergent behavior.
Agile methods

■ Dissatisfaction with the overheads involved in design

methods led to the creation of agile methods. These
methods:
– Focus on the code rather than the design;
– Are based on an iterative approach to software development;
– Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
■ Agile methods are probably best suited to small/medium-
sized business systems or PC products.
 Principles of agile methods
Principle Description
Customer involvement The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
Embrace change Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.
Problems with agile methods

■ It can be difficult to keep the interest of customers who are

involved in the process.
■ Team members may be unsuited to the intense involvement
that characterises agile methods.
■ Prioritising changes can be difficult where there are multiple
stakeholders.
■ Maintaining simplicity requires extra work.
■ Contracts may be a problem as with other approaches to
iterative development.
Extreme programming

■ Perhaps the best-known and most widely used agile method.

■ Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2 weeks;
– All tests must be run for every build and the build is only accepted
if tests run successfully.
The XP release cycle

Select user
Break down
stories for this Plan release
stories to tasks
release

Evaluate Release Develop/integ

rate/
system software test software
Extreme programming practices 1

Incremental planning Requirements are recorded on Story Cards and the Stories to be
included in a release are determined by the time available and
their relative priority. The developers break these Stories into
development Ô TasksÕ .
Small Releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.
Simple Design Enough design is carried out to meet the current requirements
and no more.
Test first development An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.
Extreme programming practices 2

Pair Programming Developers work in pairs, checking each otherÕ s work and
providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all the
code. Anyone can change anything.
Continuous Integration As soon as work on a task is complete it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as the
net effect is often to reduce code quality and medium term
productivity
On-site Customer A representative of the end-user of the system (the Customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
XP and agile principles

■ Incremental development is supported through small,

frequent system releases.
■ Customer involvement means full-time customer
engagement with the team.
■ People not process through pair programming, collective
ownership and a process that avoids long working hours.
■ Change supported through regular system releases.
■ Maintaining simplicity through constant refactoring of
code.
Customer involvement

■ Customer involvement is a key part of XP where the customer is part

of the development team.
■ The role of the customer is:
– To help develop stories that define the requirements
– To help prioritise the features to be implemented in each release
– To help develop acceptance tests which assess whether or not the
system meets its requirements.
Requirements scenarios

■ In XP, user requirements are expressed as scenarios or user stories.

■ These are written on cards and the development team break them
down into implementation tasks. These tasks are the basis of
schedule and cost estimates.
■ The customer chooses the stories for inclusion in the next release
based on their priorities and the schedule estimates.
Story card for document downloading

Downloading and printing an article

First, you select the article that you want from a displayed list. You
then have to tell the system how you will pay for it - this can either
be through a subscription, through a company account or by credit
card.

After this, you get a copyright form from the system to fill in and,
when you have submitted this, the article you want is downloaded
onto your computer.

You then choose a printer and a copy of the article is printed. You
tell the system if printing has been successful.

If the article is a print-only article, you canÕ t keep the PDF version
so it is automatically deleted from your computer .
XP and change

■ Conventional wisdom in software engineering is to design

for change. It is worth spending time and effort
anticipating changes as this reduces costs later in the life
cycle.
■ XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated.
■ Rather, it proposes constant code improvement
(refactoring) to make changes easier when they have to
be implemented.
Refactoring

■ Refactoring is the process of code improvement where

code is reorganised and rewritten to make it more
efficient, easier to understand, etc.
■ Refactoring is required because frequent releases mean
that code is developed incrementally and therefore tends
to become messy.
■ Refactoring should not change the functionality of the
system.
■ Automated testing simplifies refactoring as you can see if
the changed code still runs the tests successfully.
Testing in XP

■ Test-first development.
■ Incremental test development from scenarios.
■ User involvement in test development and validation.
■ Automated test harnesses are used to run all component tests each
time that a new release is built.
Task cards for document downloading

Task 1: Implement principal workflow

Task 2: Implement article catalog and selection

Task 3: Implement payment collection

Payment may be made in 3 dif ferent ways. The user

selects which way they wish to pay . If the user
has a library subscription, then they can input the
subscriber key which should be checked by the
system. Alternatively , they can input an or ganisational
account number . If this is valid, a debit of the cost
of the article is posted to this account. Finally , they
may input a 16 digit credit card number and expiry
date. This should be checked for validity and, if
valid a debit is posted to that credit card account.
Test case description
Test 4: Test credit card validity
Input:
A string representing the credit card number and two integers representing
the month and year when the card expires
Tests:
Check that all bytes in the string are digits
Check that the month lies between 1 and 12 and the
year is greater than or equal to the current year .
Using the first 4 digits of the credit card number ,
check that the card issuer is valid by looking up the
card issuer table. Check credit card validity by submitting the card
number and expiry date information to the card
issuer
Output:
OK or error message indicating that the card is invalid
Test-first development

■ Writing tests before code clarifies the requirements to be

implemented.
■ Tests are written as programs rather than data so that they can be
executed automatically. The test includes a check that it has executed
correctly.
■ All previous and new tests are automatically run when new
functionality is added. Thus checking that the new functionality has
not introduced errors.
Pair programming

■ In XP, programmers work in pairs, sitting together to

develop code.
■ This helps develop common ownership of code and
spreads knowledge across the team.
■ It serves as an informal review process as each line of
code is looked at by more than 1 person.
■ It encourages refactoring as the whole team can benefit
from this.
■ Measurements suggest that development productivity
with pair programming is similar to that of two people
working independently.
 XP Key Roles and
■Responsibilities
The Customer: There should be an actual customer on-site to
prioritize user stories, answer questions, and collaborate with
acceptance testing. If there is no one available, the customer should
appoint a representative.
■ The Programmers: Programmers estimate how much work it takes to
finish tasks and stories, write the automated tests, and implement
customer stories.
■ The Coach: Not every team needs a leader, but sometimes this role is
required to make sure everyone follows the practices consistently
enough to turn into habits and ensure that team members don't lapse
into old patterns.
■ The Tracker: As the name implies, the tracker keeps track of the
team’s progress metrics, including identifying obstacles and devising
workarounds.
Problems with XP

■ Customer involvement
– This is perhaps the most difficult problem. It may be difficult or
impossible to find a customer who can represent all stakeholders
and who can be taken off their normal work to become part of the
XP team. For generic products, there is no ‘customer’ - the
marketing team may not be typical of real customers.
Problems with XP

■ Architectural design
– The incremental style of development can mean that
inappropriate architectural decisions are made at an early stage
of the process.
– Problems with these may not become clear until many features
have been implemented and refactoring the architecture is very
expensive.
■ Test complacency
– It is easy for a team to believe that because it has many tests, the
system is properly tested.
– Because of the automated testing approach, there is a tendency
to develop tests that are easy to automate rather than tests that
are ‘good’ tests.
Key points

■ Extreme programming includes practices such as

systematic testing, continuous improvement and customer
involvement.
■ Customers are involved in developing requirements which
are expressed as simple scenarios.
■ The approach to testing in XP is a particular strength
where executable tests are developed before the code is
written.
■ Key problems with XP include difficulties of getting
representative customers and problems of architectural
design.
Key points
differences between extreme
programming and scrum.
comparison
When Applicable

■ Dynamically changing software requirements

■ Risks caused by fixed time projects using new technology
■ Small, co-located extended development team
■ The technology you are using allows for automated unit and functional
tests
Lean Principles

■ ean was born out of manufacturing practices but in recent time has
transformed the world of knowledge work and management. It
encourages the practice of continuous improvement and is based on
the fundamental idea of respect for people. Womack and Jones
defined the five principles of Lean manufacturing in their book “The
Machine That Changed the World”. The five principles are considered
a recipe for improving workplace efficiency and include: 1) defining
value, 2) mapping the value stream, 3) creating flow, 4) using a pull
system, and 5) pursuing perfection.
■ 1. Defining Value
■ Identifying value in a lean project is always defined by what the customer needs for the product. This might mean the time to market, pricing or
other expectations that must be met. This is the core principle and must be shared with everyone involved in the project so they always work with
the customer’s needs in mind.
■ 2. Value Stream Mapping
■ After you’ve defined the value for your end-user, next you need to map the value stream. This means defining all of the steps and related processes
that take your product from raw material to final deliverable. You can also identify the actions to produce your product in design, procurement, HR,
administration, delivery and customer service. The map should be on only one page and you should remove any steps that offer no value to the
customer.
■ 3. Create Flow
■ Once you’ve removed the waste from your value stream, it’s time to ensure those steps flow smoothly from one to another. You don’t want any
interruptions, delays or bottlenecks that can slow down production and threaten your schedule and budget. To do this, you want the value stream
steps to be in a tight sequence. This leads to cross-functional teams that work together across departments to create greater productivity.
■ 4. Establish Pull
■ “Pull” means that the customer can pull the product with a shorter production cycle, often turning what could have been months into weeks. This
lets you avoid having to build in advance or stockpile materials, which saves on inventory costs that can be passed on to your customers. This is all
dependent on the flow you created in the previous step.
■ 5. Continuous Improvement (Kaizen)
■ If the first step is the most important of the five lean principles, this step is a close second. It means approaching perfection in all aspects of your
corporate culture. Specifically, you want to use this step to loop you back to the first step. Yes, you should never stop following these steps. This
continuous improvement, also referred to by the Japanese word kaizen, is essential to lean project management.
What is FDD in Agile?

■ An Agile methodology for developing software, Feature-Driven

Development (FDD) is customer-centric, iterative, and incremental,
with the goal of delivering tangible software results often and
efficiently. FDD in Agile encourages status reporting at all levels,
which helps to track progress and results.
How Does FDD Work?

■ ypically used in large-scale development projects, five basic activities

exist during FDD:
■ Develop overall model
■ Build feature list
■ Plan by feature
■ Design by feature
■ Build by feature
How is a Feature Defined?

■ In FDD, each feature is useful and important to the client and results
in something tangible to showcase. And because businesses
appreciate quick results, the methodology depends on its two-week
cycle.
FDD
■
Lifecycle
Build overall model
■ Build feature list
■ Plan by feature
■ Design by feature
■ Build by feature
Stages of Feature-Driven
Development
■ Stage 0: Gather Data
■ Develop an overall model
■ Build a features list
Advantages of FDD

■ Reporting at all levels leads to easier progress tracking.

■ FDD provides continuous success for larger size of teams and
projects.
■ Reduction in risks is observed as whole model and design is build in
smaller segments.
■ FDD provides greater accuracy in cost estimation of the project due to
feature segmentation.
Disadvantages of FDD

■ This agile practice is not good for smaller projects.

■ There is high dependency on lead programmers, designers and
mentors.
■ There is lack of documentation which can create an issue afterwards.
Behavioral Driven
Development
■ Behavioral Driven Development (BDD) refers to an
Agile software development process that is derived from the
TDD (Test Driven Development) methodology. BDD is considered as a
test to illustrate the behavior of the system. It encourages the use of
conversation and concrete examples in simple language for
■ Behavioral Driven Development is a good approach in
Automated Testing as it is more focused on the behavior of the system
rather than the implementation of the code. BDD is facilitated through
natural language to express the behavior of the system and the
expected outcomes from the system. In BDD all parties are involved
like a customer, developer, tester, and stakeholder for a collaborated
conversation and illustration of the system’s behavior.
Behavior-Driven
Development In Agile
Development :
■ The client and service provider have a conversation about what they
need.
■ The client/customer, developer, and tester elaborate on the
requirements together.
■ Then requirements are defined in structured scenarios.
■ They help in the development and act as automated tests,
■ These scenarios are used by the testers as the basis of tests.
BDD Life Cycle :
■ Describe behavior –
This includes the flow and features of the product means the main
vision.
■ Define requirements –
Modeled requirements with business rules for a shared understanding.
■ Run and fail the tests –
Develop and run the test cases.
■ Apply code update –
Refactor it according to the requirement.
■ Run and pass the tests –
Run the updated code and pass the test cases.
Limitations of Behavioral
Driven Development
■ BDD can be time-consuming to create and maintain extensive
documentation, including user stories, acceptance criteria, and step
definitions.
■ Involving all stakeholders, especially non-technical stakeholders, can
be a challenge.
■ BDD tests heavily rely on the quality of initial requirements and user
stories; incomplete or inaccurate requirements can lead to insufficient
test coverage and bugs.
■ BDD may not be suitable for short development cycles or projects
with frequently changing requirements.
Benefits of Behavioral Driven
Development :
■ Greater clarity on business goals and customer requirements.Reaches a larger
customer set as it uses non-technical languages.Helps in defining acceptance
criteria before development.Focuses on the system’s behavior from the client’s
and developer’s point of view.Helps in avoiding unnecessary features and includes
important features.Reduces effort for post-modification and post-deployment
defects.Avoids misinterpretations during the development process.Collaboration
between team members is promoted through BDD, involving all stakeholders in the
development process to ensure a shared understanding of objectives.Automated
testing tools are encouraged, reducing testing time and effort and enabling faster
detection and resolution of issues.Integration with Continuous Integration and
Delivery processes can automate build, testing, and deployment of software,
resulting in faster feedback loops and delivery of features.Detailed documentation
of user stories, acceptance criteria, and step definitions can improve overall
project documentation, facilitating maintenance and updates to the system.
Test Driven Development
(TDD)
■ Test Driven Development is the process in which test cases are
written before the code that validates those cases. It depends on
repetition of a very short development cycle. Test driven Development
is a technique in which automated Unit test are used to drive the
design and free decoupling of dependencies.
■ The following sequence of steps is generally followed:
■ Add a test – Write a test case that describe the function completely. In
order to make the test cases the developer must understand the
features and requirements using user stories and use cases.
■ Run all the test cases and make sure that the new test case fails.
■ Write the code that passes the test case
■ Run the test cases
■ Refactor code – This is done to remove duplication of code.
■ Repeat the above mentioned steps again and again
Red – Create a test case and make it
fail
Green – Make the test case pass by
any means.
Refactor – Change the code to remove
duplicate/redundancy.
Benefits:

■ Unit test provides constant feedback about the functions.

■ Quality of design increases which further helps in proper
maintenance.
■ Test driven development act as a safety net against the bugs.
■ TDD ensures that your application actually meets requirements
defined for it.
■ TDD have very short development lifecycle.
 93

Kanban
• Lean approach to agile development

• Similar to Scrum in the sense that you focus on features as

opposed to groups of features – however Lean takes this one
step further again.

• You select, plan, develop, test and deploy one feature (in its
simplest form) before you select, plan, develop, test and deploy
the next feature.

• Aim is to eliminate ‘waste’ wherever possible…

Dr. V. Sakthivel & Dr.K.P.Vijayakumar AP(Sr.G)

 Kanban (contd…) 94

Visualize the workflow

• Split the work into pieces, write each
item on a card and put on the wall
• Use named columns to illustrate where
each item is in the workflow
Limit WIP (work in progress)

Dr. V. Sakthivel & Dr.K.P.Vijayakumar AP(Sr.G)

Kanban (contd…) 95

• Assign explicit limits to how many items may be in progress at each stage
Measure the lead time (average time to complete one item, sometimes called
“cycle time”)
• Optimize the process to make lead time as small and predictable as
possible

Dr. V. Sakthivel & Dr.K.P.Vijayakumar AP(Sr.G)

Kanban Board Illustration - I 96

Dr. V. Sakthivel & Dr.K.P.Vijayakumar AP(Sr.G)

Kanban Board Illustration - II 97

Dr. V. Sakthivel & Dr.K.P.Vijayakumar AP(Sr.G)

agile metrics

■ Agile metrics is a tool that helps marketing teams measure the progress and
productivity of marketing activities, stay on track, and address roadblocks. Agile
metrics are most effective when tailored to the specific needs of individual
projects.
■ both quantitative and qualitative data comes in. Agile metrics help agile teams
set benchmarks, measure against goals, and evaluate performance. Agile
metrics typically assess productivity, predictability, quality, or value in some way.
■ The metrics you choose will vary based on your goals, organization, and
development team. For example, the most common agile metrics for scrum
teams are burndown and velocity — while kanban teams typically track cycle
time, throughput, and work in progress (WIP). But in this guide, you will also find
plenty of methodology-agnostic metrics to choose from.
■ 37 agile metrics for development teams
Types of Agile Metrics

■ Agile business metrics

■ Scrum metrics
■ Kanban metrics
■ SAFe® metrics
■ Agile code metrics
Agile business metrics
 Scrum metrics

Team capacity Find insights in context

Type of work Sprint retrospective
Stand-ups (a.k.a daily scrum) Sprint goal completion
Sprint satisfaction
13 considerations for successful Sprint
planning
■ Sprint duration
■ Visibility into product roadmap
■ Requirements clarity
■ Sprint distribution
■ Details of user stories
■ Prioritization
■ Acceptance criteria & test cases
■ Story point values
■ Estimation accuracy
■ Story points calculation bias
■ Story point mix
■ Distribution of workload between teams
■ Dependencies and interactions
 Sprint burndown

■ 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.
 Team velocity
■ How much a team can commit to a sprint essentially boils down to velocity, or
how much work it can accomplish during a given time, as well as capacity, or
how much availability it has.
■ This helps us to predict the volume of work a team can perform for future
sprints. A team’s velocity can only be understood after running a few sprints
together as a team. Over time velocity will stabilize as a result of a team
working together. This involves not only ramping up on technologies used but
also understanding each other’s expertise and learning how to work as a team.
■ (1) estimation statistic based on story points, (2) commitment, which
is an estimate of all issues in the sprint, (3) completed estimates, and
(4) sprints completed.
Workload distribution
■ The following examples will provide you with a succinct overview of
how to allocate workload and get full control of it.
■ Suppose you have an 8-hour working day and a task that is estimated
to be completed in 24 hours 1. Once you assign this task to a project
participant, you will see in the Workload window that this person has 8
hours each day distributed between 3 working days 2.
■ This is a perfect workload distribution.
■ Now, suppose that you have two tasks that are estimated to be
completed in 24 hours within the same timeframe each 3. If you
assign those tasks to one project participant, his or her workload will
be 16 hours per day 4 which is a clear overload.
Kanban metrics

■ Blocked time
■ Control chart
■ Cumulative flow diagram
■ Cycle time
■ Lead time
■ Queue length
■ Throughput
■ Work in progress (WIP)
■ Work item age
SAFe metrics
Agile engineering and code metrics

■ Code coverage
■ Code quality
■ Code review time
■ Defect resolution time
■ Defect density
■ Deployment frequency
■ Escaped defects
■ Failed deployments
■ Production downtime
■ Quality intelligence
■ Release frequency
project schedule in traditional
software development
iteration cycle of an Agile project