UNIT I

AGILE SOFTWARE DEVELOPMENT

BASICS AND FUNDAMENTALS OF AGILE PROCESS METHODS:

Agile Software Development is a software development methodology that values flexibility,
collaboration, and customer satisfaction. It is based on the Agile Manifesto, a set of principles for
software development that prioritize individuals and interactions, working software, customer
collaboration, and responding to change.
Agile Software Development is an iterative and incremental approach to software development that
emphasizes the importance of delivering a working product quickly and frequently. It involves close
collaboration between the development team and the customer to ensure that the product meets their
needs and expectations.

Table of Content
 Why Agile is Used?
 4 Core Values of Agile Software Development
 12 Principles of Agile Software Development Methodology
 The Agile Software Development Process:
 Agile Software development cycle:
 Design Process of Agile software Development:
 Example of Agile Software Development:
 Advantages Agile Software Development:
 Disadvantages Agile Software Development:
 Practices of Agile Software Development:
 Advantages of Agile Software Development over traditional software development approaches:
Why Agile is Used?
1. Creating Tangible Value: Agile places a high priority on creating tangible value as soon as
possible in a project. Customers can benefit from early delivery of promised advantages and
opportunity for prompt feedback and modifications.
2. Concentrate on Value-Added Work: Agile methodology promotes teams to concentrate on
producing functional and value-added product increments, hence reducing the amount of time and
energy allocated to non-essential tasks.
3. Agile as a Mindset: Agile represents a shift in culture that values adaptability, collaboration,
and client happiness. It gives team members more authority and promotes a cooperative and upbeat
work atmosphere.
4. Quick Response to Change: Agile fosters a culture that allows teams to respond swiftly to
constantly shifting priorities and requirements. This adaptability is particularly useful in sectors of
the economy or technology that experience fast changes.
5. Regular Demonstrations: Agile techniques place a strong emphasis on regular demonstrations
of project progress. Stakeholders may clearly see the project’s status, upcoming problems, and
upcoming new features due to this transparency.
6. Cross-Functional Teams: Agile fosters self-organizing, cross-functional teams that share
information effectively, communicate more effectively and feel more like a unit.
4 Core Values of Agile Software Development
The Agile Software Development Methodology Manifesto describe four core values of Agile in
software development.
4 Values of Agile
1. Individuals and Interactions over Processes and Tools
2. Working Software over Comprehensive Documentation
3. Customer Collaboration over Contract Negotiation
4. Responding to Change over Following a Plan
12 Principles of Agile Software Development
The Agile Manifesto is based on four values and twelve principles that form the basis, for
methodologies.

12 Principles of Agile Methodology

These principles include:
1. Ensuring customer satisfaction through the early delivery of software.
2. Being open to changing requirements in the stages of the development.
3. Frequently delivering working software with a main focus on preference for timeframes.
4. Promoting collaboration between business stakeholders and developers as an element.
5. Structuring the projects around individuals. Providing them with the necessary environment
and support.
6. Prioritizing face to face communication whenever needed.
7. Considering working software as the measure of the progress.
8. Fostering development by allowing teams to maintain a pace indefinitely.
9. Placing attention on excellence and good design practices.
10. Recognizing the simplicity as crucial factor aiming to maximize productivity by minimizing the
work.
11. Encouraging self organizing teams as the approach to design and build systems.
12. Regularly reflecting on how to enhance effectiveness and to make adjustments accordingly.
The Agile Software Development Process

Agile Software Development

1. Requirements Gathering: The customer’s requirements for the software are gathered and
prioritized.
2. Planning: The development team creates a plan for delivering the software, including the
features that will be delivered in each iteration.
3. Development: The development team works to build the software, using frequent and rapid
iterations.
4. Testing: The software is thoroughly tested to ensure that it meets the customer’s requirements
and is of high quality.
5. Deployment: The software is deployed and put into use.
6. Maintenance: The software is maintained to ensure that it continues to meet the customer’s
needs and expectations.
Agile Software Development is widely used by software development teams and is considered to be a
flexible and adaptable approach to software development that is well-suited to changing requirements
and the fast pace of software development.
Agile is a time-bound, iterative approach to software delivery that builds software incrementally from
the start of the project, instead of trying to deliver all at once.
Agile Software development cycle
Let’s see a brief overview of how development occurs in Agile philosophy.
1. concept
2. inception
3. iteration/construction
4. release
5. production
6. retirement

Agile software development cycle

 Step 1: In the first step, concept, and business opportunities in each possible project are
identified and the amount of time and work needed to complete the project is estimated. Based on
their technical and financial viability, projects can then be prioritized and determined which ones
are worthwhile pursuing.
 Step 2: In the second phase, known as inception, the customer is consulted regarding the initial
requirements, team members are selected, and funding is secured. Additionally, a schedule
outlining each team’s responsibilities and the precise time at which each sprint’s work is expected
to be finished should be developed.
 Step 3: Teams begin building functional software in the third step, iteration/construction, based
on requirements and ongoing feedback. Iterations, also known as single development cycles, are
the foundation of the Agile software development cycle.
Design Process of Agile software Development
 In Agile development, Design and Implementation are considered to be the central activities in
the software process.
 The design and Implementation phase also incorporates other activities such as requirements
elicitation and testing.
 In an agile approach, iteration occurs across activities. Therefore, the requirements and the
design are developed together, rather than separately.
 The allocation of requirements and the design planning and development as executed in a series
of increments. In contrast with the conventional model, where requirements gathering needs to be
completed to proceed to the design and development phase, it gives Agile development an extra
level of flexibility.
 An agile process focuses more on code development rather than documentation.
Example of Agile Software Development
Let’s go through an example to understand clearly how agile works. A Software company
named ABC wants to make a new web browser for the latest release of its operating system. The
deadline for the task is 10 months. The company’s head assigned two teams named Team A and Team
B for this task. To motivate the teams, the company head says that the first team to develop the browser
would be given a salary hike and a one-week full-sponsored travel plan. With the dreams of their wild
travel fantasies, the two teams set out on the journey of the web browser. Team A decided to play by
the book and decided to choose the Waterfall model for the development. Team B after a heavy
discussion decided to take a leap of faith and choose Agile as their development model. The
Development Plan of the Team A is as follows:
 Requirement analysis and Gathering – 1.5 Months
 Design of System – 2 Months
 Coding phase – 4 Months
 System Integration and Testing – 2 Months
 User Acceptance Testing – 5 Weeks
The Development Plan for the Team B is as follows:
 Since this was an Agile, the project was broken up into several iterations.
 The iterations are all of the same time duration.
 At the end of each iteration, a working product with a new feature has to be delivered.
 Instead of Spending 1.5 months on requirements gathering, they will decide the core features
that are required in the product and decide which of these features can be developed in the first
iteration.
 Any remaining features that cannot be delivered in the first iteration will be delivered in the
next subsequent iteration, based on the priority.
 At the end of the first iterations, the team will deliver working software with the core basic
features.
The team has put their best efforts into getting the product to a complete stage. But then out of the blue
due to the rapidly changing environment, the company’s head came up with an entirely new set of
features that wanted to be implemented as quickly as possible and wanted to push out a working model
in 2 days. Team A was now in a fix, they were still in their design phase and had not yet started coding
and they had no working model to display. Moreover, it was practically impossible for them to
implement new features since the waterfall model there is not revert to the old phase once you proceed
to the next stage, which means they would have to start from square one again. That would incur heavy
costs and a lot of overtime. Team B was ahead of Team A in a lot of aspects, all thanks to Agile
Development. They also had a working product with most of the core requirements since the first
increment. And it was a piece of cake for them to add the new requirements. All they had to do was
schedule these requirements for the next increment and then implement them.
Advantages Agile Software Development
 Deployment of software is quicker and thus helps in increasing the trust of the customer.
 Can better adapt to rapidly changing requirements and respond faster.
 Helps in getting immediate feedback which can be used to improve the software in the next
increment.
 People – Not Process. People and interactions are given a higher priority than processes and
tools.
 Continuous attention to technical excellence and good design.
 Increased collaboration and communication: Agile Software Development
Methodology emphasize collaboration and communication among team members, stakeholders,
and customers. This leads to improved understanding, better alignment, and increased buy-in from
everyone involved.
 Flexibility and adaptability: Agile methodologies are designed to be flexible and adaptable,
making it easier to respond to changes in requirements, priorities, or market conditions. This allows
teams to quickly adjust their approach and stay focused on delivering value.
 Improved quality and reliability: Agile methodologies place a strong emphasis on testing,
quality assurance, and continuous improvement. This helps to ensure that software is delivered
with high quality and reliability, reducing the risk of defects or issues that can impact the user
experience.
 Enhanced customer satisfaction: Agile methodologies prioritize customer satisfaction and
focus on delivering value to the customer. By involving customers throughout the development
process, teams can ensure that the software meets their needs and expectations.
 Increased team morale and motivation: Agile methodologies promote a collaborative,
supportive, and positive work environment. This can lead to increased team morale, motivation,
and engagement, which can in turn lead to better productivity, higher quality work, and improved
outcomes.
Disadvantages Agile Software Development
 In the case of large software projects, it is difficult to assess the effort required at the initial
stages of the software development life cycle.
 Agile Development is more code-focused and produces less documentation.
 Agile development is heavily dependent on the inputs of the customer. If the customer has
ambiguity in his vision of the outcome, it is highly likely that the project to get off track.
 Face-to-face communication is harder in large-scale organizations.
 Only senior programmers are capable of making the kind of decisions required during the
development process. Hence, it’s a difficult situation for new programmers to adapt to the
environment.
 Lack of predictability: Agile Development relies heavily on customer feedback and
continuous iteration, which can make it difficult to predict project outcomes, timelines, and budgets.
 Limited scope control: Agile Development is designed to be flexible and adaptable, which
means that scope changes can be easily accommodated. However, this can also lead to scope creep
and a lack of control over the project scope.
 Lack of emphasis on testing: Agile Development places a greater emphasis on delivering
working code quickly, which can lead to a lack of focus on testing and quality assurance. This can
result in bugs and other issues that may go undetected until later stages of the project.
 Risk of team burnout: Agile Development can be intense and fast-paced, with frequent sprints
and deadlines. This can put a lot of pressure on team members and lead to burnout, especially if the
team is not given adequate time for rest and recovery.
 Lack of structure and governance: Agile Development is often less formal and structured
than other development methodologies, which can lead to a lack of governance and oversight. This
can result in inconsistent processes and practices, which can impact project quality and outcomes.
Agile is a framework that defines how software development needs to be carried on. Agile is not a
single method, it represents the various collection of methods and practices that follow the value
statements provided in the manifesto. Agile methods and practices do not promise to solve every
problem present in the software industry (No Software model ever can). But they sure help to establish
a culture and environment where solutions emerge.
Agile software development is an iterative and incremental approach to software development. It
emphasizes collaboration between the development team and the customer, flexibility, and adaptability
in the face of changing requirements, and the delivery of working software in short iterations.
The Agile Manifesto, which outlines the principles of agile development, values individuals and
interactions, working software, customer collaboration, and response to change.
Practices of Agile Software Development
 Scrum: Scrum is a framework for agile software development that involves iterative cycles
called sprints, daily stand-up meetings, and a product backlog that is prioritized by the customer.
 Kanban: Kanban is a visual system that helps teams manage their work and improve their
processes. It involves using a board with columns to represent different stages of the development
process, and cards or sticky notes to represent work items.
 Continuous Integration: Continuous Integration is the practice of frequently merging code
changes into a shared repository, which helps to identify and resolve conflicts early in the
development process.
 Test-Driven Development: Test-Driven Development (TDD) is a development practice that
involves writing automated tests before writing the code. This helps to ensure that the code meets
the requirements and reduces the likelihood of defects.
 Pair Programming: Pair programming involves two developers working together on the same
code. This helps to improve code quality, share knowledge, and reduce the likelihood of defects.
Advantages of Agile Software Development over traditional software development approaches
1. Increased customer satisfaction: Agile development involves close collaboration with the
customer, which helps to ensure that the software meets their needs and expectations.
2. Faster time-to-market: Agile development emphasizes the delivery of working software in
short iterations, which helps to get the software to market faster.
3. Reduced risk: Agile development involves frequent testing and feedback, which helps to
identify and resolve issues early in the development process.
4. Improved team collaboration: Agile development emphasizes collaboration and
communication between team members, which helps to improve productivity and morale.
5. Adaptability to change: Agile Development is designed to be flexible and adaptable, which
means that changes to the project scope, requirements, and timeline can be accommodated easily.
This can help the team to respond quickly to changing business needs and market demands.
6. Better quality software: Agile Development emphasizes continuous testing and feedback,
which helps to identify and resolve issues early in the development process. This can lead to
higher-quality software that is more reliable and less prone to errors.
7. Increased transparency: Agile Development involves frequent communication and
collaboration between the team and the customer, which helps to improve transparency and
visibility into the project status and progress. This can help to build trust and confidence with the
customer and other stakeholders.
8. Higher productivity: Agile Development emphasizes teamwork and collaboration, which
helps to improve productivity and reduce waste. This can lead to faster delivery of working
software with fewer defects and rework.
9. Improved project control: Agile Development emphasizes continuous monitoring and
measurement of project metrics, which helps to improve project control and decision-making. This
can help the team to stay on track and make data-driven decisions throughout the development
process.
In summary, Agile software development is a popular approach to software development that
emphasizes collaboration, flexibility, and the delivery of working software in short iterations. It has
several advantages over traditional software development approaches, including increased customer
satisfaction, faster time-to-market, and reduced risk.
WHAT IS LEAN SOFTWARE DEVELOPMENT?

Lean software development is a concept that emphasizes optimizing efficiency and minimizing waste
in the software development process. This approach has its roots in the Lean manufacturing movement
of the 1980s. However, it is now considered an integral part of the Agile software
development methodology.

Lean thinking can also be applied in other disciplines. Lean management is one example of this.

What are the 7 principles of Lean software development?

The main concept behind the Lean development methodology is that efficiencies can be applied, and
waste can be managed at all levels of the process. These include at the individual level, as well as in
departments, in interdepartmental operations, in the overall organization, and between the organization
and its customers and suppliers.

Lean principles aim to streamline every part of the software development lifecycle to build quality
products.

The Lean software development process includes the following seven principles:

1. Eliminate waste. After each development iteration, project managers discuss bottlenecks,
identify waste and develop a plan to eliminate it. The Lean philosophy has a broad definition of
waste that includes anything that doesn't add value to the product. Some examples are the
following:

1. unnecessary code or software features;

2. more tasks than can be completed in the task log;

3. bureaucratic processes; and

4. quality issues.

2. Build in quality. Various tactics are used to ensure quality is built into the Lean process, such
as pair programming and test-driven development.
3. Amplify learning. Knowledge one software engineer gains must be shared with every engineer
on the software development team. This occurs through code review and sharing at meetings. Also,
engineers learn as they go and question assumptions.

4. Delay commitment as long as possible. The goal is to experiment and learn as much as
possible before committing to irreversible decisions. Developers incorporate features and
functionality as late as possible in the process to prevent having to redo work as the market
changes.

5. Deliver fast. Developers launch a product quickly, receive customer feedback fast and use that
feedback to create a strategy for improvement. The idea behind this approach is to fail fast and
learn from the results. This strategy contrasts with other methodologies used to design complex
products. They often take a lot of time and still end up failing.

6. Respect people. Respect is the basis for a productive, collaborative atmosphere. Lean
encourages healthy conflict, proactive communication and constant feedback.

7. Optimize the whole. The team examines the process from start to finish to make the Lean
value stream as efficient as possible. It contrasts with the concept of suboptimization, where subpar
code is generated faster than it can be tested for the sake of speed and software testers are
overloaded.
What is the difference between Lean development and Agile?

Lean and Agile principles have much in common. When comparing Lean and Agile, experts often
point to the similarities rather than the differences. Lean and Agile work together so seamlessly that it's
difficult to tell them apart. They are sometimes referred to in tandem as Lean-Agile.

The last three Lean principles highlight some of what the Lean methodology has in common with Agile.
In both cases, the product development team sets the pace and is responsible for delivering the product.
Agile teams do this using the sprint methodology. And Lean's "optimizing the whole" principle is
similar to the Agile retrospective, where team members gather after a project's completion to discuss
successes and challenges.

There are some subtle differences between the two processes. Lean focuses on building better
processes, while Agile's focus is to build better products. Agile practices seek to create products that
meet consumer needs and expectations, and Lean is one way to achieve that goal.

Lean is often counted as one of several Agile frameworks -- Scrum and Kanban are two others. The
Agile methodology is detailed in the Agile Manifesto, which contains a set of values and principles that
guide the Agile frameworks.

What are the benefits of Lean software development?

Some of the advantages of Lean are the following:

 Collaboration. Lean principles amplify learning and respect to encourage collaboration and
knowledge sharing and avoid bottlenecks. Teams are empowered to make their own decisions and
work together in the decision-making process.

 Continuous improvement. Lean includes what many call the modern software development
process. The workflow incorporates constant communication with customers and steady feedback.
This enables continuous improvement, or Kaizen, in all parts of the operation.

 Efficiency. Demand for software is exploding, and companies cannot deliver apps fast enough.
The Lean approach eliminates waste and delivers software fast, making development organizations
more efficient and cutting cost.

 Flexibility. The Lean methodology incorporates flexibility, while still prioritizing speed in
the software development lifecycle. It leaves room for change and lets developers alter products
based on continuous feedback.

 Quality. Lean's efficiency, continuous improvement, flexibility and collaboration results in an

overall improvement in product quality and an increase in customer satisfaction.
What are the challenges of Lean development?

These are some of the challenges of Lean software development practices:

 Team training requirements. If a team is unable to work together and communicate,

development efforts suffer. Teams and team members must be trained so they can take on each
other's work and adapt to changing initiatives. They must also be able to organize work and trade
duties as priorities change.

 Missing metrics. A common pitfall of Lean is measuring the wrong software metrics or not
measuring at all. Since one of the main goals of Lean software engineering is to eliminate waste,
teams must be able to identify waste and measure it.

 No boundaries. Software requirements specifications evolve in Lean as customers provide

feedback. Too many requirements and too much change create complexity and make it difficult to
release a cohesive piece of software.

 Suboptimization. Suboptimization is when only part of the production system's value stream is
optimized. This happens when a problem is broken into parts that are solved in isolation without
considering the effect one part will have on other parts or the entire system.
The Kaizen Method

Kaizen, meaning “continuous improvement” in Japanese, is at the heart of Lean Management. This
approach engages every employee, from the executive team to the operators, in the continuous search
for small daily improvements. The goal is to cultivate a corporate culture where continuous
improvement is embedded in daily behavior.
What Is A Kaizen Board?
A Kaizen board is a visual tool used to track and manage continuous improvement efforts within an
organization or team. The Kaizen goal helps identify issues, nurture good ideas, plan solutions, track
progress, and showcase improvements, thus making the Kaizen philosophy more actionable and
measurable.

How to Get Started with the Kaizen Approach

Getting started with Kaizen doesn’t require a significant overhaul of your current practices. Instead, it’s
about making small, manageable adjustments to your existing processes. Here’s how you can start
implementing the Kaizen process just like every team embracing Kaizen:

#1) Identify Areas for Continuous Improvement

The first step in the Kaizen approach is identifying areas to improve in your organization. This literally
translates to anything from a business process, a personal habit, or even a specific task you perform
regularly. Review your activities and ask yourself, “Where can I improve?”

#2) Set Achievable Goals

Once you’ve identified an area for improvement, set a clear, achievable goal related to it.

Remember, Kaizen is about small, incremental changes, so your goal should reflect this philosophy.
For example, if you want to improve your time management, your goal might be to reduce wasted time
by 10% within a month.

#3) Implement Small Changes

Now that you have your goal start implementing small changes to help you reach it. These changes
should be easy to integrate into your current routines.

Suppose your goal is to reduce wasted time. In that case, you might start by eliminating one
unnecessary task from your daily routine or setting specific times for checking emails instead of doing
it sporadically throughout the day.

Remember, the key to Kaizen is consistency. Stick with minor changes, monitor your progress, and
adjust as necessary. Over time, you’ll see significant improvements from these seemingly minor
adjustments.

The Kanban Method

Kanban is a visual production management system aiming to control the work in progress using cards
(or digital alternatives) to signal the need for component replenishment. This tool helps avoid
overproduction and minimize inventory by closely aligning production with the actual demand.

Kanban is a visual workflow management system that aims to help you manage and streamline your
tasks more effectively.
Originating from the Japanese manufacturing and production environment to monitor assembly lines,
it’s now widely used across various industries.

The primary goal of Kanban is to identify potential bottlenecks in your processes and fix them so work
can flow through them cost-effectively at an optimal speed or set of logical pieces. It is represented
visually on a Kanban board with horizontal column headings, allowing you to see the state of every
piece of work at any time.

What Are Kanban Cards?

Kanban cards are a crucial component of the Kanban methodology that you’ll find quite helpful. These
cards represent individual tasks or work environment items in your process. Each card typically
includes details about the task, such as its description, who is responsible for it, metrics, deadlines, and
any other relevant information.

You’ll place these cards on your Kanban board, moving them through various stages as the work
progresses. This visual representation helps you track each task’s status and provides a clear workflow
overview, making it easier for you and your team to manage work efficiently and effectively.

Difference Between Traditional and Agile Software Development

Traditional Software Development Agile Software Development

It is used to develop simple software. It is used to develop complicated software.

In this methodology, testing and

In this methodology, testing is done once
development processes are performed
the development phase is completed.
concurrently.

It follows a linear It follows an iterative organizational

organizational expectation structure. structure.
 Traditional Software Development Agile Software Development

It provides less security. It provides high security.

Client involvement is less as compared to Client involvement is high as compared to

Agile development. traditional software development.

It provides less functionality in the It provides all the functionality needed by

software. the users.

It supports a fixed development model. It supports a changeable development model.

It is used by freshers. It is used by professionals.

Development cost is less using this Development cost is high using this
methodology. methodology.

It majorly consists of five phases. It consists of only three phases.

It is less used by software development It is normally used by software development

firms. firms.

The expectation is favored in the Adaptability is favored in the agile

traditional model. methodology.

Examples
Examples
 Office productivity suites
 Sky
 Data management software
 Phillips
 Media players
 JP Morgan Chase
 Security programs

Models based on Agile Software

Models based on Traditional Software
Development-
Development-
 Scrum
 Spiral Model
 Extreme Programming (XP)
 Waterfall Model
 Crystal
 V Model
 Dynamic Systems Development
 Incremental Model
Method (DSDM)

Differences Between Agile Plans at Different Lifecycle Phases

Lifecycle Phase Planning Focus Key Activities Outcomes
Identify stakeholders,
High-level vision, Project charter, initial
define project vision,
Initiation goals, and initial backlog, high-level
create initial product
backlog creation roadmap
backlog
Preparing the team Set up tools, define Ready-to-use
Sprint/Iteration
and environment for working agreements, refine environment, refined
0
development backlog, plan first sprint backlog, sprint plan
Break down backlog items
Sprint backlog, sprint
Detailed planning for into tasks, estimate effort,
Sprint Planning goal, task
the upcoming sprint assign tasks to team
assignments
members
Daily stand-ups, task Incremental product
Daily planning and
Execution updates, collaboration, and development,
coordination
problem-solving continuous progress
Evaluating the work Demonstrate completed Stakeholder feedback,
Review/Demo done and gathering work to stakeholders, validated product
feedback gather feedback increment
Reflecting on the
Discuss what went well, Actionable
process and
Retrospective what didn’t, and actions for improvements for the
identifying
improvement next sprint
improvements
Finalize features, conduct Released product,
Planning for product
Release testing, prepare for user feedback, and
release and delivery
deployment lessons learned

Testing Plan Links in Agile Methodology

1. Continuous Integration and Continuous Testing:

- Testing is performed continuously as part of the development process.

- Automated tests are run frequently to ensure that new code integrates well with existing code and does
not introduce defects.

2. Collaboration Between Developers and Testers:

- Testers work closely with developers, product owners, and other stakeholders to ensure that
requirements are clear and testable.

- Testing is a shared responsibility, and everyone on the team contributes to quality.

3. Test-Driven Development (TDD):

- Tests are written before the code is developed.

- This ensures that the code meets the requirements and reduces the likelihood of defects.
4. Iterative Testing:

- Testing occurs in each iteration (sprint), and feedback is incorporated into the next iteration.

- This allows for early detection and resolution of defects.

5. User Stories and Acceptance Criteria:

- Testing is directly linked to user stories and their acceptance criteria.

- Test cases are derived from these criteria to ensure that the product meets user expectations.

6. Regression Testing:

- Automated regression tests are run frequently to ensure that new changes do not break existing
functionality.

7. Exploratory Testing:

- Testers perform exploratory testing to uncover issues that may not be caught by scripted tests.

- This is especially useful for complex or unpredictable scenarios.

8. Feedback Loop:

- Testing provides immediate feedback to the team, enabling quick adjustments and improvements.

Testing Plan Links in Agile Methodology (Table)

Agile Element Testing Link Description

Ensures that the product meets
Test cases are derived from
User Stories user requirements and
acceptance criteria
expectations.
Testing tasks are included in the Testing is planned and prioritized
Sprint Planning
sprint backlog alongside development tasks.
Testers provide updates on testing Ensures transparency and quick
Daily Stand-ups
progress and blockers resolution of issues.
Ensures that new code integrates
Continuous Automated tests are run with every
well and does not introduce
Integration code commit
defects.
Sprint Tested features are demonstrated Stakeholders provide feedback on
Review/Demo to stakeholders the tested functionality.
Testing processes are reviewed for Identifies ways to improve testing
Retrospective
improvement efficiency and effectiveness.
Test-Driven Tests are written before code Ensures that the code meets
Development development requirements and reduces defects.
Exploratory Unscripted testing to uncover Helps identify edge cases and
Agile Element Testing Link Description
Testing unexpected issues usability issues.
Regression Automated tests are run to ensure Maintains product stability as new
Testing existing functionality is not broken features are added.
Definition of Testing is a mandatory part of the Ensures that no work is considered
Done "Done" criteria complete without being tested.

Roles in Agile

Roles in Agile

Role Responsibilities
Defines the product vision, prioritizes the backlog, and ensures the
Product Owner
team delivers value.
Facilitates the Agile process, removes impediments, and ensures the
Scrum Master
team follows Agile principles.
Development Cross-functional team responsible for delivering the product increment
Team (developers, testers, designers, etc.).
Stakeholders Provide feedback, clarify requirements, and validate deliverables.

Key Techniques in Agile

Technique Purpose
Capture requirements from the user's perspective and define
User Stories
acceptance criteria.
Refines and prioritizes the product backlog to ensure clarity
Backlog Grooming
and readiness.
Plans the work to be done in the upcoming sprint, including
Sprint Planning
testing tasks.
Keeps the team aligned, identifies blockers, and ensures
Daily Stand-ups
progress.
Ensures code is integrated and tested frequently to catch
Continuous Integration
defects early.
Test-Driven Development Write tests before code to ensure requirements are met and
(TDD) reduce defects.
Two developers work together to improve code quality and
Pair Programming
share knowledge.
Reflects on the process and identifies improvements for the
Retrospectives
next iteration.

Principles of Agile
1. Customer Satisfaction: Deliver value early and continuously through working software.

2. Welcome Change: Embrace changing requirements, even late in development.

3. Frequent Delivery: Deliver working software in short, iterative cycles.

4. Collaboration: Business stakeholders and developers work together daily.

5. Motivated Individuals: Build projects around motivated individuals and trust them to get the job done.

6. Face-to-Face Communication: The most efficient and effective method of conveying information.

7. Working Software: The primary measure of progress.

8. Sustainable Pace: Maintain a constant pace indefinitely to avoid burnout.

9. Technical Excellence: Focus on good design and quality to enhance agility.

10. Simplicity: Maximize the amount of work not done by focusing on what’s essential.

11. Self-Organizing Teams: Teams organize themselves to achieve the best outcomes.

12. Reflect and Adjust: Regularly reflect on how to become more effective and adjust accordingly.

Assessing the Initial Status of a Project

Agile helps assess the initial status of a project through the following means:

1. Project Vision and Goals:

- The Product Owner defines the vision and goals, which provide clarity on the project's purpose and
direction.

- This helps assess whether the team understands the "why" behind the project.

2. Backlog Readiness:

- The product backlog is reviewed to ensure it contains well-defined user stories with clear acceptance
criteria.

This helps assess whether the team has a clear understanding of what needs to be delivered.

3. Team Readiness:

- The cross-functional team is assessed for skills, availability, and collaboration readiness.

- This helps identify gaps in expertise or resources.

4. Stakeholder Engagement:

- Stakeholders are identified, and their involvement is planned to ensure continuous feedback.

- This helps assess whether the project has the necessary support and input.
5. Definition of Done:

- The team agrees on the criteria for considering a user story or task complete.

- This helps ensure quality standards are understood and met from the start.

6. Risk Assessment:

- Risks are identified early, and mitigation strategies are planned.

- This helps assess potential challenges and prepare for them.

How Agile Helps Build Quality?

1. Continuous Testing:

- Testing is integrated into every sprint, ensuring that defects are caught and fixed early.

- Automated tests and regression testing maintain product stability.

2. Iterative Development:

- Frequent iterations allow for continuous feedback and improvement, ensuring the product meets user
needs.

3. Collaboration:

- Close collaboration between developers, testers, and stakeholders ensures that requirements are clear and
testable.

4. Test-Driven Development (TDD):

- Writing tests before code ensures that the code meets requirements and reduces defects.

5. Definition of Done:

- Clear criteria for completion ensure that no work is considered done without being tested and reviewed.

6. Retrospectives:

- Regular retrospectives help the team identify areas for improvement in both the process and the product.

7. Technical Excellence:

- Agile emphasizes good design, refactoring, and continuous integration, which contribute to high-quality
code.

8. User-Centric Focus:

- User stories and acceptance criteria ensure that the product is built to meet user needs and expectations.
 UNIT II
AGILE AND SCRUM PRINCIPLES

Manifesto for Agile Software Development

The Manifesto for Agile Software Development is a foundational document produced by 17 developers
at Snowbird, Utah in 2001. This document consists of 4 Agile Values and 12 Agile Principles,
emphasizing collaboration, flexibility, and customer satisfaction. These 12 principles and 4 agile values
provide a guide to Software Developers. The Manifesto for Agile Software Development emerged as a
transformative guide to Software Development.
Manifesto for Agile Software Development

Table of Content
 History of Agile Manifesto
 Purpose of Manifesto for Agile Software Development
 4 Values of Manifesto for Agile Software Development
 Principles of Manifesto for Agile Software Development
 Conclusion: Manifesto for Agile software development
 FAQ's on Manifesto for Agile software development
History of Agile Manifesto
In the late 1990s, traditional software development methodologies faced challenges with adapting to
changing project requirements. A group of visionary software developers, including Kent
Beck, Martin Fowler, and Alistair Cockburn gathered and collaborated in 2001, and formulated the
Agile Manifesto.

History of
Agile Manifesto
It's a document that outlines a set of guiding principles for adaptive and customer-centric software
development. This manifesto was officially released on February 13, 2001. This has marked a turning
point in the industry, with Agile methodologies gaining attraction globally. After 2001, practices like
Scrum and Extreme Programming became popular. This extends the influence of Agile beyond
software development into diverse sectors. This Agile Manifesto's enduring legacy continues to shape
how teams approach projects, fostering adaptability, collaboration, and customer focus in the dynamic
landscape of technology and business.
Purpose of Manifesto for Agile Software Development
 The primary purpose of the Agile Manifesto is to provide a foundation for developing
software in a way that responds effectively to changing requirements and delivers value
to customers. It aims to shift the focus from rigid processes and extensive
documentation to individuals and interactions, working software, and customer
collaboration.
What is the Agile Manifesto?
The Agile Manifesto is a set of foundational principles for agile software development that emphasizes
flexibility, collaboration, and customer satisfaction. It Outlines 4 core Values and 12 Principles guide
agile practices.
4 Core Values of the tackleAgile Manifesto
1. Individuals and Interactions over Processes and Tools: Focuses on the importance of
effective communication and collaboration among team members.
2. Working Software over Comprehensive Documentation: Prioritizes the delivery of
functional software as the primary measure of progress.
3. Customer Collaboration over Contract Negotiation: Encourages customers and stakeholders
to have active involvement throughout the development process.
4. Responding to Change over Following a Plan: On changing requirements, embracing
flexibility and ability to adapt even late in the development process.

4 Values of
Agile Manifesto for Software Development
12 Principles of Agile Manifesto
This Agile Manifesto is supported by 12 principles that help to implement the values.
The 12 Principles of Agile Manifesto for Software Development7
1. Customer Satisfaction through Early and Continuous Delivery: This principle concentrates
on the importance of customer satisfaction by providing information to customers early on time and
also with consistency throughout the development process.
2. Welcome Changing Requirements, Even Late in Development: Agile processes tackle
change for the customer's competitive advantage. Even late in development, changes in
requirements are welcomed to ensure the delivered software meets the evolving requirements of the
customer.
3. Deliver Working Software Frequently: This principle encourages the regular release of
functional software increments in short iterations. This enables faster feedback and adaptation to
changing requirements.
4. Collaboration between Business Stakeholders and Developers: This says the businesspeople
and developers must work together daily throughout the project. There should be communication
and collaboration between stakeholders and the development team regularly. This is crucial for
understanding and prioritizing requirements effectively.
5. Build Projects around Motivated Individuals: This promotes in giving developers the
environment and support they need and trusts them to complete the job successfully. Motivated and
empowered individuals are more likely to produce work with quality and make valuable
contributions to the project.
6. Face-to-face communication is the Most Effective: Face-to-face communication is the most
effective method of discussion and conveying information. This principle depicts the importance of
direct interaction which helps minimize misunderstandings, and hence effective communication is
achieved.
7. Working Software is the Primary Measure of Progress: This principle emphasizes
delivering functional and working software as the primary metric for project advancement. It
encourages teams to prioritize the continuous delivery of valuable features, so it ensures that good
progress is consistently achieved throughout the process. The primary goal is to provide customers
with incremental value and also gather feedback early in the project life cycle.
8. Maintain a Sustainable Pace of Work: Agile promotes sustainable development. All people
involved: The sponsors, developers, and users should be able to maintain a constant pace
indefinitely. This principle depicts the need for a sustainable and consistent development pace. This
helps in avoiding burnout and ensures long-term project success.
9. Continuous Attention to Technical Excellence and Good design: This principle is on the
importance of maintaining high standards of technical craft and design, so it ensures the long-term
ability in maintenance and adaptability of the software.
10. Simplicity—the Art of Maximizing the Amount of Work Not Done: Simplicity is essential.
The objective here is to concentrate on the most valuable features and tasks and avoid unnecessary
complexity as the art of maximizing the amount of work not done is crucial.
11. Self-Organizing Teams: Self-organizing teams provide the best architectures, requirements,
and designs. These help in empowering teams to make decisions and organize to optimize
efficiency and creativity.
12. Regular Reflection on Team Effectiveness: This makes the team reflect on how to become
more effective at regular intervals and then adjust accordingly. Continuous improvement is very
crucial for adapting to changing circumstances and optimizing the team's performance over time.
Why is the Agile Manifesto important?
 It is a revolutionized Software Development that focuses on a more flexible and Adaptive
approach rather than a rigid approach.
 It enhances Team collaboration where individuals can interact openly and freely, also agile
focuses on a collaborative work environment where team members can share their ideas openly,
communicate with each other and work efficiently.
 It helps in increasing customer satisfaction, Customers are also involved in the process which
ensures the product aligns with their needs and expectations, leading to higher satisfaction and a
better end product.
 Promote Flexibility and Adaptability, agile allows for 'responding to change', means allows
teams to adapt to evolving requirements and market dynamics and reduces the risk of project
failure.
 Accelerate Delivery, by focusing on working software, Agile encourages iterative development
and frequent releases, enabling faster delivery of valuable features to customers.
How to use the Agile Manifesto?
Implementing an Agile Manifesto is not about only adopting the principles, it is also about how an
organization shifts its culture from a rigid one to a more flexible approach.
Here are some steps to use the Agile Manifesto
 Focuses on Agile Core Values first by encouraging your team, they can internalize and
prioritize the four core values in their daily work.
 Adopt Agile Frameworks Implement Agile frameworks like Scrum, Kanban, and Extreme
Programming that align with your team's needs and project requirements.
 Foster Open Communication, and, encourage regular communication among team members
and stakeholders freely, allowing them to share their ideas by creating an environment where team
members feel comfortable.
 Iterate and Improve, according to change in response, continuously assess your process, and
as per the feedback from the user make changes and adjustments. Agile is about continuous
improvement and learning.
 Engage with Customers Maintain ongoing collaboration with customers to gather feedback
and ensure the product aligns with their needs.

What is Extreme Programming (XP)?

Extreme programming (XP) is one of the most important software development frameworks of Agile
models. It is used to improve software quality and responsiveness to customer requirements.

Table of Content
 What is Extreme Programming (XP)?
 Good Practices in Extreme Programming
 Basic principles of Extreme programming
 Applications of Extreme Programming (XP)
 Life Cycle of Extreme Programming (XP)
 Values of Extreme Programming (XP)
 Advantages of Extreme Programming (XP)
 Conclusion
 Frequently Asked Questions related to Extreme Programming
The extreme programming model recommends taking the best practices that have worked well in the
past in program development projects to extreme levels.
What is Extreme Programming (XP)?
Extreme Programming (XP) is an Agile software development methodology that focuses on delivering
high-quality software through frequent and continuous feedback, collaboration, and adaptation. XP
emphasizes a close working relationship between the development team, the customer, and
stakeholders, with an emphasis on rapid, iterative development and deployment.
Extreme Programming (XP)
Agile development approaches evolved in the 1990s as a reaction to documentation and bureaucracy-
based processes, particularly the waterfall approach. Agile approaches are based on some common
principles, some of which are:
1. Working software is the key measure of progress in a project.
2. For progress in a project, therefore software should be developed and delivered rapidly in small
increments.
3. Even late changes in the requirements should be entertained.
4. Face-to-face communication is preferred over documentation.
5. Continuous feedback and involvement of customers are necessary for developing good-quality
software.
6. A simple design that involves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
7. The delivery dates are decided by empowered teams of talented individuals.
Extreme programming is one of the most popular and well-known approaches in the family of agile
methods. an XP project starts with user stories which are short descriptions of what scenarios the
customers and users would like the system to support. Each story is written on a separate card, so they
can be flexibly grouped.
Good Practices in Extreme Programming
Some of the good practices that have been recognized in the extreme programming model and
suggested to maximize their use are given below:

Extreme Programming Good Practices

 Code Review: Code review detects and corrects errors efficiently. It suggests pair
programming as coding and reviewing of written code carried out by a pair of programmers who
switch their work between them every hour.
 Testing: Testing code helps to remove errors and improves its reliability. XP suggests test-
driven development (TDD) to continually write and execute test cases. In the TDD approach, test
cases are written even before any code is written.
 Incremental development: Incremental development is very good because customer feedback
is gained and based on this development team comes up with new increments every few days after
each iteration.
 Simplicity: Simplicity makes it easier to develop good-quality code as well as to test and
debug it.
 Design: Good quality design is important to develop good quality software. So, everybody
should design daily.
 Integration testing:Integration Testing helps to identify bugs at the interfaces of different
functionalities. Extreme programming suggests that the developers should achieve continuous
integration by building and performing integration testing several times a day.
Basic Principles of Extreme programming
XP is based on the frequent iteration through which the developers implement User Stories. User
stories are simple and informal statements of the customer about the functionalities needed. A User
Story is a conventional description by the user of a feature of the required system. It does not mention
finer details such as the different scenarios that can occur. Based on User stories, the project team
proposes Metaphors. Metaphors are a common vision of how the system would work. The
development team may decide to build a Spike for some features. A Spike is a very simple program
that is constructed to explore the suitability of a solution being proposed. It can be considered similar to
a prototype. Some of the basic activities that are followed during software development by using the
XP model are given below:
 Coding: The concept of coding which is used in the XP model is slightly different from
traditional coding. Here, the coding activity includes drawing diagrams (modeling) that will be
transformed into code, scripting a web-based system, and choosing among several alternative
solutions.
 Testing: The XP model gives high importance to testing and considers it to be the primary
factor in developing fault-free software.
 Listening: The developers need to carefully listen to the customers if they have to develop
good quality software. Sometimes programmers may not have the depth knowledge of the system
to be developed. So, the programmers should understand properly the functionality of the system
and they have to listen to the customers.
 Designing: Without a proper design, a system implementation becomes too complex, and very
difficult to understand the solution, thus making maintenance expensive. A good design results
elimination of complex dependencies within a system. So, effective use of suitable design is
emphasized.
 Feedback: One of the most important aspects of the XP model is to gain feedback to
understand the exact customer needs. Frequent contact with the customer makes the development
effective.
 Simplicity: The main principle of the XP model is to develop a simple system that will work
efficiently in the present time, rather than trying to build something that would take time and may
never be used. It focuses on some specific features that are immediately needed, rather than
engaging time and effort on speculations of future requirements.
 Pair Programming: XP encourages pair programming where two developers work together at
the same workstation. This approach helps in knowledge sharing, reduces errors, and improves
code quality.
 Continuous Integration: In XP, developers integrate their code into a shared repository
several times a day. This helps to detect and resolve integration issues early on in the development
process.
 Refactoring: XP encourages refactoring, which is the process of restructuring existing code to
make it more efficient and maintainable. Refactoring helps to keep the codebase clean, organized,
and easy to understand.
 Collective Code Ownership: In XP, there is no individual ownership of code. Instead, the
entire team is responsible for the codebase. This approach ensures that all team members have a
sense of ownership and responsibility towards the code.
 Planning Game: XP follows a planning game, where the customer and the development team
collaborate to prioritize and plan development tasks. This approach helps to ensure that the team is
working on the most important features and delivers value to the customer.
 On-site Customer: XP requires an on-site customer who works closely with the development
team throughout the project. This approach helps to ensure that the customer’s needs are
understood and met, and also facilitates communication and feedback.
Applications of Extreme Programming (XP)
Some of the projects that are suitable to develop using the XP model are given below:
 Small projects: The XP model is very useful in small projects consisting of small teams as
face-to-face meeting is easier to achieve.
 Projects involving new technology or Research projects: This type of project faces changing
requirements rapidly and technical problems. So XP model is used to complete this type of project.
 Web development projects: The XP model is well-suited for web development projects as the
development process is iterative and requires frequent testing to ensure the system meets the
requirements.
 Collaborative projects: The XP model is useful for collaborative projects that require close
collaboration between the development team and the customer.
 Projects with tight deadlines: The XP model can be used in projects that have a tight deadline,
as it emphasizes simplicity and iterative development.
 Projects with rapidly changing requirements: The XP model is designed to handle rapidly
changing requirements, making it suitable for projects where requirements may change frequently.
 Projects where quality is a high priority: The XP model places a strong emphasis on testing
and quality assurance, making it a suitable approach for projects where quality is a high priority.
XP, and other agile methods, are suitable for situations where the volume and space of requirements
change are high and where requirement risks are considerable.
Life Cycle of Extreme Programming (XP)
The Extreme Programming Life Cycle consist of five phases:

Life Cycle of Extreme Programming (XP)

1. Planning: The first stage of Extreme Programming is planning. During this phase, clients
define their needs in concise descriptions known as user stories. The team calculates the effort
required for each story and schedules releases according to priority and effort.
2. Design: The team creates only the essential design needed for current user stories, using a
common analogy or story to help everyone understand the overall system architecture and keep the
design straightforward and clear.
3. Coding: Extreme Programming (XP) promotes pair programming i.e. wo developers work
together at one workstation, enhancing code quality and knowledge sharing. They write tests before
coding to ensure functionality from the start (TDD), and frequently integrate their code into a
shared repository with automated tests to catch issues early.
4. Testing: Extreme Programming (XP) gives more importance to testing that consist of both unit
tests and acceptance test. Unit tests, which are automated, check if specific features work correctly.
Acceptance tests, conducted by customers, ensure that the overall system meets initial requirements.
This continuous testing ensures the software’s quality and alignment with customer needs.
5. Listening: In the listening phase regular feedback from customers to ensure the product meets
their needs and to adapt to any changes.
Values of Extreme Programming (XP)
There are five core values of Extreme Programming (XP)

Values of Extreme Programming (XP)

1. Communication: The essence of communication is for information and ideas to be exchanged
amongst development team members so that everyone has an understanding of the system
requirements and goals. Extreme Programming (XP) supports this by allowing open and frequent
communication between members of a team.
2. Simplicity: Keeping things as simple as possible helps reduce complexity and makes it easier
to understand and maintain the code.
3. Feedback: Feedback loops which are constant are among testing as well as customer
involvements which helps in detecting problems earlier during development.
4. Courage: Team members are encouraged to take risks, speak up about problems, and adapt to
change without fear of repercussions.
5. Respect: Every member’s input or opinion is appreciated which promotes a collective way of
working among people who are supportive within a certain group.
Advantages of Extreme Programming (XP)
 Slipped schedules: Timely delivery is ensured through slipping timetables and doable
development cycles.
 Misunderstanding the business and/or domain − Constant contact and explanations are
ensured by including the client on the team.
 Canceled projects: Focusing on ongoing customer engagement guarantees open
communication with the consumer and prompt problem-solving.
 Staff turnover: Teamwork that is focused on cooperation provides excitement and goodwill.
Team spirit is fostered by multidisciplinary cohesion.
 Costs incurred in changes: Extensive and continuing testing ensures that the modifications do
not impair the functioning of the system. A functioning system always guarantees that there is
enough time to accommodate changes without impairing ongoing operations.
 Business changes: Changes are accepted at any moment since they are seen to be inevitable.
 Production and post-delivery defects: the unit tests to find and repair bugs as soon as
possible.
What is Scrum in Agile Methodology?
Scrum is a popular framework that is used whenever we want to develop complex products, Ken
Schwaber and Jeff Sutherland are known as the people who developed Scrum. Scrum is a type
of Agile framework.

Table of Content
 What is a scrum in software development?
 Silent features of Scrum
 Advantage of Scrum framework
 Disadvantage of Scrum framework
 Conclusion
 Frequently Asked Questions on Scrum (software development)
What is a scrum in Agile Methodology?
Scrum is a management framework that teams use to self-organize tasks and work towards a common
goal. It is a framework within which people can address complex adaptive problems while the
productivity and creativity of delivering products are at the highest possible value. Scrum is a
management framework that teams use to self-organize and work towards a common goal.
 Scrum allows us to develop products of the highest value while making sure that we maintain
creativity and productivity.
 The iterative and incremental approach used in scrum allows the teams to adapt to the changing
requirements.
Silent features of Scrum
 Scrum is a light-weighted framework
 Scrum emphasizes self-organization
 Scrum is simple to understand
 Scrum framework helps the team to work together
 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, it goes to the Release
stage.
 Sprint Review: If the product still has some non-achievable features, it will be checked in this
stage and then 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.
Advantage of Scrum framework
 Scrum framework is fast moving and money efficient.
 Scrum framework works by dividing the large product into small sub-products. It’s like a
divide and conquer strategy
 In Scrum customer satisfaction is very important.
 Scrum is adaptive in nature because it have short sprint.
 As Scrum framework rely on constant feedback therefore the quality of product increases in
less amount of time
Disadvantage of Scrum framework
 Scrum framework do not allow changes into their sprint.
 Scrum framework is not fully described model. If you wanna adopt it you need to fill in the
framework with your own details like Extreme Programming(XP), Kanban, Dynamic Systems
Development Method (DSDM).
 It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear
definition.
 The daily Scrum meetings and frequent reviews require substantial resources.

WORKING OF SCRUM IN AN ORGANIZATION.

Scrum working :
Let’s say we need to build a product “MyFirstProduct”.
So first, We gather all requirements and feature requests from Customer, Executives, or even other
team members. Basically, In Scrum, features are from the end-user perspective. Features are written
are known to be “User-Stories”.
User-stories :
These user-stories are collectively known as Product backlog. Means a Complete list according to
end-user wish. A product backlog is created. After this, user-stories priority is assigned to a
particular release of our product (Release Backlog).
1. Product Owner :
So, Product Owner assures that appropriate features are added into backlog, as it helps to set
direction of product release.
2. Scrum Master :
It is not owner of a project but its job is to make a continuous flow of process and assurance of
tools to be required to get work done. It setups meeting and monitor all work and progress of
scrum team.
3. Scrum team/Development team :
By scrum team we mean, team is a cross-functional, little, and self-sorting out-group that claims
aggregate obligation of creating, testing, and delivering Product increase. Also, different roles are
there for a specific domain like developer, tester, executives, etc.
4. Release Planning :
In this, team first prioritizes user stories and estimate amount of work for each user-stories. It
 gives you idea of amount of total work (an estimation) required to complete entire
project/product.

User-stories are divided in prioritization like : prioritization-1, prioritization-2, prioritization-3 etc.

And Release Backlog is formed. Now after Release backlog is ready sprints are plan out. Sprint is
mainly for a short duration to make determined efforts to deal with chunks of product and get it in a
ready state without error and a complete releasable form.

Why Sprints :
Sprint can be 2-3 weeks or up to 1month too. It differs from project to project. If you see sprints are a
subset of Release Backlog. Here goal is to release a complete working subset at every sprint. Sprint
is also a practical/Realistic representation of product.
Sprint Review is there to check if anything es left or not. After that Sprint Retrospective, it means
team checks if there was any other way so that we can improve other sprint by resolving issue based
on previous sprint so that release of sprint can be increased.
Burndown chart :
It is used to check progress of every sprint. Using this we calculate Speed of productivity and
approximate completion date of project. If team is working less than Chart it simply means team
reduces its working velocity and will take more completion date as compared to Burndown chart.
Generalize formula in organization : Work remaining / rate equals to days of completion.

ADVANCED SCRUM APPLICATIONS

1. Scrumwise: Scrumwise is an advanced agile project management tool that provides powerful
features for managing teams and projects. It supports multiple teams and projects, making it suitable
for large-scale projects. It also offers a variety of customization options for creating reports, tracking
progress, and managing tasks.

2. JIRA Software: JIRA Software is an advanced scrum application for teams that need to track
complex workflows. It allows teams to easily plan sprints, assign tasks, and manage backlogs. It also
integrates with other tools such as Slack and GitHub, allowing teams to collaborate effectively.

3. Targetprocess: Targetprocess is an advanced scrum management tool that helps teams plan, track,
and execute projects. It offers a variety of features, including resource management, task management,
and reporting. It also has an intuitive interface and supports collaboration across teams.

4. Asana: Asana is an advanced agile project management tool that helps teams manage workflows and
tasks. It allows teams to set up projects, assign tasks, track progress, and collaborate. It also integrates
with other tools such as Slack, Dropbox, and Google Drive.

5. Trello: Trello is an advanced scrum application that helps teams manage projects and tasks. It
provides visual boards, allowing teams to track tasks, assign tasks, and plan sprints. It also integrates
with other tools such as Slack and Google Drive, allowing teams to collaborate.

SCRUM AND THE ORGANIZATION IN AGILE METHODOLOGY

Scrum is not just a framework for teams; it has a profound impact on the entire organization.
Implementing Scrum requires a cultural shift, leadership support, and a commitment to Agile principles.
Below is a detailed explanation of how Scrum interacts with and influences the organization in Agile
methodology.

1. Cultural Shift

Adopting Scrum requires a fundamental change in how the organization operates. Key aspects of this
cultural shift include:

- From Command-and-Control to Empowerment:

- Traditional hierarchies are replaced with self-organizing teams.

- Teams are empowered to make decisions and take ownership of their work.

- From Silos to Collaboration:

- Departments and teams work together collaboratively rather than in isolation.

- Cross-functional teams are formed to deliver end-to-end solutions.

- From Fixed Plans to Adaptability:

- Organizations embrace change and focus on delivering value incrementally.

- Long-term plans are replaced with iterative planning and continuous feedback

2. Leadership Support

Leadership plays a critical role in the successful adoption of Scrum. Leaders must:

- Champion Agile Values:

- Promote Agile principles like collaboration, transparency, and continuous improvement.

- Lead by example and demonstrate commitment to Agile practices.

- Empower Teams:

- Provide teams with the autonomy to self-organize and make decisions.

- Remove organizational impediments that hinder progress.

- Invest in Training:

- Provide training and coaching to help teams understand and implement Scrum effectively.

- Encourage continuous learning and skill development.

3. Organizational Structure

Scrum often necessitates changes to the organizational structure to support Agile practices:
- Cross-Functional Teams:

- Teams are composed of members with diverse skills (developers, testers, designers, etc.) to deliver
complete increments.

- Flatter Hierarchy:

- Reduce layers of management to enable faster decision-making and communication.

- Product-Centric Focus:

- Organize teams around products or services rather than functions or departments.

4. Metrics and Reporting

Scrum introduces new ways of measuring progress and success:

- Velocity:

- Tracks the amount of work a team can complete in a sprint, helping with future planning.

- Burndown Charts:

- Visualize progress within a sprint, showing remaining work versus time.

- Cycle Time:

- Measures the time taken to complete a task from start to finish.

- Customer Satisfaction:

- Focuses on delivering value to customers and gathering their feedback.

5. Scaling Scrum

For larger organizations, Scrum can be scaled to manage multiple teams and complex projects:

-Scrum of Scrums:

- A meeting where representatives from different Scrum teams coordinate and resolve dependencies.

- LeSS (Large Scale Scrum):

- A framework for scaling Scrum to multiple teams while maintaining simplicity.

- SAFe (Scaled Agile Framework):

- A comprehensive framework for scaling Agile practices across the enterprise.

6. Challenges and Solutions

Implementing Scrum in an organization is not without challenges:

Challenge Solution
Provide training, communicate benefits, and involve employees in
Resistance to Change
the process.
Lack of Leadership Educate leaders on Agile principles and demonstrate the value of
Support Scrum.
Encourage cross-functional collaboration and reorganize teams
Siloed Departments
around products.
Inconsistent Practices Establish clear guidelines and provide ongoing coaching.
Use frameworks like LeSS or SAFe to manage multiple teams
Scaling Issues
effectively.

7. Benefits to the Organization

Scrum delivers significant benefits to organizations that embrace it:

- Faster Time-to-Market:

- Delivers working increments in short iterations, enabling quicker releases.

- Improved Quality:

- Continuous testing and feedback ensure high-quality products.

- Increased Customer Satisfaction:

- Regular delivery of value and customer collaboration lead to better outcomes.

- Higher Employee Engagement:

- Empowered teams and a collaborative culture boost morale and productivity.

- Better Adaptability:

- Organizations can respond quickly to changing market conditions and customer needs.

SCRUM VALUES

In 2016, five scrum values were added to the Scrum Guide. These values provide direction toward
work, actions, and the behavior of the scrum team. They are considered essential to a scrum team’s
success.

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team’s
success. Therefore, each team member should agree to commit to performing tasks they can complete
and not over commit. There should be frequent communication regarding work progress, often in
stand-ups.

Courage
Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its
ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new
things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project
progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where
the team completes a set amount of work. The sprint provides structure but also focus to complete the
planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and
blockers. At Atlassian we often have our scrum teams address these questions:

i. What did I work on yesterday?

ii. What am I working on today?
iii. What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when
everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member
contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one
another, the product owner, stakeholders, and the scrum master.
 UNIT III
AGILE PRODUCT MANAGEMENT

Streamline communication with Agile meetings

Traditional project communication plans outline a rigid and detailed structure of check-ins and status
meetings. Agile meetings try to cut down on unnecessary emails and documentation with highly
focused and efficient face-to-face meetings.

In fact, Agile includes set practices to communicate at each level, as shown below.

Streamline the communication process with Agile meetings including:

Sprint planning: At the beginning of a sprint, the team gets together to plan the sprint goal (or project
objectives) for that stage based on the product backlog. This is an essential meeting because it
determines the focus of the sprint, the requirements for deliverables, and the plan of action.

The length of the meeting depends on the length of the sprint. But a good rule of thumb is to multiply
the length of the sprint (in weeks) by two. So a sprint planning meeting for a two-week sprint should
take about four hours.

Daily Scrum meeting: This daily standup meeting is short and sweet. Each team member gives a brief
status update on what they did the day before, what’s on the docket for that day, and what (if any)
issues they’re facing. These meetings should last no longer than 15 minutes.

Sprint review: At the end of the sprint, it’s time to show everyone what you’ve completed. All
stakeholders and Scrum team members gather to demo the software and highlight the tasks finished,
identify any issues, and take feedback.

Retrospective: The retrospective occurs after a sprint review to go over the team’s performance during
the sprint, including what went well, what didn’t work, and how to improve going forward. This is an
important part of the Agile focus on continuous improvement and iteration. These meetings usually last
a couple hours.

Modes of Communication.
 Communication Technologies:

Technology Description

Collaborative Software-based modeling tools (SBMTs), also known as computer

modeling tools aided software engineering (CASE) tools, that enable several
developers to simultaneously work on one or models with
real-time updates of those models. These tools are typically
browser-based and hosted via a SAAS strategy.

Collaborative writing Word processing tools that enable several people to simultaneously
tools write a document with real-time updates of that document.
Wikis and Google Docs are examples of this.

Discussion tools Tools such as email, newsgroups, mailing lists, instant messaging,
and chat rooms that enable transmission of text messages, and
potentially other attachments, between people.

Inclusive Modeling Simple tools such as whiteboards, sheets of paper, sticky notes and
Tools so on.

Personal video Many laptops, workstations, and phones now have cameras and
software built in that enable videoconferencing.

Version control tools Software tools used to check in/out, define, and manage versions of
artifacts.

Virtual meeting tools Tools that enable communication between several people who are in
different physical locations.

Collaborative Software-based modeling tools (SBMTs), also known as computer

 Technology Description

modeling tools aided software engineering (CASE) tools, that enable several
developers to simultaneously work on one or models with
real-time updates of those models. These tools are typically
browser-based and hosted via a SAAS strategy.

Collaborative writing Word processing tools that enable several people to simultaneously
tools write a document with real-time updates of that document.
Wikis and Google Docs are examples of this.

Discussion tools Tools such as email, newsgroups, mailing lists, instant messaging,
and chat rooms that enable transmission of text messages, and
potentially other attachments, between people.

Inclusive Modeling Simple tools such as whiteboards, sheets of paper, sticky notes and
Tools so on.

Personal video Many laptops, workstations, and phones now have cameras and
software built in that enable videoconferencing.

Version Software tools used to check in/out, define, and manage versions of
control tools artifacts.

Virtual meeting tools Tools that enable communication between several people who are in
different physical locations.

AGILE PLANNING PROCESS: STEP-BY-STEP:

Agile project planning involves multiple steps. Each step is meant to propel your project forward while
maintaining an organized approach to managing your product and workforce. The steps can be adapted
to your team’s specific needs, and some need to be maintained on an ongoing basis, but overall,
following the steps below will help you successfully implement an Agile plan for your next product
launch.

1.Define vision

Your first step in Agile planning is to start by defining the vision for your project or product, which
includes overall goals and objectives to be achieved. The product owner is often crucial in this early
stage, ensuring that the vision aligns with user needs and business goals.

2.Set clear expectations on goals

Next, you should set clear expectations on what you want the output to be so that all team members and
stakeholders are on the same page. Even if tasks or certain plans change due to feedback cycles and
new iterations, the expectation should remain constant.

3.Define and break down the product roadmap

After setting expectations, it’s important to build a high-level product roadmap to highlight milestones
and deliverables, giving your project more of a strategic direction. Then, the roadmap should be broken
down into releases or increments, each with a defined set of features to include. Cross-functional teams
often collaborate at this stage to ensure all perspectives are considered.

4.Create tasks based on user stories

This step should be more ongoing as project and user needs evolve over different iterations, but the
idea is to create actionable tasks based on real user stories so that team members can work on adding
new features, updating existing ones, or creating more functionality in your product.

5.Populate product backlog

Your product backlog is a collection of tasks and user stories that should be worked on over a project’s
lifecycle. It includes tasks that aren’t a part of the current sprint but may be a part of future ones and
can operate as a place to collect new tasks that arise as a result of feedback, roadblocks, or problems
that need to be solved. Tasks in the product backlog should also be prioritized according to user needs
or a project’s timeline.

6.Plan iterations and estimate effort

For each release, it’s important to plan a series of iterations or sprints. In this process, you want to
define each iteration’s goals and objectives while also estimating the effort and time it may take based
on the current sprint’s tasks. This helps gauge a sprint’s complexity so you can create an interaction
plan based on current workfloads, deliverables, and timelines.

7.Conduct daily stand-ups

Daily meetings, often called stand-ups, are a helpful Agile ceremony that allows teams to discuss any
pressing issues and plan the day’s work. Daily stand-ups are short and focused and involve very short-
term planning to tackle a task currently being worked on.

8.Monitor and adapt

Finally, with Agile planning, it’s always important to monitor progress against overall goals, iteration
plans, and your product roadmap. Track any deviations from the plan so you can find immediate
solutions. At the end of each sprint, you can identify areas for improvement and implement them in
future iterations.

These eight steps involve a lot of scheduling, planning, and communicating to implement effectively.
To keep this process organized and running smoothly, many teams use a platform like monday dev,
which is built on the monday.com Work Operating System (Work OS). Platforms like monday dev
help teams run their projects, communicate between themselves, and track all updates in real-time.

WHAT IS ESTIMATION IN AGILE?

Agile estimation estimates your effort to complete a prioritized task in the product backlog. We
measure it for the time it would take to complete that task. As a result, you can plan sprints more
accurately.
Trivia: A sprint is a time-boxed interval that defines the time allocated to complete a task.
Note: Even if a business accurately estimates the effort required to complete a user story in Agile, it’s
not the final data. Do not strive to achieve perfect accuracy because requirements can change anytime.
There are also agile anti-patterns and other emerging realities that change the development course.
Agile teams also make estimations concerning story points. A story point is used in Agile Software
Development projects to estimate the difficulty of implementing a given user story. We measure it in
relative units assigned to different user stories that require estimation.
A story point is a number that helps estimate the difficulty of building a user story successfully. This
difficulty could be related to the complexities, risks, and efforts involved.
Agile project estimation also helps to build strong coordination. If project X depends on project Y,
agile project estimation provides an overview of the wait time.

Why Run Agile Estimations?

Agile estimates are essential for

 Making teams accountable for deliverables,

  Inducing discipline across the Agile team,

 Predicting the approximate time, it will take to finish a project,

 Enabling better sprint management,

 Improving team productivity.

Why do Teams Estimate in Agile?

Overestimating and underestimating are both typical for Agile software development companies. It
leads to varying development and launch times. Considering Agile estimation in the initial stages can
assist in accurate user story estimations. It helps the team stick to the deliverables, and you don’t
deflect.
Some of the to-the-point benefits of Agile Estimation techniques include:

1. Improved Decision-Making

With accurate, agile estimation, the development team can conduct practical backlog grooming
sessions, which further helps in precise sprint planning. Their user story delivery time will improve
when they make informed decisions and plan well.

2. Better Coordination

Let’s say the estimated effort for user story A is two weeks. On the other hand, the estimation effort for
user story B is four weeks. Now, both user stories depend on each other and are connected. In that case,
the team needs to prioritize work so that both user stories get completed simultaneously. It will lead to
better coordination among teams.

3. Better Risk Management

Software projects often suffer from exceeding budgets and timelines. To lessen this risk, Agile project
estimation is an ideal solution. Agile product estimation helps estimate story points and stick to budgets,
estimates, and the project’s scope—the more accurate the estimates, the better the chances of on-time,
quality delivery.

Stages of Agile Estimation: The Short Discovery Phase

When a project starts, the horizon is limited. Hence, it is wise to implement a short product discovery
phase to tide over this problem. The discovery phase establishes the essential tenet of Agile
development methodology, breaking down the requirements into small batch sizes. It is an exercise that
typically takes two to four weeks, depending on the project’s complexity.
Here’s what the in-detail process includes:

1. Conduct Stakeholder Interviews

The Business Analyst (BA) assigned to the discovery team initially revisits any existing documentation
shared and extracts the gaps and queries. The BA then conducts regular workshops with the
stakeholders to discuss the gaps and clarify doubts in the system workflow.
Based on these workshops, the BA comes up with the business and functional requirements:
Business Requirements Document (BRD): defines the end goal of the project
Functional Requirements Document (FRD): describes the features required to achieve the end-goal
These workshops can be conducted over a call with the client or when they visit the premises to have
one-on-one sessions.

2. Define High-Level Product Backlog

The next step of Agile Estimation involves the BA and the Technical Architect. They frame an initial
outcome that the stakeholders are looking for with a feasible solution or product.
A high-level product backlog is defined in terms of epics and story titles, which describe the bare bones
of the application. They then validate if the backlog addresses the project’s scope for the client.

3. Understand the Client and its Potential Customers

Depending upon the complexity of the problem that the application is intended to solve, a UX design
anchor is taken on board along with the BA for the discovery phase. The UX analyst’s prime
deliverable is to understand the client and their potential customers.
The UX analyst works on the personas of the possible user group who might use the application, the
ecosystem in which the personas will be using it, and the touchpoints of the user personas within the
system. The deliverables would include ecosystem maps, personas, user journeys, and storyboards.

4. Prioritize Requirements
The discovery team becomes involved in the agile cost estimation project and works on the high-level
backlog after the stakeholder has validated it.
The analysis is employed with the prioritization method to decide which requirements to complete first,
which ones can come later, and which ones to exclude. The backlog items are divided based on the
MoSCoW method, which segments features based on must-haves, should-haves, could-haves & won’t-
haves.

5. Prepare the Minimum Viable Product (MVP) Backlog

Based on the prioritization activity, the BA assembles the requirements as ‘must-haves’ to the backlog
and sections them as the requirements for MVP Development. The MVP backlog might also contain a
few items from the ‘should haves’ list, ensuring that the product is sufficiently competitive in the
market.
P.S.: In some instances, depending on the budget and time to market, this step is skipped, and the agile
teams jump directly to developing the fully-fledged product.

6. Estimate the Project Cost and Timeline

The discovery team estimates the MVP backlog to define the estimated cost and timeline for the first
release. This is followed by build, rinse, and repeat until they arrive at an estimate that fits the business
needs. This also allows flexibility to load and offload features as product development starts.

Steps to Successful Story Point Estimation in Agile

The story points approach in the Agile estimation technique uses historical data to compare features of
previous, similar projects to generate a precise estimate. The steps involved in the estimation method
with story points are as follows:

i. Identify user stories

ii. Discuss the requirements of the user story. It is the responsibility of the Product Owner or business
analyst to answer the questions and explain what precisely the referred story entails.

iii. Create a matrix for estimation. The estimation matrix is a numeric scale used to evaluate the
selected pieces of work. This scale can be the Fibonacci sequence 5, 8, 13, 21, 34) or the
straightforward linear scale (3, 4, 5, 6, 7..).
iv. Choose an Agile estimation technique.

v. Conduct sprint planning

vi. Validate that the estimates are internally consistent and align with the stories as the process goes
along.
TARGETING AND MOTIVATING THE TEAM

1. Set clear goals

Nothing demotivates people more than running in circles without clear goals and objectives. Even if
people aren’t 100 percent on board with a given direction, having one is still better than ambiguity.

Make sure an objective is always there — ideally, both long-term and short-term. The long-term goal
serves as a north star and helps the team see the bigger picture. Short-term objectives give the team
something tangible they can self-organize around.

And don’t forget to celebrate milestones.

2. Give people space

A micromanaged team will be disengaged, period. And why would you even try to micromanage
people? At the end of the day, nothing beats a team’s collective wisdom and expertise.

I believe, most of the time, micromanagement doesn’t come from bad intentions or a lack of trust. It
comes from impatience.

It takes time — and I’m talking months, not days — for a members of team to truly get to know each
other, develop a sense of ownership, and understand the scope of their work. Too often, managers tend
to be impatient and jump into “temporary” micromanagement to get things moving while the team
gains speed.

But it also teaches the team that the manager comes with tasks and solutions, so it never actually
matures as a team. This leads to more micromanagement and, eventually, you end up with a
disengaged feature factory.

There are no shortcuts here; you must give the team time and coaching if you want an engaged and
autonomous team. Pay the price early or pay interest in the long run.

3. Trust over explanations

One of the signs of a team that trusts each other is that people don’t need explanations from each other.
Why would you?

If someone has to leave earlier today, that’s fine. Need to take an unplanned day off on Friday? Fine
with me. Do you have to skip daily tomorrow? That’s okay.
Ask for an explanation only when you really need for the team to perform better. If someone is late
with a task, it’s okay to dig deeper for the reasons — maybe someone will be able to help with the
problem — but don’t grill people just for the sake of micromanaging them.

If someone comes to me with the information — e.g., they’ll need an additional day to complete
something — I trust them as professionals and take their word that did their best to achieve our goals.
If they didn’t manage to do so, there’s a valid reason behind it. There’s rarely a need for further
explanation.

4. Build relationships

A team that bonds together works better together. The dynamics are just so different when you work
with a group of close colleagues, or maybe even friends, versus just random people. Disappointing
teammates is one thing, but disappointing friends is another.

Invest time in fostering relationships between people. This can include big activities, like regular
offsites and workations, as well as smaller gestures, like celebrating birthdays or having a virtual coffee
every week.

5. Facilitate killer retrospectives

A retrospective can be a game-changing ceremony that helps the team reach a new level if facilitated
well.

If facilitated poorly, it can be a wasted time. Or, worse, a meeting in which everyone leaves annoyed
and angry with each other.

Retrospectives have a significant impact on the whole team. If you use every single one of them right,
you’ll have a great-performing team in no time. But it does require some effort.

Read about various retrospective formats, prepare before facilitating one, gather feedback, and improve
continuously. Don’t treat the retro as a meeting where you come to ask, “What went well and wrong?”
Treat it as a potentially game-changing workshop that deserves effort and preparation.

6. Keep cameras on

The remote work trend forces us to see each other less and less. In the past, we used to see each other
daily. Now, our face-to-face interactions happen mostly on video calls.

Don’t diminish these opportunities even further by turning cameras off.

Cameras help us see one another as humans. Plus, they keep us more focused on a meeting. This
additional focus leads to more active and fruitful discussions.

If you need to multitask or zone out during a meeting, the problem is the meeting itself, not the camera.

7. Recognize small acts of greatness

Whenever someone does something good, recognize it immediately. Don’t wait until the performance
review, and don’t neglect small things.

Ultimately, it’s these regular, small acts of greatness that matter, not occasional heroic actions, that
help us reach our goals.
If you see someone acting in a way you’d like the team to follow (e.g., taking initiative, raising a
problem and bringing solutions, etc.), recognize it and praise the person publicly.

It’ll both reinforce the desired behavior and communicate to the rest of the team what type of behavior
is expected.

8. Mix big bets with small wins

Big bets give the team a sense that they’re working on something complex and truly meaningful. Small
wins let them drive quick results and get a sense of achievement.

You need both. When planning the roadmap with the team, make sure to include both small wins and
big bets.

If you focus only on big bets, a lack of immediate results and things to celebrate might be demotivating.
On the other hand, if you focus only on small wins, the team might start feeling that they are running in
circles over-optimizing the product.

Give the team the energy and motivation to seize big bets by making sure they regularly achieve and
celebrate some smaller victories. Don’t over focus on one of the two.

9. Build a strong feedback culture

A strong feedback culture is essential for the team to perform at its best. It serves two purposes.

First, it allows everyone to be heard, share their thoughts, and contribute to the team’s future. People
are more likely to challenge the status quo and bring feedback when they see it makes an actual impact.

It also helps people grow. When they receive meaningful feedback constantly, they develop as
professionals. And the more people grow, the more engaged they tend to be.

Strive to build a culture where feedback is the bread and butter of the team. It requires:

o The right mindset toward giving and receiving feedback

o A sense of safety within the team
o Feedback loops and processes that make giving and receiving feedback easy
Implement these in a team, and you’ll see results.

10. Challenge people

Make sure everyone on your team can work on something slightly above their current skill level.

When people are challenged, they grow more. And people that develop a lot in their day-to-day work
are usually more engaged and motivated than people who stagnate.
 Always make sure to put the bar just slightly out of reach. If the bar is too low, there’s no motivation to
engage. On the other hand, if the bar is too high and seemingly out of reach, it might be more
demotivating than motivating.

MANAGING BUSINESS INVOLVEMENT:

In Agile environments, the BA transcends traditional roles, often acting as a Business Advisor and
Coach. This multifaceted role involves:

1. Assisting product owners in comprehending business needs

 Interconnecting business and technical realms. BAs aid product owners in comprehending
complex business requirements and how they translate them into product features.

 Strategic advice. They provide insights into market trends, customer needs, and competitive
landscapes, helping product owners make informed decisions.

 Example. An Agile BA might assist a product owner in an e-commerce project by analyzing

customer shopping patterns to recommend features that enhance the user experience.
2. Facilitating collaboration and transferring knowledge

 Team integration. Agile BA’s foster a collaborative environment where knowledge and ideas
are freely shared between the product owner, development team, and stakeholders.

 Knowledge sharing. They conduct workshops and training sessions to make sure that all the
team members are on the same page with the project’s objectives and understand the Agile
methodologies.

 Example. A BA might facilitate regular brainstorming sessions in a software development

team where team members can contribute ideas and collectively refine the product roadmap.
3. Generating examples and guiding teams

 Creating prototypes and use cases. BAs develop practical examples such as user scenarios,
prototypes, or mock-ups to clarify requirements and guide development efforts.

 Guidance and support. They guide teams through the Agile process, providing support in
interpreting user stories’, acceptance criteria, and ensuring alignment with business goals.

 Example. The BA might create user journey maps and personas for a mobile app development
project so as to help the development team understand the end users’ perspectives and desires.
In this advisory and coaching capacity, an Agile Business Analyst (BA) champions the effort of teams
remaining focused on delivering business value. They act as catalysts for effective communication and
collaboration, establishing that all team members are clearly aware of the business objectives and the
means to achieve them. Their ability to translate business needs into actionable insights for product
development is crucial for the success of Agile projects.

Creating a Business Analysis plan in an Agile team

Creating a Business Analysis Plan is a crucial step in the Agile framework that vouches for the layout
of business analysis activities with Agile methodologies. This plan outlines how Business Analysts
(BAs) will integrate their role into the Agile process, emphasizing flexibility and continuous
collaboration.
 Integrating Business Analysis into Agile processes

Incorporating business analysis into Agile processes is a vital function of Agile BAs, who assert that
the analytical activities seamlessly align with Agile principles and foster a flexible iterative approach.

 Alignment with Agile principles. Agile BAs integrate business analysis by lining up activities
with Agile principles, safeguarding a versatile and intermittent approach to requirements.

 Continuous collaboration. They work closely with Agile teams throughout the project,
maintaining ongoing collaboration and adaptation to change.

 Case. In an Agile project, BAs might integrate business analysis into daily stand-ups and sprint
planning sessions to continuously match the business needs with development activities.
Through continuous teamwork and alignment with Agile principles, Agile BAs enhance the efficacy of
Agile teams, ensuring that business analysis is not just an activity, but an integral part of the Agile
process.

Planning for multiple iterations of detailed requirements

Agile BAs are pivotal in planning and adapting requirements through multiple iterations, a process
central to the Agile methodology’s focus on delivering continuous value.

 Iterative requirement refinement. Agile BAs plan for and manage the evolution of
requirements over multiple iterations, guaranteeing that each sprint delivers value and connects with
the overall project goals.

 Backlog prioritization. They prioritize the product backlog to reflect changing business needs
and stakeholder feedback.

 Case. Based on user feedback and testing results, the BA would iteratively refine user stories
and acceptance criteria across sprints for a new software feature.
Agile BAs’ iterative refinement of requirements and competent backlog prioritization double check
that each sprint is purposeful and closely aligned with the evolving business necessities and stakeholder
feedback.

Supporting the technology team during sprints

In Agile teams, the role of BAs extends to providing crucial support to the technology team, facilitating
an extensive knowledge of project requirements, and aiding in problem-solving.

 Facilitating understanding. Agile BAs support the technology team by clarifying

requirements, answering questions, and ensuring a shared sense of the project goals.

 Problem-solving. They assist in resolving any ambiguities or issues during sprints as a bridge
between technical and business perspectives.

 Case. During a sprint focused on developing a new API, the BA would work closely with
developers to assure that they fully realize the business context and user needs.
By engaging with the technology team during sprints, Agile BAs play a critical role in spanning the
gulf between business perspectives and technical execution, verifying project goals are met with clarity
and efficiency.

The Business Analysis Plan in Agile is a dynamic blueprint that guides BAs in effectively integrating
their expertise into Agile projects. It underlines the importance of iterative planning, continuous
stakeholder collaboration, and proactive support for the technology team, making certain that Agile
projects are well-aligned with business objectives and adapt to changing conditions.

ESCALATION ISSUE IN AGILE METHODOLOGY:

Escalation is the process of bringing a project issue up to a higher authority for timely resolution. There
is no standard procedure when it comes to escalating project issues, but here’s a step-by-step guide to
help you get started.

1. Identify the problem

Start by identifying the problem(s) that you want to address and explain it in a way that can be easily
understood by all types of stakeholders. Failure to do so could make it difficult to comprehend how
serious the problem is, which could lead to a poor or mismanaged escalation.

2. Gather evidence
Take some time to gather pieces of evidence or supporting facts that reinforce the need for project
escalation. While this step is optional, presenting evidence that further highlights the issue at hand will
definitely help your cause. Make sure you have a copy of any records, receipts, or agreements that will
be presented once the issue is ready for escalation.

3. Delegate responsibilities
If any of the tasks or activities that need to be done as part of the escalation process can be handled by
project team members, make sure to assign these responsibilities and prioritize them accordingly.

4. Determine the correct authority

Before initiating a project escalation, it’s critical that you know the right authority figures to speak to.
Approaching the wrong stakeholders will only muddy the process further, and the case might even get
lost in the day-to-day shuffle. You might even need to present your case to multiple stakeholders in
order to achieve the desired result.

5. Make your presentation

Now it’s time to make your case for the escalation. Describe the issue as clearly and concisely as
possible, present any evidence you’ve gathered, and highlight any attempts you’ve already made to
resolve the issue. The more information you can provide during your presentation, the more likely that
stakeholders will understand the problem for themselves, which should lead to a positive and
productive escalation.

In Agile methodologies, quality, risk, metrics, and measurements are critical components that help
teams deliver value efficiently while maintaining high standards. Here's how they are integrated into
Agile practices:

QUALITY, RISK, METRICS AND MEASUREMENTS:

1. Quality in Agile
Quality in Agile is not an afterthought but is built into the process from the start. It focuses on
delivering a product that meets customer needs and expectations.

- Key Principles:

- Continuous Integration (CI): Frequent integration of code to detect issues early.

- Test-Driven Development (TDD): Writing tests before code to ensure functionality.

- Definition of Done (DoD): A shared understanding of what "done" means for a user story or task.

- Automated Testing: Reduces manual effort and ensures consistent quality.

- Customer Collaboration: Regular feedback from stakeholders to ensure the product meets their
needs.

- Practices:

- Pair programming to improve code quality.

- Regular code reviews and refactoring.

- Sprint retrospectives to identify quality improvements.

2. Risk Management in Agile

Agile approaches risk management iteratively and incrementally, addressing risks as they arise rather
than trying to predict all risks upfront.

-Key Principles:

- Transparency: Risks are made visible to the entire team.

- Early Identification: Risks are identified during sprint planning, daily stand-ups, and retrospectives.

- Incremental Mitigation: Risks are addressed in small, manageable steps.

- Adaptability: Agile teams can pivot quickly to address emerging risks.

- Practices:
 - Risk burn down charts to track and mitigate risks over time.

- Regular risk assessments during sprint reviews.

- Maintaining a risk register to document and prioritize risks.

3. Metrics and Measurements in Agile

Agile metrics help teams track progress, identify bottlenecks, and improve performance. These metrics
should be simple, actionable, and focused on delivering value.

- Key Metrics:

- Velocity:Measures the amount of work a team completes in a sprint. Helps in forecasting future
sprints.

- Burn-down/Burn-up Charts: Tracks progress toward sprint or release goals.

- Cycle Time: Measures the time taken to complete a task from start to finish.

- Lead Time: Measures the time from request to delivery.

- Cumulative Flow Diagram (CFD): Visualizes work in progress and bottlenecks.

- Sprint Goal Success Rate: Tracks how often the team achieves its sprint goals.

- Defect Rate: Measures the number of defects found during or after a sprint.

- Team Satisfaction: Gauges team morale and engagement.

- Best Practices:

- Use metrics to inspire improvement, not to punish or micromanage.

- Focus on outcomes (e.g., customer satisfaction) rather than outputs (e.g., lines of code).

- Regularly review metrics in retrospectives to identify areas for improvement.

4. Integrating Quality, Risk, and Metrics in Agile

- Iterative Improvement: Use retrospectives to reflect on quality, risks, and metrics, and implement
changes in the next sprint.

- Collaboration: Ensure the entire team (developers, testers, product owners) is involved in managing
quality and risk.

- Transparency: Make quality standards, risks, and metrics visible to the team and stakeholders.

- Customer-Centricity: Align quality and risk management with customer needs and expectations.

5. Tools for Managing Quality, Risk, and Metrics

- Quality: Jira, Jenkins, Selenium, SonarQube.

- Risk:Risk registers, Jira (for tracking), Confluence (for documentation).

- Metrics:Jira dashboards, Azure DevOps, VersionOne, or custom dashboards using tools like Power
BI or Tableau.

By integrating quality, risk management, and metrics into Agile practices, teams can deliver high-value
products while continuously improving their processes.
 UNIT IV
AGILE REQUIREMENTS AND AGILE TESTING

WHAT ARE AGILE USER STORIES?

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature,
expressed from the software user’s perspective.

A user story is an informal, general explanation of a software feature written from the perspective of
the end user or customer.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to
the customer. Note that "customers" don't have to be external end users in the traditional sense, they
can also be internal customers or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into
detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to
sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their
backlog and run them through their workflow. It’s this work on user stories that help scrum teams get
better at estimation and sprint planning, leading to more accurate forecasting and greater agility.
Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine
their workflows.

User stories are also the building blocks of larger agile frameworks like epics and initiatives. Epics are
large work items broken down into a set of stories, and multiple epics comprise an initiative. These
larger structures ensure that the day-to-day work of the development team (on stores) contributes to the
organizational goals built into epics and initiatives.

Learn more about epics and initiatives

Why create user stories?

For development teams new to agile, user stories sometimes seem like an added step. Why not just
break the big project (the epic) into a series of steps and get on with it? But stories give the team
important context and associate tasks with the value those tasks bring.
User stories serve a number of key benefits:

 Stories keep the focus on the user. A to-do list keeps the team focused on tasks that need to be
checked off, but a collection of stories keeps the team focused on solving problems for real users.

 Stories enable collaboration. With the end goal defined, the team can work together to decide
how best to serve the user and meet that goal.

 Stories drive creative solutions. Stories encourage the team to think critically and creatively
about how to best solve for an end goal.

 Stories create momentum. With each passing story, the development team enjoys a small
challenge and a small win, driving momentum.
See how user stories work in Jira

Working with user stories

Once a story has been written, it’s time to integrate it into your workflow. Generally a story is written
by the product owner, product manager, or program manager and submitted for review.

During a sprint or iteration planning meeting, the team decides what stories they’ll tackle that sprint.
Teams now discuss the requirements and functionality that each user story requires. This is an
opportunity to get technical and creative in the team’s implementation of the story. Once agreed upon,
these requirements are added to the story.

Another common step in this meeting is to score the stories based on their complexity or time to
completion. Teams use t-shirt sizes, the Fibonacci sequence, or planning poker to make proper
estimations. A story should be sized to complete in one sprint, so as the team specs each story, they
make sure to break up stories that will go over that completion horizon.

How to write user stories

Consider the following when writing user stories:

 Definition of “done” — The story is generally “done” when the user can complete the outlined
task, but make sure to define what that is.

 Outline subtasks or tasks — Decide which specific steps need to be completed and who is
responsible for each of them.

 User personas — For whom? If there are multiple end users, consider making multiple stories.

 Ordered Steps — Write a story for each step in a larger process.

 Listen to feedback — Talk to your users and capture the problem or need in their words. No need
to guess at stories when you can source them from your customers.

 Time — Time is a touchy subject. Many development teams avoid discussions of time altogether,
relying instead on their estimation frameworks. Since stories should be completable in one sprint,
stories that might take weeks or months to complete should be broken up into smaller stories or
should be considered their own epic.

Once the user stories are clearly defined, make sure they are visible for the entire team.

User story template and examples

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down:

 "As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the
persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve
hopefully interviewed plenty of Max’s. We understand how that person works, how they think and
what they feel. We have empathy for Max.
 “Wants to”: Here we’re describing their intent — not the features they use. What is it they’re
actually trying to achieve? This statement should be implementation free — if you’re describing
any part of the UI and not what the user goal is you're missing the point.
 “So that”: how does their immediate desire to do something this fit into their bigger picture?
What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?
For example, user stories might look like:

 As Max, I want to invite my friends, so we can enjoy this service together.

 As Sascha, I want to organize my work, so I can feel more in control.
 As a manager, I want to be able to understand my colleagues progress, so I can better report our
sucess and failures.
This structure is not required, but it is helpful for defining done. When that persona can capture their
desired value, then the story is complete. We encourage teams to define their own structure, and then to
stick to it.

Getting started with agile user stories

User stories describe the why and the what behind the day-to-day work of development team members,
often expressed as persona + need + purpose. Understanding their role as the source of truth for what
your team is delivering, but also why, is key to a smooth process.

Start by evaluating the next, or most pressing, large project (e.g. an epic). Break it down into smaller
user stories, and work with the development team for refinement. Once your stories are out in the wild
where the whole team can see them, you’re ready to get to work.
An Agile backlog (back log) is a prioritized list of features, bugs, technical work, and knowledge
acquisition needed to meet the desired functionality in the product. Your backlog is the roadmap
for your product.

How do You Manage a Backlog?

Backlog management is the process by which the product owner (often in

collaboration with others) adds, adjusts, grooms, and prioritizes backlog items within
the backlog to make sure the most valuable product is shipped to customers.

An oversized product backlog is a problem. It impedes innovation. It slows time to market. And it
causes frustration in even the best Agile teams. In this post, we'll cover common challenges of
oversized backlogs and how to fix them.

Agile Backlog Management Challenges

In an Agile development organization, the main tool to manage the road map and gain predictability is
the backlog. But if it grows uncontrollably, the value it provides diminishes.

An unreasonably long backlog is a major pain point for many Agile teams. By virtue of the shear
amount of information, it becomes unmanageable and irrelevant. It will then be abandoned. Teams
will resort to reactive sprint planning. In turn, they'll lose sight of the long-term goals and end up in a
very task-focused environment. Because it's much easier to think about what you need to do now than
what you need to achieve in the distant future.

An overly large backlog causes many problems.

Maintenance costs — We suffer from a blindness to queues. Queues incur cost; each item will
continuously require a little attention to remain valid. Grooming a fat backlog can seem like an
insurmountable task, which means that it is omitted. Eventually this leads to the entire backlog
becoming obsolete.

Value reduction — Each item, in a backlog of tens of thousands of items, will seem insignificant.
Adding a new item will feel pointless. When backlogs get too big, they become a trash bin where all
work you want to do, but never will, ends up.

Inhibited innovation — Since reorganizing a big backlog is such a chore, brilliant ideas are either
added at the front or the end of the backlog. Adding items to the front means that you are invalidating
the rest of the backlog, while adding them to the end guarantees they never will be done.

The referenced media source is missing and needs to be re-embedded.

Back to top

Why Do Product Backlogs Get Too Big?

With these problems in mind, let's look at how backlogs become oversized. Truth is, there is not a
single cause, but often a combination.

Hoarding — Humans are hoarders by nature. We have a hard time throwing away anything,
especially good ideas. The key to managing the backlog is not to know what should go in, but
deciding what should go out.

Information need —There is a lingering belief that keeping track of everything at a granular level
gives us a good idea of the scope. However, as responding to change is an important part of agile
development the further in the future we have plans the less certain they are. Thus the granularity
needs to reflect that. In the term DEEP, which is often used to describe a good backlog, the D stands
for Detailed appropriately and describes the solution to this problem.

Dependency resolution — When we are not truly Agile we strive toward resolving dependencies far
into the future. To identify dependency chains, we break down large items into their components and
reduce goals into tasks. This has a double-negative effect on backlog quality. First, it makes the
backlog balloon. Second, it means that our backlog is no longer value driven, and instead heavily
focused on what work we need to do.

No commitment to product owner role — Most products organizations have way too few product
owners in comparison to the team size, and they have limited time to manage the backlog. The
product owner responsibility is something that shouldn’t be taken lightly.

6 Tips For a Backlog

Here are a few action items for improving your backlog size.

1. Take the Product Owner Role Seriously

There should be one person — no more, no less — responsible for the backlog of each scrum team.
Ideally, that person is only responsible for one team backlog as well. That person needs to have plenty
of time available for maintaining the backlog in collaboration with the team and external stakeholders.
She needs to be knowledgeable about the product and have the authority to make decisions within the
backlog without involvement of other parties.

2. Limit Design in Process

A good starting point would be to start looking at your Design in Process (DIP) inventory, a term
coined by Donald Reinertsen. What you want to do is set a limit as to how many items you can have
in the backlog. There is not a size that fits all. But a starting point would be size per product owner
(PO). Since a PO is mainly responsible for a backlog, her capacity to administer the information is the
limitation. Thus, a large product with ten PO’s, responsible for different areas, could have a backlog
that is double the size the backlog of a product with five PO’s. Generic advice? Dunbar’s
number gives good guidance in this situation. It says that one PO could handle around 150 items at
any given time. We should also consider DIP for amount of work to ensure that our pipeline isn’t
planned for years and years as this could seriously inhibit innovation. However, it’s hard to give a
generic advice on how long a roadmap should be as it depends on a lot factors, such as product type
and market maturity.

3. Decide How to Manage the Backlog

Create a simple and clear strategy of how you will manage your backlog and involve the team in that
process. The product owner holds the responsibility to maintain the backlog, but she is not the only
one that contributes to the vision. Everyone on the team can and should contribute and continuously
participate in the process of keeping the backlog fresh. For this to work, everyone needs to have a
rough understanding for backlog as this is the product’s vision and road-map.

4. Make Decisions

Restrain yourself from entering every idea that comes up, keep it in your head and if it still is in there
after a week it might be worth adding to backlog. In association to that you should have a soft “one in,
one out” policy as you are hitting the DIP limit you have set for yourself. And yes, it is hard to discard
things but having that ability is an important trait of a product owner.
5. Work With an Aging Idea Funnel

A product backlog, and a team backlog, can be divided into several stages where the DIP limit could
be more difficult the closer they are to implementation. The simplest approach would be to dedicate
one portion of the backlog to new ideas, and another portion which is more thoroughly groomed and
restricted in size. Give the ideas an age limit so that the ones that are not being prioritized are
disappearing over time to avoid flooding this part. When the idea is moved to the next part, it
indicates a commitment from the PO that this idea will actually be implemented eventually.

6. Follow Your Own Rules

If you apply strict DIP limits you might be tempted to bypass your own rules and instead pack an
abundance of information into each item. Don’t do that.

AGILE ARCHITECTURE:

FDD :
FDD stands for Feature-Driven Development. It is an agile iterative and incremental model that
focuses on progressing the features of the developing software. The main motive of feature-driven
development is to provide timely updated and working software to the client. In FDD, reporting and
progress tracking is necessary at all levels. In this article we will see Feature-Driven Development in
detail.
History of FDD
FDD was first applied in the year 1997 on a real-world application by Jeff De Luca for large software
development with specific needs of 15-month and 50 persons and published as a discussion in book
Java Modeling in Color with UML in the year 1999.
FDD Lifecycle
 Build overall model
 Build feature list
 Plan by feature
 Design by feature
 Build by feature

Characteristics of FDD
 Short iterative: FDD life cycle works in simple and short iterations to efficiently finish the
work on time and gives good pace for large projects.
 Customer focused: This agile practice is totally based on inspection of each feature by client
and then pushed to main build code.
 Structured and feature focused: Initial activities in lifecycle builds the domain model and
features list in the beginning of timeline and more than 70% of efforts are given to last 2 activities.
 Frequent releases: Feature-driven development provides continuous releases of features in the
software and retaining continuous success of the project.
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.

AGILE RISK MANAGEMENT:

What is the Agile QA Process?
The Agile Quality Assurance (QA) is a process that focuses on continuous testing and collaboration
throughout the lifecycle of the product. It involves Continuous testing in parallel with development
so that we can quickly identify and resolve the defects in the project. It also defines the automated
test cases to reduce the time spent in the testing activities. Due to this, the team can focus on more
important tasks.
1. This iterative and collaborative approach ensures that software is not only functionally
correct but also fulfills the expectations of the end-users.
2. QA Testing focuses more on finding the errors or bugs early before they become a severe risk
for the project.
Role of QA Testing in Agile Project
Here are the following Role of QA Testing in Agile Project:

Role of QA
Testing in Agile Project

1. Early Sprint Planning for Early Delivery

 Sprint, which lasts typically 2-4 weeks involves the iteration through which the project
deliverable is developed. Thus, a sprint is a quick short development cycle. But the QA Testing
makes it faster and shorter development cycle.
 The QA Testers participate in the stand-up sessions to identify the user stories, acceptance
criteria, and potential testing scenarios. Thus, it does not happen that the testing is done after
development. It starts right from the project development starts
 In other words, the Testers can pre-plan which user stories to work on. Due to this, the Agile
Process becomes more focused throughout the entire project.

2. Cross-functional Operations for Collaborative Approach

 The cross-functional collaboration is a crucial part of the Agile Principles. Sometimes, we are
required to get involved in a domain in which we are not familiar. Hence, QA Testing allows us
to interact with people of different skills to execute the project tasks.
 In this QA Testing Process, the testers actively participate in cross-functional teams to
collaborate with the developers, testers, and other project stakeholders. Generally, they use stand-
up sessions, discussions, and planning meetings with the developers, product owners, and other
stakeholders.
 This collaborative approach enhances the efficiency and effectiveness of the entire
development process. As a result, our project becomes more integrated.

3. Validating the Definition of Done

 The Definition of Done (DoD) is a set of criteria that must be fulfilled for a user story or a
test scenario before the QA Tester marks them to be considered complete. Thus, QA Testing
assures that each Agile task aligns with DoD throughout the lifecycle.
 The QA process allows us to review and assess each user story against the defined acceptance
criteria, functional requirements, and quality standards. Once the acceptance criteria are fulfilled,
the project archives completeness.
 The validation of various criteria is important for maintaining a consistent delivery pipeline
of the project outcomes so that we can prevent technical issues from becoming a part of the
project.

4. Acceptance Tests to Capture the Market

 QA testing includes the creation of the Acceptance Tests. These tests validate whether the
developed features are in line with customer expectations and market requirements or not.
 Acceptance tests in the Agile QA Testing Plan are also capable of finding the bugs or errors
that can impact the user experience in the product. Hence, the product can get approval from the
stakeholders easily.
 For creating the Acceptance Tests, user feedback can be taken early in the development
process. This proactive approach not only enhances customer satisfaction but also eagles us for
quick adjustments to the product based on market demands.

5. Ownership for Project Stability

 The Agile QA Testing process focuses on taking Ownership of the Project. It means that the
team becomes liable for changes, updates, or new features. The QA Process ensures the code
quality but ownership of the project makes the team more responsible for making the best efforts
for project delivery.
 The feeling of ownership in the development team and stakeholders makes communication
strong. Hence, Agile QA also helps us to maintain transparency in the project processes.
 Therefore, the overall stability of the project is increased and it is ensured that the changes or
new features do not impact the existing functionality of the project.
Example of QA Testing in Agile
Till now, we have covered all the information about the Role of QA in Agile. Let us now understand
this concept using a practical example. Consider the project of an e-commerce application
development using Agile Methods. Once the project starts with the initial phase, the QA Process
starts.
1. Firstly, QA Testers collaborate with the product owner and the development team to define
acceptance criteria for user registration. This includes aspects like successful user creation,
validation of input fields, and secure password handling. The QA team then creates test cases
based on these criteria.
2. After this, they implement QA testing is applied iteratively to validate each user story against
the acceptance criteria. This approach allows us to quickly identify and resolution of issues,
preventing the Following image from highlighting the activities in this QA Process. The
following image highlights
Sprint/Phase Activities

Planning  Implement functionality

 Collaborate on criteria
 Define pep: user creation, validation, security

Implementation Testing Phase

 Create test cases
 Execute automated tests
 Explore edge cases, scenarios
 Collaborate on defect resolution

Validation and Issue-fix Iterative Testing

 Iterate on new features
 Validate against criteria
 Quick issue resolution

POPULAR AGILE TOOLS FOR SOFTWARE DEVELOPMENT

An Agile Tool for software development is a software application or a platform that enables the teams
to manage and track the Agile project more efficiently. These Agile methodologies are increasing day
by day in project management due to their flexibility and ability to adapt to the changes in the
requirements of the projects. Agile is referred to as a project management methodology that is
particularly used to break difficult projects into smaller, more focused chunks so teams can work in
short, incremental phases. There is a wide range of agile tools which are available in the market that
help the teams with planning, visualization, and collaboration process throughout the journey of
software development.
What are Agile Tools in Software Development?
An Agile Tool for software development is a software application or a platform that enables the teams
to manage and track the Agile project more efficiently. These Agile methodologies are increasing day
by day in project management due to their flexibility and ability to adapt to the changes in the
requirements of the projects. Therefore these agile tools provide a digital workspace where the teams
can plan, collaborate, and execute their projects by using the principles of Agile.
Popular Agile Tools for Software Development
There are multiple Agile tools which are used in Agile Software development and these tools consist of
various features which helps the software developers to increase the efficiently of the Agile project
development. Therefore some of the most popular Agile tools which are used in Agile Software
development are mentioned below:

Agile Tools
1. Jira: An Agile Tool
Jira is the most widely used Agile tool which is mainly used for issue tracking, bug tracking and agile
project management, it is also used by a large number of clients and the users all over the world. Jira
tool is also used for backlog tracking and release planning , CI/CD and developer tools integrations.

Features:

 Jira offers multiple features such as project tracking, reporting, tracking and collaborating with
the team.
 Jira also provides tracking and planning tools which mainly helps the teams to manage the
dependencies, feature the requirements and stakeholders one by one.
 Jira mainly offers issue prioritization and also allows the software testers to point out the major
issues in the software development and products.
2. ClickUp: An Agile Tool
ClickUp is one of the most popular agile tools which is used to improve productivity and this tool also
allows the teams to work together on the given tasks and projects. ClickUp has a user-friendly interface
which helps the users to customize their workspace and with its multiple features it helps the
developers

Features:

 ClickUp mainly consists of over 15 views which include Board, Timeline, Gantt chart and so
on.
 ClickUp consists of a Drag and drop feature available.
 There is also a time tracking feature available to record the time spent on the task.
3. Mural: An Agile Tool
Mural is one of the digital collaboration platforms which helps the teams in providing the functionality
for the project planning. It is an easy to use white board which provides both a collaborative space and
the training to enhance the team’s collaboration abilities. The users of Mural tool can make plans and
also coordinate in a single place.

Features:

 Mural provides an exclusive framework and templates which includes lean, agile and design
thinking.
 Mural tool offers virtual whiteboard which works as a canvas for the team collaboration with
the visual element.
 Mural comes with multiple collaboration tools which allow the team members to work together
in a real time.
4. Kanbanize: An Agile Tool
Kanbanize is a web based tool used in agile tool which increases productivity and accelerates with the
team output. Kanbanize is used to manage the workflow by using the Kanban method, the
customizable Kanban board can sync with any team requirement.

Features:

 Kanbanize offers flexible and customizable Kanban board where the teams can customize to
the fit and their needs.
 Kanbanize integrates with GitHub, Jira, Slack and with other multiple tools.
 With the help of Kanbanize, teams can personalize the workflow for multiple projects and
teams.
5. GitHub: An Agile Tool
GitHub is another widely used web based platform ideal for project management as it allows the
software development teams to perform the tasks effectively and track the progress of the task at one
place. GitHub allows sharing the tasks and it also allows collaboration with the other team members.

Features

 GitHub helps in safely managing the templates and also repositories of the codes.
 GitHub improves the code writing and increases the safety of the code.
 With the help of GitHub easy code hosting and effective team management is possible.
6. Monday.com: An Agile Tool
Monday.com is a Work Operating System which is used to manage all your team’s work at a place.
Monday tool particularly allows the businesses to assign the tasks, set the budget and monitor the
progress and track the projects which further helps the developers in the agile software development.
Key Features:
 Monday consists of automations to save time on the tasks and work in a smart way.
 It integrates with the multiple work tools, such as Gmail, HubSpot or slack
 Monday is one of the Secure platforms to ensure data privacy.
7. Jenkins: An Agile Tool
Jenkins is an open source and free automation server ideal for creating, testing and deploying the
software applications, it is one of the most popular automation servers which is used in the DevOps
community. Jenkins is used for automatically building, testing and deploying the applications
whenever the codebase is modified.

Features:

 Jenkins allows the distributed builds to various computers for increase in the performance.
 Jenkins integrates with the different tools used throughout the lifecycle of software
development.
 Jenkins supports complex projects which consist of thousands of builds per day.
8. Shortcut: An Agile Tool
Shortcut is an agile tool for software development which combines planning and development for the
project into a unified experience, this tool allows you to develop the ideas through the shortcut docs
and collaborate with the design specs, PRDs and MVPs.

Features:

 Shortcut helps the users to view and monitor the work progress through the Kanban board.
 Shortcut integrates with GitLab, Slack and GitHub and completes the overview of the work
progress through the analytics and reporting.
9. Asana: An Agile Tool
Asana is another popular agile tool for software development which helps the teams to organise the
tasks in a better way and helps in setting the priorities and deadlines to generate the reports in no time.
Asana integrates with more than 100 collaboration tools to keep all the communications at one place.

Features:

 Asana helps in setting priorities and deadlines between the team members.
 Asana is one of the great tools which integrates with other tools.
 By using Asana developers can easily generate graphs.
10. Planbox: An Agile Tool
Planbox is a type of cloud based agile tool designed for the project managers for all the businesses to
develop a collaborative environment among the team members, partners and between the customers, it
helps the teams to receive the feedback and quickly adapt to the changes.

AGILE TESTING TECHNIQUES:

Testing is an integral part of software development and it goes hand in hand with the requirement
creation activities. There can be a structured and systematic approach to testing in agile projects too. As
there are multiple releases usually defined in Agile projects, testing plays an important role in the
quality control of the product or service.
In Agile, emphasis is given to the requirement analysis discussion where team members are expected to
work closely with the Product Owner and Business Analyst for the user stories and its acceptance
criteria development. Tester’s involvement is necessary right from the initiation of the project so that
they can actively participate in defining the definition of Done, exploration of User Stories, etc. Testers
should not remain idle or wait for requirements. They should follow up on validation criteria in order to
know what’s expected of a new feature or a change being made in the system. In Agile projects, each
team member irrespective of the work has to become more proactive, enthusiastic, and forward-
thinking in their interpretation of requirements.
Agility not only improves the software testing process but also adds flexibility and enhances ease of
use. Thus, agility leads to a ‘continuous process improvement’, which significantly increases testing
volumes because of satisfaction with the process.

Key Concepts

In Agile frameworks, both testing and development are carried out in the same sprint. Once the testing
team has a clear idea of what is being developed, the tester’s work on how the system would behave
after the new changes are incorporated and whether it satisfies the business needs or acceptance criteria.
In the time when the development team works on the design and code changes, the testing team works
on the testing approach and comes up with the test scenarios and test scripts. Once the code is ready to
be tested, the testing team starts the testing which needs to be completed by the end of the sprint. This
is quite possible in some scenarios when a module of the business need is made available to test. The
testing team is expected to work on smaller modules and test them as and when provided rather than
the whole functionality to be developed completely.

1. Test Strategy and Planning

Test strategy is an important artifact in testing a project. It’s the responsibility of the testing team to
have a structured and definite testing approach and strategy in the project. Unlike the traditional way,
in Agile as the scope of requirement and hence the testing do change very often, it is usually
recommended to update the test strategy at the beginning of each sprint. Documentation of this test
strategy starts from the Release initiation phase and acts as a living document throughout the Release.
Each sprint has its own scope of stories that need to be delivered. As part of the testing team, they can
create the test plan. This plan has to be updated in each Sprint and is continued till the release.
Traditionally in software projects, system testing is used to begin after the development team has
completed the integration and then the business owners used to carry out UAT (User Acceptance
Testing) after system testing. However, when it comes to Agile all these boundaries are very porous.
As an Agile team member, one has to test one functionality at the same time write a test plan for
another and at the same time review the design for another story and carry out many similar kinds of
activities all at the same point in time. Testers participate in design discussions in Agile projects. This
helps them plan their test cases in a better way.
In Agile, towards the end of every sprint, the team participates in the Sprint review with Business. In
these reviews, it’s primarily the responsibility of the team members involved in testing to prepare the
test data sheets and run the tests in front of the Business Stakeholders, Product Owners and show them
how the product is working and whether or not it’s meeting their Acceptance Criteria. This is a key
process in Agile and helps the team to collect feedback from the client and other stakeholders on the
user stories developed within the sprint. The testing team plays a pivotal role in this process.

2. Importance of Automation for Testing in Agile

Agile needs continuous testing of the functionalities developed in past Sprints. The use of Automation
helps complete this regression testing on time. It minimizes the rework that can happen due to error-
prone manual processes. It helps bring predictability to the tests run as part of Sprint testing. Helps to
cover more regression tests than it could have been done manually. This is very much required in Agile
as it has a higher number of builds and more frequent changes because of its iterative nature. The
resource is available for other tasks – Rather than retesting existing functionalities, testers can focus
their efforts on parts of new functionality that require manual intervention. Continuous regression
testing would require huge testing effort since we have to repeat the tests many times depending on the
iterations. The use of automation helps reduce this effort. The smaller automated test cases when
aggregated in each sprint, during the end of the project form an exhaustive regression suite that covers
almost all the functionalities from a system, regression, and acceptance testing point of view. Thus, it
helps in minimizing the cost of the project in the Release Sprint (last Sprint in the Release) – as the
majority of the testing can be handled through the existing automation.

3. Test Coverage in Agile

Considering a limited timeframe for a Sprint to complete the testing, identifying and finalizing the test
coverage for the user stories is one of the most important and challenging tasks in an Agile project.
Inadequate test coverage might result in missing critical tests for some requirements. Test coverage for
a user story is usually discussed and finalized during the backlog grooming sessions and later during
the Sprint Planning meetings. There are a couple of situations where test coverage might result in
missing out a few test scenarios which can be mitigated by creating a traceability matrix between
requirements, user stories, and test cases. A link can also be created between test cases and user
stories.
Another case might arise when a code change is done without complete impact analysis, review and the
corresponding changes in test cases needed could result in incomplete test coverage. This can be
mitigated by analyzing the impact, reviewing source code to identify modules that are to be changed,
and ensuring that all the changed code has been properly tested. Also, the use of code coverage tools
must be leveraged for verifiable thoroughness as part of the automation effort.

4. Test Data Management in Agile

Test data is one of the most important factors in testing. Creating and manipulating the data for testing
various test cases is one of the challenging tasks in testing. Agile Testing in Sprints gets difficult when
the system is dependent on another team for test data. The Sprint timelines do not give enough room
for any delays in the data setup. Setting up the test data is done along the Sprint to make available them
at least, just in time (JIT) if not earlier, by the time when the developer checks in his code for claiming
it ‘as done’. Since all of the developers usually practice test automation for unit testing and integration
testing and sometimes use the ‘test-driven development’ approach to complete their user stories, the
synchronized supply of the test data by the testing team is essential.
The analysis of the data needs is done during the backlog grooming sessions and the Sprint planning
meetings to ensure the complete data setup needs. Once the analysis is done, the concerned team(s)
is/are reached out accordingly. This also may not be fruitful at times, because if the data is complex
and huge, we may not get adequate support from the team owning the data. Hence the discussion
should ideally start with the business, at least a Sprint early or as per the applicable SLA to get the data
at the appropriate time.
Also, if possible, members (from business) who are responsible for the data should be included as part
of the Scrum team for Sprint where their support is required. This way they get more clarity on the
exact data required and the team can gauge/refine their progress.
Moreover, agile being an iterative model, there might be similar user stories in different sprints where
the test data created in earlier sprints can either be directly reused or used with minor modifications in
order to avoid redundant data requests/set up and reduced turnaround time for the test data creation and
manipulation.
5. Impact Analysis in Agile

In the traditional practice, Team used to go through the Business requirements and develop the test
scenarios in isolation. They participate in design reviews only when it was completed by development
teams. Hence contributions from the testing teams in those reviews were minimal. However, in Agile,
there is a more significant role of the testing team in impact analysis and design reviews as they are
involved in the design discussions happening for a story. This helps the developer in the impact
analysis and debugging of the issues. Many times, testing team members go to the code level to
analyze or debug the issue along with the developer. In agile, because of the short timeframe, it is the
responsibility of the entire team to ensure that things are developed correctly from day one and thus
contribute to successful delivery.

Testing Practices in Agile:

1. Types of Testing:
 Unit Testing
 Integration Testing
 Smoke Testing
 System Testing
 Regression Testing
 Performance Testing
 Exploratory Testing
 Client/User Acceptance Testing
2. Defect Management in Agile:
There is a myth that defect management is not needed in Agile. However, it is important to understand
how does it work when there is a bug that needs more effort and could not be fixed in the stipulated
time of a sprint. In such cases, defect management is needed in agile projects too. Whenever the stories
are available to test, the testing team starts testing and finds bugs. The usual practice is, if the bug or
the issue can be fixed in a day, defects are not raised, and the development team is communicated to
work on the issue. If the issue which is found is not fixed in a day, then a defect is raised to make the
team and the relevant stakeholders aware of the issue. This has to be tracked formally in a defect
management tool. The critical defects are discussed with the team along with the Product Owner who
finalizes the criticality of the defect and the criticality of the story under which the defect has been
logged.
Following is the depiction of how Defect management is done in Agile:

WHAT IS TEST DRIVEN DEVELOPMENT (TDD)?

Test Driven Development (TDD) is a software development methodology that emphasizes
writing tests before writing the actual code. It ensures that code is always tested and functional,
reducing bugs and improving code quality. In TDD, developers write small, focused tests that define
the desired functionality, then write the minimum code necessary to pass these tests, and finally,
refactor the code to improve structure and performance.
This cyclic process helps in creating reliable, maintainable, and efficient software. By following
TDD, teams can enhance code reliability, accelerate development cycles, and maintain high
standards of software quality

Table of Content
 What is Test Driven Development (TDD)?
 Process of Test Driven Development (TDD)
 History of Test Driven Development (TDD)?
 Advantages of Test Driven Development (TDD)
 Disadvantages of Test Driven Development (TDD)
 Test-driven work in Test Driven Development (TDD)
 TDD Vs. Traditional Testing
 Approaches of Test Driven Development (TDD)
 Conclusion
 Frequently Asked Questions on Test Driven Development (TDD)
What is Test Driven Development (TDD)?
Test-driven development (TDD) is a method of coding in which you first write a test and it fails, then
write the code to pass the test of development, and clean up the code. This process recycled for one
new feature or change. In other methods in which you write either all the code or all the tests first,
TDD will combine and write tests and code together into one.
Test-Driven Development (TDD) is a method in software development where the focus is on writing
tests before writing the actual code for a feature. This approach uses short development cycles that
repeat to ensure quality and correctness.
Process of Test Driven Development (TDD)
It is the process in which test cases are written before the code that validates those cases. It depends
on the repetition of a concise development cycle. Test-driven Development is a technique in which
automated Unit tests are used to drive the design and free decoupling of dependencies.
The following sequence of steps is generally followed:

Test Driven Development (TDD)

 Run all the test cases and make sure that the new test case fails.
 Red – Create a test case and make it fail, Run the test cases
 Green – Make the test case pass by any means.
 Refactor – Change the code to remove duplicate/redundancy.Refactor code – This is done to
remove duplication of code.
 Repeat the above-mentioned steps again and again
Write a complete test case describing the function. To make the test cases the developer must
understand the features and requirements using user stories and use cases.
History of Test Driven Development (TDD)?
TDD shares similarities with test-first programming from extreme programming, which started in
1999. However, TDD has gained more widespread interest on its own. Programmers also use TDD to
improve and fix old code written with different methods.
The idea of Test-Driven Development (TDD) which invented from an old book on programming. In
this suggested method you will manually enter the expected output and then write a code until the
actual output when matches it. After creating the first xUnit framework, We will remember this and
give it a try which is related to the the invention of the TDD for me.
Advantages of Test Driven Development (TDD)
 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.
Disadvantages of Test Driven Development (TDD)
 Increased Code Volume: Using TDD means writing extra code for tests cases , which can
make the overall codebase larger and more Unstructured.
 False Security from Tests: Passing tests will make the developers think the code is safer
only for assuming purpose.
 Maintenance Overheads: Keeping a lot of tests up-to-date can be difficult to maintain the
information and its also time-consuming process.
 Time-Consuming Test Processes: Writing and maintaining the tests can take a long time.
 Testing Environment Set-Up: TDD needs to be a proper testing environment in which it
will make effort to set up and maintain the codes and data.
Test-driven work in Test Driven Development (TDD)
TDD, or Test-Driven Development, is not just for software only. It is also used to create product and
service teams as test-driven work. To make testing successful, it needs to be created at both small
and big levels in test-driven development.
This means testing every part of the work, like methods in a class, input data values, log messages,
and error codes. Other side of software, teams use quality control (QC) will check before starting
work. These will be checks to help plan and check the outcomes of the tests. They follow a similar
process to TDD, with some small changes which are as follows:
1. “Add a check” instead of “Add a test”
2. “Run all checks” instead of “Run all tests”
3. “Do the work” instead of “Write some code”
4. “Run all checks” instead of “Run tests”
5. “Clean up the work” instead of “Refactor code”
6. Repeat these steps
TDD Vs. Traditional Testing
 Approach: Test Driven Development (TDD) it is a way of making software in that tests are
written first after that the code is written. In traditional testing it the other way, It will making the
code first and then start testing in it.
 Testing Scope: TDD checks small parts of code one by one. Traditional testing checks the
whole system, including how different parts work together.
 Iterative: TDD is works in small small steps. It will write a small code and tests, and then
improve regularly to code until it passes all the tests which are required. Traditional testing tests
the code one time and then fixing any problems which ate been find.
 Debugging: TDD will try to find mistakes early in the process of code, which makes it will
easier to fix them. Traditional testing will find the mistakes for after, which can be when held
then it will harder to fix in the future.
 Documentation: TDD will focuses on documentation of the tests and their results.
Traditional testing might have been more clear information about how the testing made done and
the system will tested.
Approaches of Test Driven Development (TDD)
There are two main approaches to Test-Driven Development (TDD): Inside Out and Outside In.

Inside Out

 Also known as the Detroit School of TDD or Classicist.

 Focuses on testing the smallest units first and building up from there.
 The architecture of the software emerges naturally as tests are written.
 Easier to learn for beginners.
 Minimizes the use of mocks.
 Helps prevent over-engineering.
 Design and architecture are refined during the refactor stage, which can sometimes lead to
significant changes.

Outside In

 Also known as the London School of TDD or Mockist.

 Focuses on testing user behavior and interactions.
 Testing starts at the outermost level, such as the user interface, and works inward to the
details.
 Relies heavily on mocks and stubs to simulate external dependencies.
 Harder to learn but ensures the code meets overall business needs.
 Design is considered during the red stage, aligning tests with business requirements from the
start.

WHAT IS USER ACCEPTANCE TESTING?

UAT, or user acceptance testing, is the final stage in the software testing process. It is typically
performed by the end-users or client to determine whether an application or feature fulfills its purpose.
UAT must be completed before the software can be released to the market.In the Waterfall
methodology, UAT is typically the final phase in the g However, in Agile software teams, user
acceptance testing is done for each iteration of working software.

How to perform UAT in Agile:

There are 6 steps in testing:

. Analyze the business requirements: It’s important to understand the business and functional
requirements of your software. For example, if a business requirement is for customers to have
multiple payment methods, the functional requirement is to set up various payment gateways.
Analyzing these requirements will show you what needs to be tested.

. Create a UAT plan: The UAT plan outlines the strategy for UAT testing in Agile. It
documents the entry and exit criteria, test scenarios/cases, and timelines of the testing.

. Identify test scenarios and test cases: Test scenarios are the hypothetical situations your users
may encounter as they interact with your software and are written to guide testers through
possible problems. A test case, meanwhile, is a set of specific actions taken to test a particular
feature or functionality. Both test scenarios and test cases are created from your analysis of the
business requirements.

. Select your testing team: Testers can be recruited from your existing user base and often
include real-world users, subject matter experts, stakeholders, the product owner, or the
customer. The test scenarios and test cases must be clearly defined for the testers.

. Run tests and record the results: The testers run the test scenarios and test cases. Bugs are
logged and re-tested once fixed. Data from user reports can provide more insight into the test
cases performed.

. Sign off: Once the team has addressed the issues revealed by the UAT, the testing team
indicates acceptance of the software. This means that the product meets user requirements and
is ready for release.

UAT BEST PRACTICES IN AGILE:

 Plan Agile user acceptance testing in advance. Usually, UAT is conducted prior to launch
when teams are already under pressure to meet deadlines. Planning for UAT will ensure that
you do not miss any important test cases.

 Know your target audience. Who will be using your software? What are their needs? What
problems could your software solve? Attempting to answer these questions will save you from
wasting time on features that don’t work.

 Be specific. Your test cases should be as detailed as possible to guide testers during the UAT in
Agile process. Create a step-by-step plan that shows them which buttons to click, what results
to expect, etc.

 Have well-defined acceptance criteria. You must determine the metrics for success before
carrying out UAT testing in Agile. Your acceptance criteria must be measurable, simple, and
account for the user’s perspective.
Incorporating UAT into your Agile workflow ensures that your product meets the needs of your end-
users, saving any potential time, money, and effort spent addressing problems after the launch.

UNIT V
AGILE REVIEW AND SCALING AGILE FOR LARGE PROJECTS

AGILE METRICS AND MEASUREMENTS

Agile metrics are the main useful part of Agile philosophy which is used to measure the team's
productivity. By using the Agile metrics team managers and the members can see the consequences
of their work and use these data to maintain and improve their workflow to further increase their
efficiency. Therefore, in this article, a complete overview has been provided about the Agile metrics
and the top 10 Agile metrics.

Understanding Agile Metrics

Agile metrics are used in Agile development to help the teams of Agile development in their
development process by maintaining the work quality, gauging productivity, predictability, and
health of the team and products being developed. The main purpose of agile metrics is to value to
customers. There are mainly three important types of agile metrics which are mentioned below:
1. Scrum metrics: Scrum metrics mainly focus on the predictable delivery of working software
to clients or customers. The common metrics include the team velocity and burndown charts.
2. Kanban metrics: The Kanban metrics mainly focus on the workflow, organizing and
prioritizing the work, and getting it done. Cumulative flow is a common metric.
3. Lean metrics: The lean metrics are mainly focused on making sure a flow of value from the
organization to its customers and also removing wasteful activities. Lead time and cycle time are
the common metrics.
Top 10 Agile Metrics
Multiple agile metrics are used for delivering working software to the customer. Therefore some of
the most important Agile metrics are mentioned below:

1. Sprint Burndown

Sprint burndown is one of the agile metrics that is applied both in the long-term and short-term- the
team managers can develop the sprint burndown scrum reports in real-time to track the team's
progress in the present project - for this they particularly need to estimate the total number of sprints
and predict the likely time expenses. Sprint burndown can be used for long terms- the managers can
analyze reports on past projects, pinpoint stages that have failed the expected timeframes, and
analyze the causes of delays. It also allows tracking the dynamics of the team's workflow.
2. Agile Velocity

Velocity is one of the important agile metrics that is used on projects. Agile velocity is used to
measure the number of story points completed by a team on average over the past few sprints.
Therefore agile velocity can be used to predict the team's output in the upcoming sprints. Velocity is
known to be a powerful metric as it is a result metric to know how much value was delivered to the
customers in a series of sprints.

3. Lead Time

Lead time is a type of agile metric that allows the teams to check how much it took for the product
backlog entry to arrive at the end of the sprint. Lead time can be used to track the products at any
developmental stage task by task or to assess the overall time expenses. Lead time metric can be used
by the developers to use this metric while planning for their future work and also to estimate the
prices. For every project be sure to record lead time. By using lead time developers can also examine
separately every stage.

4. Cycle Time

Cycle time is a type of agile metric that is used to focus on individual tasks and this metric is mainly
used to evaluate the duration of a single cycle where one of the cycles is taken by one task which
further calculates the number of cycles per project. This metric is also used to measure the
accomplished results for the end-user if the product is already beta-tested. With the help of cycle
time team members can immediately see if one task takes too much time or if some team members
aren’t delivering on their ends.

5. Code Coverage

Code coverage is another agile metric that is used to measure the percentage of the code that is
covered by the unit tests and can be measured by the number of method statements, conditions, or
branches that are further executed as a part of the unit test suite. Code coverage is used to run
automatically as part of every build and gives a crude picture showing how much of the codebase has
been tested.

6. Static Code Analysis

Static code analysis is an automated process and not exactly a metric that can provide insights into
the code quality and clean the code from simple errors and redundancies. It is used to provide a safe
baseline for the code quality and it consists of no substitutes for the human input into the code
quality therefore manual code reviews, other methods, and pair programming.

7. Release Net Promoter Score

Net promoter scores are mainly calculated for the release of software which further measures
whether the users would recommend the software to others. Therefore it is one of the important
gauges of customer satisfaction which involves evaluating the user's reactions to quantitative and
qualitative feedback. After the team analyzed and collected the feedback each of the team members
suggested a score that evaluates how much the users are likely to recommend the product.

8. Cumulative Flow
Cumulative flow has a main purpose to accumulate all the project flows and evaluate them in a single
diagram. Having such type of graph can provide individuals with a big-scale view which can be
further sent to the project stakeholders who didn’t have much time to analyze the more
comprehensive reports. Therefore cumulative flow can visualize the bottlenecks in the process.

9. Failed Deployments

Whenever the project is being deployed but fails to attract the users this is recorded as a failed
deployment. Therefore sometimes a failed deployment happens to the decisions of one of the
stakeholders or the business model which proves to be unreliable. Thus whatever may be the problem
the individual needs to record all the failed deployments along with the reasons for their failure.
Hence before releasing a new deployment, the team can always have a look at the previously failed
deployments and examine if one cannot undergo a similar process. Analyzing the previous issues
prevents further issues.

10. Escaped Defects

Every agile project consists of a work cycle or sprint at the end of which a specific task is being
delivered. When the work is completed the team manager has to assess the quality of turned-in
results. Therefore all the changes, unfixed bugs, and edits are escaped defects. These are the issues
that developers could have fixed but didn’t. To know the mistakes record their precise number and
nature. After reporting on the escaped defects and the collected tangible statistics the individuals
need to discuss the results with the team and make sure that every team member knows about the
errors the team misses.
Implementing Agile Metrics Effectively
To implement agile metrics effectively in businesses individuals need to know how to measure
success. These agile metrics help the individuals and the team members to keep a realistic and data-
based overview of the progress so that it can be made sure that it consists of higher productivity,
better quality, and also improves satisfaction.
Conclusion
Agile metrics are used to help the team members and the project managers direct the teams toward
continuous improvement based on real-life data from past work cycles. Therefore in this article,
detailed knowledge has been provided about the agile metrics and the top 10 agile metrics that are
used to maintain the productivity of the workflow.
THE AGILE APPROACH TO ESTIMATING AND PROJECT VARIABLES:

ESTIMATION TECHNIQUE IN AGILE:

Estimation is the process of finding an estimate, or approximation. It is an Art of guessing. Estimation
includes four main factors – money, effort, resources, and time needed to build a specific system or
product. There are many techniques available in today’s world for doing estimations in
an Agile Project. The main objectives for doing estimations include Relative Estimation, discussions to
get more information on items whose estimations need to be done and ensuring the commitment and
enthusiasm of the whole team towards the tasks assigned to them. Agile Project Estimation
Techniques are:
1. Dot Voting: In Dot Voting Techniques all the user stories along with their description are
posted on the board. Each member put a dot in front of those stories that they consider most
important. This way the stories are sorted according to their priorities. This is done to select the
most important stories that should be taken forward.
2. T-Shirt Size: This technique helps in open and mutual collaborative discussions. In this
technique, t-shirt sizes -XS (Extra Small), S (Small), M (Medium), L (Large), and XL (Extra Large)
 are used. User stories are given t-shirt sizes according to the member’s understanding. This
technique provides rough estimation very fast.
3. Planning Poker: Planning Poker is the most famous Estimation technique in Agile. This
technique makes sure that every member participates in the estimation and shares his/her opinion.
In this technique cards with numbers on them, are given to each member of the team. The Product
Owner reads the story, after which every member has to hold the card showing the level of effort
they will make for the user story. Discussion and Re-estimation go on until the whole team reaches
a consensus.
4. The Bucket System: The Bucket System estimation technique is much faster than the Planning
Poker technique. In this buckets are created with random values: 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50.
The whole team estimates the items by placing them in these “buckets”. In the Bucket System
Divide and Conquer approach is followed.
5. Large/Uncertain/Small: This technique is for doing rough estimation and it is simpler than the
Bucket system technique. All the items are categorized in Large/Uncertain/Small. First simple user
stories are chosen for estimation then more complex ones are taken. It’s a good technique when
comparable items are in the Product Backlog.
6. Relative Estimation: In this technique, teams estimate user stories according to one another
rather than giving them exact numerical values. For instance, they can state, without assigning
specific point values, that Story X is twice as complex as Story Y. This method prioritizes selection
and ranking while simplifying estimation.
7. Story Points: In this estimation technique, user stories are given story points based on
complexities, effort, and risk by teams. Story points are a metric without units and can stand in for
any comparable value decided by the team. This method is adaptable and frequently used alongside
Planning Poker.
8. Estimation Based on Velocity: This technique states the amount of work a team can
accomplish in a sprint is measured by the team’s velocity. Teams calculate the amount of user story
points that can commit to in the following sprint using their average velocity over several sprints.

Conclusion

The choice of the estimation technique depends on the context of the project and the amount of detail
required for it. The teams can use more than one technique at the same time to look for different
aspects of the work together.
AGILE MEASUREMENT:
How to Measure Agile Team Performance
Agile teams thrive on driving results, but it’s important to know exactly how to measure Agile team
performance. With a lot of Agile KPI metrics to choose from, finding the metrics that matter for your
team is easier said than done. As Eric Ries, author of The Lean StartUp reminds us, it’s important not
to target ‘vanity metrics.’ That is to say, performance metrics that make an Agile team look great but,
in practical terms, don’t mean a whole lot.

So, how do we figure out how to measure Agile team performance? Agile experts recommend hyper-
focusing on just four metrics, detailed below:

. Predictability (measured by the Planned-to-Done ratio)

. Productivity (measured by cycle length)

 . Quality (measured by the Escaped Defect Rate)

. Stability (measured by happiness metric)

How to measure team performance in Agile: Predictability

By using predictability as a metric, your Agile teams will be able to calculate what the likelihood of
delivery will be. For example, if they commit to 100 backlog items over a quarter and deliver 90, their
planned-to-done rate would be 90%.
It’s worth budgeting resources for any likely additional deliverables that may need to be taken on
during the given period or ensuring those that weren’t previously planned are counted to get more
accurate results. This metric can be used to create more accurate OKRs, improve planning, and better
balance resources for your Agile teams.

How to measure Agile team performance: Productivity

Arguably one of the most important metrics, productivity is measured by cycle time — that is, how
many items your Agile teams can deliver in a given period of time. This should ideally be measured
with an Agile project dashboard.
On a very simple level, you can measure productivity by using dashboards to track the amount of work
completed in a sprint or cycle from when the work started to when it finished. The shorter the cycle
time, the more things are getting done.

How to measure team performance in Agile: Quality

Quality, on the other hand, is measured by Escaped Defect Rate, which tracks the overall quality of the
deliverables your team is working on. It connects customer satisfaction to the team working on the
customer product or software. The lower the defect rate, the more likely the customer will be satisfied
with the product.
Therefore, we measure Escaped Defect Rate by tracking the number of problems (these can be bugs or
defects) found in a product once it has been released. These defects are only those that are recorded
post-release.

How to measure Agile team performance: Stability

This metric measures how stable your team is (and consequently what their output is). This is known as
the ‘human factor’ and essentially reminds us that if the three other metrics are absolutely perfect, the
team is likely burnt out or about to be. This can be assessed in the form of a survey with a ranking of
the team’s choosing. The happiness metric can be used to reassess timings, resource allocation, and
processes. It can also be used to improve team collaboration. Getting this metric right is critical for
hardworking Agile teams.

AGILE CONTROL: THE 7 CONTROL PARAMETERS

Here are seven parameters that you can use to measure the effectiveness of your agile initiatives.

1. On-Time Delivery
Fifty-eight percent of the respondents believed that on-time delivery was the most significant measure
of success in agile practices. In this case, on-time delivery means that a particular item required by the
business arrived on the expected date. It also had the proposed features. In other words, all parties
adhered to every condition in the contract as initially written.
2. The Quality of the Product
Forty-eight percent of the respondents mentioned quality as the primary measure of success when it
came to agile initiatives. To put it differently, the condition of the software is their chief concern. For
example, is it useable? Is it secure? Is it reliable? Achieving high standards of excellence in the
production of software is only possible if it undergoes constant testing and monitoring.

3. The Level of Customer Satisfaction

More than 44% of the respondents stated that they measured the success of agile processes by
examining the level of customer satisfaction. They would analyze it by referring to the volume of calls
made by users to the company’s support team. They would look at sales figures as well in addition to
the rate at which people are using the product.

4. Business Value
Forty-four percent of the respondents claimed that they assessed agile methodologies based on the
worth that they brought into the business. They measured this worth through well-defined analytical
techniques including Statement of Work (SoW). They also estimated it by linking each feature the
product has to a specific value that it brings into the business.

5. The Scope of Features and Requirements

Thirty-nine of the respondents stated that they analyzed agile initiatives based on the scope of the
product. More specifically, they looked at the features of the software and its requirements. Fortunately,
the collection of this metric is a straightforward process. The parties involved can do it in agile standup
meetings while representing it through burn-down charts or Kanban boards.

6. The Visibility of the Project

Project visibility is the most significant measure of agile initiatives for 30% of the respondents in this
survey. Achieving a high level of it is possible if the parties involved share the product across multiple
platforms. They have to do it in diverse ways so that everyone can play a role towards the success of
the project.

7. The Level of Productivity and Predictability

Twenty-nine percent of the respondents stated that they measured agile processes by examining their
level of productivity. Burn-up charts are an excellent way of collecting data for this metric.
Determining predictability is also possible by reviewing the product's velocity trends. For example,
fluctuating levels of velocity is an indication of unpredictability.

Conclusion
The Ninth Annual State of Agile Survey gives professionals profound insights into agile trends across
the country and the globe. More importantly, it increases your awareness of agile metrics including the
seven parameters mentioned above. These metrics help you measure the impact of agile initiatives on
your business so that you can modify them appropriately if necessary.

AGILE APPROACH TO RISK

What is Agile Risk Identification?
Project experts use Agile Risk Identification to examine project elements such as technical
dependencies, system integrations, data security, etc. Project Experts analyze these elements and
various issues to make the workflow fool-proof. It includes the identification of risks in all aspects
such as project documentation, requirements, and stakeholder expectations.
In part 1 of Agile Risk Identification, we identify and analyze the risks and document them to take
action. But the second part includes all the executable tasks described in the first part. Let us see all
these parts in a detailed way.
Risk Assessment and Prioritization
Agile Methodology is an iterative and dynamic approach to managing the project. It focuses on the
incremental development in which the project is managed in small increments. However, in these
short cycles of development, the team has specific tasks and roles that are assigned as per their skill.
Along with the Project Tasks, it is also important to focus on the current and present issues that may
become a risk for your fine. Therefore, Risk Identification and Assessment play an important role in
it. Let us explore the tools using which we can assess the risks.

Risk Assessment Tools

Many are the tools that help the project professionals to evaluate the risks. The following are the
commonly used tools for assessing the risks.
 Risk Matrix: It captures the various risks in terms of their likelihood and impact so that their
severity can be known. It allows us to see what risks need to be addressed on priority.
 Risk Heat Maps: They use the color-coded scale to highlight the risk severity. It is similar to
the Risk Matrix. However, the difference is that the Risk Matrix uses a numerical scale and a
gradient color scale.

Prioritization Frameworks

Prioritizing the tasks is also important as it helps us to find what risk needs to be addressed first. This
is also important for allocating the time and resources to the most important activities on priority.
You can use the following methods to prioritize the risks.
 The Risk Urgency Model focuses on highlighting the time-sensitive issues that are marked as
high, medium, or low. Thus, we can easily calculate the severity of the issues.
 The MoSCow Method also prioritizes tasks like the Risk Urgencey Model with the difference
that it shows the four categories of risk namely "Must have," "Should have," "Could have," and
"Won't have.”
Agile Risk Mitigation Techniques
Agile Risk mitigation allows us to manage project elements such as technical dependencies, system
integrations, data security, etc for resolving the risks. It includes the identification and mitigation of
risks in all aspects such as project documentation, requirements, and stakeholder expectations. In
more simple words, we can say that it includes all the executable tasks described in the first part. Let
us see all these parts in a detailed way.
After we perform different activities such as Documentation review, requirement gathering,
Brainstorming, Assumption analysis, and Checklist analysis, we have to implement more advanced
strategies to perform risk mitigation plans. These techniques are discussed below.

Risk Analysis

Risk Analysis is the set of sequential tasks to analyze the risks. It includes identifying the risks and
assessing them to find their impact value. After this, they are prioritized so that we can manage the
critical risks easily. Implementation of these steps allows the Agile Teams to get a comprehensive
understanding of the various risks associated with the Project.
It is an important part of Agile Risk Identification so that we can allocate the resources to the various
tasks with efficiency. Also, knowing about the probability and likelihood of occurrence helps us to
deal with the Risk better.

Risk Planning

Only identifying the risks but with inefficient planning can become the cause of a severe project
failure or breakdown. This component involves creating a strategy to address the identified tasks.
The different strategies include risk avoidance, risk transfer, risk mitigation, and acceptance plans.
Also, other advanced strategies such as Automated Risk Monitoring, Quantitative Risk Assessment,
and Integration with other Agile Tools are These plans are documented and communicated with
team members with transparency.
It also involves the Mitigation and Risk Response or other fallback plans to recover from the failure.
The general term for this is Contingency Plan which helps us to recover from the impact of
unpredictable or uncertain risks. We also have to develop the establishing early warning systems so
as not to let the risk affect the project. In this way, the likelihood of the issues and tasks can be easily
determined.

Monitoring and Control

The tracking is important to know the working status or progress of the various risk response plans.
Thus, Monitoring and Control Plans enable the users to evaluate and monitor the working of the
strategies that we implemented. It includes Real-time risk monitoring so that their outcomes align
with the business value.
Along with this, it also has the tracking of the metrics such as Key Performance Indicators to know
how well the risk mitigation plans fit with the nature of the various project risks. The last step is to
document the key learnings of the monitoring analysis. This performance result is shared with the
stakeholders to take follow-ups on the risks.
Implementing Mitigation Strategies
After getting insights into risk mitigation, we can easily move on to the next part which is the
implementation of the Risk Mitigation strategies:

Embedding Risk Management in the Agile Cycle

Agile Methodology mainly focuses on the iterative process. Thus, identifying and managing the risks
in Agile is also meant to be done in increments. This helps to analyze the risks quickly. So in this
process, sprint planning is done, and risk discussions are scheduled.
Sprint Planning is the core part of the Agile Project which deals with communication with the
Product Owner, Scrum Master, and Development Team. It also involves discussions with the key
stakeholders about risk identification. This enables the team to prepare for risk before the sprint
starts.

Leveraging Collaborative Tools

Project Professionals can use the Agile Boards to visually track and manage risks throughout the
project lifecycle. These boards are updated regularly to ensure visibility and transparency in the
project process. Along with this, workspace tools such as Slack and GitHub can also integrated into
the Agile Cycle to identify the risk during the execution itself.
Building a Risk-Aware Culture

Risk Mitigation is all about building a team-work-based environment and fixing the issues through a
collaborative approach. Hence, project professionals conduct training sessions and workshops to
improve the work culture of the team in terms of risk identification and mitigation. Therefore, a
shared understanding can help us to avoid the issues and risks in our project.
Conclusion
Taking up the Agile Project is easy but knowing what can become a potential risk for the project is
equally important. Agile Risk Identification Part 2 is important for dealing with the risks in our Agile
Project. With accurate planning, analysis, and monitoring of the result, we can easily implement
advanced strategies for avoiding the risks in our project. You have now gained a sufficient
understanding of the second part of the Agile Risk Identification. Go ahead and take advantage by
identifying the project risks using advanced strategies.
THE AGILE APPROACH TO CONFIGURATION MANAGEMENT

System configuration management:

Whenever software is built, there is always scope for improvement and those improvements bring
picture changes. Changes may be required to modify or update any existing solution or to create a new
solution for a problem. Requirements keep on changing daily so we need to keep on upgrading our
systems based on the current requirements and needs to meet desired outputs. Changes should be
analyzed before they are made to the existing system, recorded before they are implemented, reported
to have details of before and after, and controlled in a manner that will improve quality and reduce
error. This is where the need for System Configuration Management comes. System Configuration
Management (SCM) is an arrangement of exercises that controls change by recognizing the items for
change, setting up connections between those things, making/characterizing instruments for overseeing
diverse variants, controlling the changes being executed in the current framework, inspecting and
revealing/reporting on the changes made. It is essential to control the changes because if the changes
are not checked legitimately then they may wind up undermining a well-run programming. In this way,
SCM is a fundamental piece of all project management activities.
Processes involved in SCM – Configuration management provides a disciplined environment for
smooth control of work products. It involves the following activities:
1. Identification and Establishment – Identifying the configuration items from products that
compose baselines at given points in time (a baseline is a set of mutually consistent Configuration
Items, which has been formally reviewed and agreed upon, and serves as the basis of further
development). Establishing relationships among items, creating a mechanism to manage multiple
levels of control and procedure for the change management system.
2. Version control – Creating versions/specifications of the existing product to build
newproducts with the help of the SCM system. A description of the version is given
3. Suppose after some changes, the version of the configuration object changes from 1.0 to 1.1.
Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed by a major
update that is object 1.2. The development of object 1.0 continues through 1.3 and 1.4, but finally,
a noteworthy change to the object results in a new evolutionary path, version 2.0. Both versions are
currently supported.
4. Change control – Controlling changes to Configuration items (CI). The change control process
is explained in Figure below:

5. Change request : A change request (CR) is submitted and evaluated to assess technical merit,
potential side effects, the overall impact on other configuration objects and system functions, and
the projected cost of the change. The results of the evaluation are presented as a change report,
which is used by a change control board (CCB) —a person or group who makes a final decision on
the status and priority of the change. An engineering change Request (ECR) is generated for each
approved change. Also, CCB notifies the developer in case the change is rejected with proper
reason. The ECR describes the change to be made, the constraints that must be respected, and the
criteria for review and audit. The object to be changed is “checked out” of the project database, the
change is made, and then the object is tested again. The object is then “checked in” to the database
and appropriate version control mechanisms are used to create the next version of the software.

6. Conf
iguration auditing – A software configuration audit complements the formal technical review of
the process and product. It focuses on the technical correctness of the configuration object that has
been modified. The audit confirms the completeness, correctness, and consistency of items in the
SCM system and tracks action items from the audit to closure.
7. Reporting – Providing accurate status and current configuration data to developers, testers, end
users, customers, and stakeholders through admin guides, user guides, FAQs, Release notes,
Memos, Installation Guide, Configuration guides, etc.
System Configuration Management (SCM) is a software engineering practice that focuses on managing
the configuration of software systems and ensuring that software components are properly controlled,
tracked, and stored. It is a critical aspect of software development, as it helps to ensure that changes
made to a software system are properly coordinated and that the system is always in a known and
stable state.
SCM involves a set of processes and tools that help to manage the different components of a software
system, including source code, documentation, and other assets. It enables teams to track changes made
to the software system, identify when and why changes were made, and manage the integration of these
changes into the final product.
Importance of Software Configuration Management
1. Effective Bug Tracking: Linking code modifications to issues that have been reported, makes
bug tracking more effective.
2. Continuous Deployment and Integration: SCM combines with continuous processes to
automate deployment and testing, resulting in more dependable and timely software delivery.
3. Risk management: SCM lowers the chance of introducing critical flaws by assisting in the early
detection and correction of problems.
4. Support for Big Projects: Source Code Control (SCM) offers an orderly method to handle code
modifications for big projects, fostering a well-organized development process.
5. Reproducibility: By recording precise versions of code, libraries, and dependencies, source
code versioning (SCM) makes builds repeatable.
6. Parallel Development: SCM facilitates parallel development by enabling several developers to
collaborate on various branches at once.
Why need for System configuration management?
1. Replicability: Software version control (SCM) makes ensures that a software system can be
replicated at any stage of its development. This is necessary for testing, debugging, and upholding
consistent environments in production, testing, and development.
2. Identification of Configuration: Source code, documentation, and executable files are examples
of configuration elements that SCM helps in locating and labeling. The management of a system’s
constituent parts and their interactions depend on this identification.
3. Effective Process of Development: By automating monotonous processes like managing
dependencies, merging changes, and resolving disputes, SCM simplifies the development process.
Error risk is decreased and efficiency is increased because of this automation.
Key objectives of SCM
1. Control the evolution of software systems: SCM helps to ensure that changes to a software
system are properly planned, tested, and integrated into the final product.
2. Enable collaboration and coordination: SCM helps teams to collaborate and coordinate their
work, ensuring that changes are properly integrated and that everyone is working from the same
version of the software system.
3. Provide version control: SCM provides version control for software systems, enabling teams
to manage and track different versions of the system and to revert to earlier versions if necessary.
4. Facilitate replication and distribution: SCM helps to ensure that software systems can be
easily replicated and distributed to other environments, such as test, production, and customer sites.
5. SCM is a critical component of software development, and effective SCM practices can help to
improve the quality and reliability of software systems, as well as increase efficiency and reduce
the risk of errors.
The main advantages of SCM
1. Improved productivity and efficiency by reducing the time and effort required to manage
software changes.
2. Reduced risk of errors and defects by ensuring that all changes were properly tested and
validated.
3. Increased collaboration and communication among team members by providing a central
repository for software artifacts.
4. Improved quality and stability of software systems by ensuring that all changes are properly
controlled and managed.
The main disadvantages of SCM
1. Increased complexity and overhead, particularly in large software systems.
2. Difficulty in managing dependencies and ensuring that all changes are properly integrated.
3. Potential for conflicts and delays, particularly in large development teams with multiple
contributors.

THE ATERN PRINCIPLES:

The Atern Principles, core to the DSDM (Dynamic Systems Development Method) agile
framework, guide project delivery by emphasizing business needs, on-time delivery, collaboration,
quality, incremental development, iterative processes, continuous communication, and demonstrating
control.

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development technique (DSDM) is an associate degree agile code
development approach that provides a framework for building and maintaining systems. The DSDM
philosophy is borrowed from a modified version of the sociologist principle—80 % of An application
is often delivered in twenty percent of the time it’d desire deliver the entire (100 percent) application.
DSDM is An iterative code method within which every iteration follows the 80% rule that simply
enough work is needed for every increment to facilitate movement to the following increment. The
remaining detail is often completed later once a lot of business necessities are noted or changes are
requested and accommodated.
The DSDM tool (www.dsdm.org) could be a worldwide cluster of member companies that put together
tackle the role of “keeper” of the strategy. The pool has outlined AN Agile Development Model,
known as the DSDM life cycle that defines 3 different unvarying cycles, preceded by 2 further life
cycle activities:
1. Feasibility Study:
It establishes the essential business necessities and constraints related to the applying to be
designed then assesses whether or not the application could be a viable candidate for the DSDM
method.
2. Business Study:
It establishes the use and knowledge necessities that may permit the applying to supply business
value; additionally, it is the essential application design and identifies the maintainability
necessities for the applying.
3. Functional Model Iteration:
It produces a collection of progressive prototypes that demonstrate practicality for the client.
(Note: All DSDM prototypes are supposed to evolve into the deliverable application.) The intent
throughout this unvarying cycle is to collect further necessities by eliciting feedback from users as
they exercise the paradigm.
4. Design and Build Iteration:
It revisits prototypes designed throughout useful model iteration to make sure that everyone has
been designed during a manner that may alter it to supply operational business price for finish users.
In some cases, useful model iteration and style and build iteration occur at the same time.
5. Implementation:
It places the newest code increment (an “operationalized” prototype) into the operational
surroundings. It ought to be noted that:
 (a) the increment might not 100% complete or,
 (b) changes are also requested because the increment is placed into place. In either case,
DSDM development work continues by returning to the useful model iteration activity.
Below diagram describe the DSDM life cycle:
DSDM is often combined with XP to supply a mixed approach that defines a solid method model (the
DSDM life cycle) with the barmy and bolt practices (XP) that are needed to create code increments.
additionally, the ASD ideas of collaboration and self-organizing groups are often tailored to a
combined method model.
ATERN PHILOSOPHY:
The Atern philosophy within agile project management, particularly in the context of DSDM (Dynamic
Systems Development Method), emphasizes strategic alignment, early delivery of real business
benefits, and iterative development with continuous feedback and control.
Here's a more detailed breakdown:

 Strategic Alignment: Atern stresses that projects must be aligned with clearly defined strategic
goals and focus on delivering real business benefits early on.
 Iterative Development: Projects are developed incrementally, with work reviewed and
feedback received at the end of each iteration.
 Focus on Business Needs: Atern prioritizes understanding and addressing the underlying
business needs and making decisions with the project goal in mind.
 On-Time Delivery: The framework emphasizes the importance of delivering projects on time,
recognizing it as a critical success factor.
 Collaboration: Atern promotes collaborative teams that work together effectively, recognizing
that collaborative teams outperform those that don't.
 Quality Focus: Atern emphasizes the importance of maintaining quality throughout the project
lifecycle, ensuring the system is good enough.
 Incremental Delivery from Firm Foundations: Atern suggests performing sufficient analysis
and design upfront to build incrementally from a solid foundation.
 Continuous Communication: Atern highlights the importance of continuous and clear
communication to prevent project failures.
  Demonstrated Control: Atern emphasizes proactive management of plans to ensure the
project remains in control at all times.
 Empowered Teams: Atern enables business agility through self-directed, empowered teams
working together in a supportive and collaborative manner.

THE RATIONALE FOR USING ATERN:

The rationale for using Atern, the Agile project delivery framework, in Agile projects is to facilitate
rapid, effective, and business-focused delivery by emphasizing strategic goals, incremental value,
and continuous stakeholder engagement while maintaining control over cost, risk, and quality.

Here's a more detailed explanation:

 Focus on Business Outcomes: Atern prioritizes delivering real business benefits and achieving
strategic goals, rather than solely focusing on technical aspects.
 Incremental Delivery: It promotes the delivery of product in business-valuable increments
throughout the project, allowing for early and continuous feedback.
 Change Management: Atern embraces changing requirements and environments, using
prioritization and timeboxing to manage change effectively within time and budget constraints.
 Stakeholder Engagement: It emphasizes continuous and active user involvement at both
management and team levels, ensuring that the project aligns with business needs.
 Control and Predictability: Atern provides a structured approach to agile project management,
helping to ensure projects remain in control and on track.
 Flexibility: Atern allows the project team to decide how products are built, enabling tailoring
to various environments and requirements.
 Generic Approach: Atern is a generic approach to agile project management, not solely
focused on software delivery, making it applicable to various project types.
 Business Prioritization: Atern helps in understanding the relative priority of requirements,
which helps the team make progress and hit deadlines.
 On-Time, On-Budget Delivery: Atern aims for on-time, on-budget delivery by promoting
effective planning, prioritization, and time management.
 Well-Documented Method: Atern is a well-documented method, providing guidance and
support for agile project delivery.

REFACTORING IN AGILE
Refactoring is the practice of continuously improving the design of existing code, without changing the
fundamental behavior. In Agile, teams maintain and enhance their code on an incremental basis from
Sprint to Sprint. If code is not refactored in an Agile project, it will result in poor code quality, such as
unhealthy dependencies between classes or packages, improper class responsibility allocation, too
many responsibilities per method or class, duplicate code, and a variety of other types of confusion and
clutter. Refactoring helps to remove this chaos and simplifies the unclear and complex code. Following
are the definitions quoted by various experts in Agile on Refactoring concepts:
It is best to refactor continuously, rather than in phases. Refactoring continuously prevents the code
from getting complicated and helps to keep the code clean and easy to maintain. In Agile development,
there can be short and separate sprints to accommodate refactoring. This module provides an overview
of the technical/engineering practice of Refactoring which would be implemented in Agile projects.

Challenges:

Though refactoring brings a lot of benefits to the code quality of the software, there are multiple
challenges that dissuade developers in Agile projects from continuously refactoring the code.
Following are a few challenges that are mostly seen in Agile projects
 Time Constraint: Time is the biggest challenge for doing refactoring in Agile projects as the
Sprints are time-boxed with a defined set of deliverables.
 Reluctance: If the code is working fine without any refactoring done, there will be an
inclination towards not revisiting the code. This is primarily because of the mindset that there is no
error and hence no need to do additional activities i.e. refactoring.
 Integration with branches: To integrate the code across different branches post refactoring is
considered a challenge
 Fear factor: Developer often fears that refactoring will introduce bugs and break the existing
functionality which is working fine
 Re-Testing: In case automated test suites are not available, the developer is discouraged to do
refactoring with the additional effort of manual testing to check the functionality
 Backward Compatibility: Backward compatibility often prevents developers from starting
refactoring efforts.

Motivation For Refactoring:

The following points for motivation are more common among the developers while they do
refactoring
 It becomes easier to add new code
 The existing code’s design is improved.
 Helps to gain a better understanding of code
 Makes coding less annoying

Advantages of Refactoring:

Refactoring in small steps helps to prevent defects from being introduced. The following points can be
further perceived from the benefits of implementing Refactoring.
 Improves software extendibility
 Reduce the expense of code maintenance.
 Provides standardized code
 Architecture improvement without impacting software behavior
 Provides more readable and modular code
 Modular component refactored to maximize possible reusability

Design Guidelines for Agile Projects:

In a traditional software development project, requirements and plans are set before development
begins, which enables the team to know the road ahead with reasonable confidence that requirements
or design will not change drastically in the middle whereas the Agile method is to enable and embrace
change. On an Agile project, requirements can change at any point in the project cycle. Therefore, it is
imperative for Agile teams to have a code in a position where they can conveniently accept a new
requirement or change.
Good design is an important principle of Agile manifesto projects: “Continuous attention to technical
excellence and good design enhances agility”.

Precautions for Refactoring:

 Too much pattern focus takes away the focus from writing small, simple, and understandable
code.
 Look at patterns from a refactoring perspective and not just as reusable elements.

How to Check Faculty Code?

‘Code Smell’ is the phrase coined by Kent Back and Martin Fowler. Some of the most important
“smells in code” are:

S.No. Smell Description

1. Duplicated code Identical or very similar code exists in more than one location

2. Long Method A method/function/procedure that has grown too large

3. Long Class A class that has grown too large

Too Many A long list of parameters is hard to read and makes calling and testing the
4.
Parameters function complicated

5. Feature envy A class that uses methods of another class excessively

6. Lazy Class A class that does too little

Contrived Forced usage of overly complicated design patterns where the simpler
7.
complexity design would suffice.

8. Complex to debug Code has become complex enough to debug

Guidelines for Refactoring:

 Make sure the code is working before you start.

 Ensure that an automated test suite is available and provides good coverage.
 Run the tests frequently before, during, and after each refactoring.
 Before each refactoring, use a version control tool and save a checkpoint. Not only does this
mean recovery can be done quickly from disasters, but it also means refactoring can be tried out
and then back out if unsatisfied with the refactored code.
 Break each refactoring down into smaller units.
 Finally, if a refactoring tool is available in your environment, utilize it.
Implementation of Refactoring Techniques:
There are multiple refactoring techniques available that will make the existing code better in terms of
performance and maintainability. The basic purpose of refactoring in Agile or any other methodology
is “Leave a module in a better state than you found it”
The Refactoring techniques are categorized by Martin Fowler as follows:
 Composing methods
 Moving features within Objects
 Organizing data
 Simplifying Conditional Expression
 Making method calls simpler
Every category has certain refactoring techniques. Few techniques are explained below.
1. Composing Methods: It deals with the proper packaging of method or function code. Large
methods/functions having very long complex logic implementation can reduce the maintainability and
readability of the code. Applying refactoring techniques like extract methods will help make the code
more maintainable and readable. A few of the refactoring techniques in composing method/function are
detailed below:
 Extract Method
 Inline Method
 Replace method with method object
Extract Method: This is one of the popularly used Refactoring techniques. The implementation
behind this technique is very simple. It consists of breaking up long methods by shifting complex
chunks of code into new methods which have very descriptive identifiers. This method is used when:
 The code consists of long methods covering multiple logical flows that can be broken up into
smaller methods
 If the same code is duplicated in more than one flow, move this to a single method and call
from all other flows
The advantages of this method are:
 Proper code reorganization by grouping a set of statements into the single smaller method
 Reduces code duplication
 Increases the readability of the code
Inline method: In contrast to the Extract Method technique of refactoring, Inline method techniques
suggests replacing a method/function call with the body of the method/function. It is suggested when
the source code of the method/function is very small. This method is used when:
 When a function call causes a performance bottleneck
 When inline code increases the readability of the code since the body of the function is the
same as the function name
 When there are too many delegations in the code
The advantages of this method are:
 Unnecessary complexity reduced, reduction in method calling overhead
 Increases the readability of the code
Replace method with method object: The Thumb rule of good code is that, it should be readable and
easily manageable. At times we might come across a very long method having complicated logic
implementation done inside it with many local variables. Such a method cannot be simplified by
applying the extract method technique because of the usage of too many local variables, because
passing around that many variables would be just as messy as the long method itself. In such cases, a
class can be created for such a method. This class will have all local variables of that long method as its
data members. One of the methods will be the long method. The complicated logic of this method can
easily be simplified by applying the extract methods technique.
2. Moving Features Within Objects:
One of the most important and critical parts of object design is deciding on where to assign the
responsibilities. There are many options. Refactoring techniques can help us decide the same.
Following are a few of the refactoring techniques which can be used to decide the proper responsibility
allocation:

 Move Method: Consider a scenario for performing a functionality. A method is using members
(data or functions) of another class i.e. Class-2 multiple times, as compared to the one in which it is
written i.e. Class-1. Then such a code can be refactored using the Move Method technique.
According to this technique in such cases, that method can be moved to Class-2. Class-1 can call
this method in order to complete the needful functionality and the method can be removed from
Class-1 altogether. Move method technique can also be applied when a method is used a
maximum number of times by one of the classes in which it is declared and defined.

 Move field: If a member of one class is used a maximum number of times by access methods
from some other class, then such field can be moved to another class itself. This needs necessary
modifications in the earlier class which was having that data member in it. Move method
techniques will also be applied when new classes are identified during the development phase.

 Hide delegate: One of the important features of object-oriented design is if changes are made
in one of the classes, then no other classes or very few classes should have an impact on its code
because of this change. If one class is sending its requests to another class then such a class can be
referred to as a client class. The class which serves the sent requests can be referred to as the server
class. Consider a function that has to get an object of class B by calling one of the methods of class
A. This function has to also call a method of class B to get the required data. This means that
function has to interact with class A first and then with class B. In this case, the internal structure of
class B is partially revealed to that function. The same can be avoided if class A has a method that
itself will get the necessary things from class B and send the same to the client function. This
delegation part can be made hidden from the client function. The below diagram shows a pictorial
presentation where the ‘Department’ Class is hidden from ‘Client’, as the call to ‘Department’
Class is moved to the ‘Person’ class method.
3. Organizing Data:
The following section illustrates a few techniques that would make data organization better. This also
makes working with data easier. Replace array with Object: One of the most common data structures
used for data organization is an array. The array is a collection of homogeneous data in contiguous
locations of memory having the same name. Although homogeneous, the same array can contain data
with a different meaning causing confusion while accessing this data structure. In such cases, it is good
to replace the array with an object.
4. Simplifying Conditional Expressions:
Understanding conditional logic implemented in a program can be one of the challenging tasks. Using
refactoring techniques, the conditional logic can be simplified so that the code can be understood easily.
This section has a few refactoring techniques using which conditional logic can be simplified easily.
5. Making method calls simpler:
Objects can interact with each other and the outside world through public methods. These methods
should be easy to understand then the entire object-oriented design will become easy to understand. In
this section, we will discuss a few refactoring techniques which will make the methods calls easier.

Refactoring in Test Driven Development:

Test-Driven Development (TDD) is a software engineering approach that consists of writing failing
test case(s) first covering functionality. And then implementing the necessary code to pass the tests and
finally refactor the code without changing external behavior.
TDD deals with 2 types of tests i.e.
 Unit tests: used to verify the functionality of a single class that is separated from its
environment.
 Acceptance tests: used to check a single functionality
On similar lines, Refactoring can also be categorized into different types.
 Refactoring at local class level: The unit tests for this class are unchanged and the tests are
still green. If the Unit tests are designed to check complete scenarios instead of single-member calls,
the refactoring falls into this category.
 Refactoring impacting multiple classes: In this case, Acceptance tests are the only way to
check complete functionality after refactoring. This is useful if a new way of functionality is
provided, and implemented by changing class after class and associated unit tests. An important
aspect to remember for refactoring in TDD is when code is refactored impacting interface/API, all
the callers of this interface/API along with Tests written for the interface/API need to be changed
as part of refactoring. In congruence with the definition, refactoring is a “behavior-preserving”
change.
CONTINUOUS INTEGRATION
 Continuous Integration Definition: Continuous Integration (CI) is an aspect of the Continuous
Delivery Pipeline in which new functionality is developed, tested, integrated, and validated in
preparation for deployment and release.

 CI is the second aspect in the four-part Continuous Delivery Pipeline of Continuous

Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on
Demand.

 Continuous integration in the context of the continuous delivery pipeline. Details Continuous
integration is a critical technical practice for each Agile Release Train (ART). It improves
quality, reduces risk, and establishes a fast, reliable, and sustainable development pace. With
continuous integration, the system always runs, meaning it’s potentially deployable, even
during development.

 CI is most easily applied to software solutions where small, tested vertical threads can deliver
value independently. In larger, multi-platform software systems, the challenge is harder. Each
platform has technical constructs which need continuous integration to validate new
functionality.

 CI is even more complicated when systems comprise software, hardware, components, and
services provided by suppliers. But the fact remains that frequently integrating and testing
features together is the only practical way to validate a solution fully. As a result, teams need a
balanced approach that allows them to build-in quality and gets fast feedback on their
integrated work.

 For purely software-based solutions, continuous integration is relatively easy to achieve with
modern tools. For more complex systems with hardware and software, a continuous
integration approach is required (see the Enterprise Solution Delivery article) to balance the
economic trade-offs between frequency, the scope of integration, and testing. The Four
Activities of Continuous Integration As illustrated in Figure 2, SAFe describes four activities
associated with continuous integration:

i. Develop describes the practices necessary to implement stories and commit the code and
components to version control
ii. Build describes the techniques needed to create deployable binaries and merge development
branches into the trunk

iii. Test end-to-end describes the practices necessary to validate the solution

AUTOMATION IN AGILE:
Automation in IT can be defined as a set of programs/steps which can be performed independently to
achieve required functions and leads to the reduction of manual effort and improvement in code
quality. Automating the repetitive procedures can provide real value to the projects which are getting
executed using Agile methodology.
Automation is a vital component of maintaining agility, and it is a top priority for the entire team, as
seen by defined practices/disciplines and a commitment to continuous improvement. Automation is
used in a variety of ways, including continuous integration/builds, unit, functional, and integration
testing, and continuous/automated deployment.
By reducing manual effort, automation in software design and testing eliminates risks associated
with human error. It spares developers and testers from repetitive activities and allows them to focus
on the more critical aspects of system quality, thus improving build and testing effectiveness as well
as operational efficiency. Build and testing automation also ensures reusability and scalability, which
in turn translates into significant cost savings.
Some of the areas where automation can play an important role are:
 Code build and deployment
 Unit test execution
 Generating code coverage reports
 Functional & Performance test execution
 Generating code quality metrics reports
 Generating coding conventions reports
After the process has been identified, the Team is recommended to investigate how to automate the
process and identify the tools that could assist with automation. Also, the Team needs to estimate the
level of effort required to implement the automation against the total cost and risk of manual
procedures. In most cases, the decision boils down to cost versus benefit analysis. This module
covers overall concepts of Automation and the areas where Automation can be implemented along
with the associated tools in an Agile project.

Key Concepts:

One of the key principles and benefits of following Agile methodology is faster feedback. This
feedback includes feedback from the Clients, Product Owner, and Delivery team members. Often the
term “Fail Fast” is used to emphasize that it is better to fail earlier so that impediments can be
corrected based on the feedback.
Agile projects usually will have shorter release cycles in order to get early feedback from clients.
Though the functionality delivered is less, it is more important to deliver the right functionality.
From the delivery view, it is important that the team (developers and testers) should be able to
deliver faster. It is imperative that any repetitive manual tasks should be automated. This will free up
the time spent by team members on these repetitive tasks and focus on delivering more value (might
be another story) to the users.
The complexity of a typical enterprise application development and deployment process involving
multiple branches and multiple projects adds a huge cost overhead and risks to the organization.
Some of the benefits of using automation in these cases are listed below:

S.No. Typical Manual process Automated process

01. A tight control is needed on individual A Transparent process as the progress on all
components for monitoring the overall components are more visible and risks can be
process identified more easily

02. Higher repetitive efforts during

Reduced efforts during deployment
deployment

03. The Risk of manual execution error is

Once standardized, the errors are avoided
high

04. Once standardized, a high level of quality is

Could run into quality issues
maintained

05. Inconsistent results as the process are

It gives standard results always.
dependent on the persons involved

Some typical real-life instances:

 Scenario 1: The developer is supposed to make changes to existing functionality. After
completing the development, the developer must test the changes made. Now, if there are no
existing unit test cases, the developer must be performing unit testing for the entire functionality
again. This will in turn increase the time taken for the changes. If the test cases are automated
through various unit testing frameworks using x Unit, the test cases can be run quickly and
validated immediately. The developer can focus only on testing the changes and creating unit test
cases around these changes.
 Scenario 2: After completing unit and integration testing, the developer must promote the
changes to QA/testing environment for further testing by the QA team. If the promotion to the
QA environment involves multiple requests to the infrastructure team and a few hours delay, this
will create a bottleneck. It will be an impediment to the overall team, as there could be multiple
stories that need to be promoted to the QA environment.

Usage of Automation in Agile:

1. Automation in Development:
 Unit Test suite: Unit Testing is one of the basic building blocks for Continuous Integration.
Developers can have a series of their testing automated as simple unit tests and make it available
along with their versioned codebase. These tests should be living test suites i.e. they should run
to success at any point in time. Whenever a code module is changed, the corresponding unit tests
should also be updated and ensured that the test cases are passed. The automated unit tests are the
first line of defense and a crucial part of the “Fail Fast” approach. Various unit testing
 frameworks that are available are – JUnit (for Java), NUnit (for DotNet), utPlSql (for Oracle
PL/SQL).
 Code Quality Analysis: Static code analysis needs to be performed to identify and quantify
the code quality metrics like standards, security risks, and adherence to best practices. As part of
the development practice, code quality checks should be run. Only after attaining satisfactory
quality metrics, the code should be checked into the version control tool. Some of the key tools
for Static Code Analysis are CAST, SONAR. Note that developers can make use of the IDE
(Integrated Development Environment) integration capabilities of these tools to integrate static
code analysis in their development process.
2. Automation in Build:
Continuous Integration (CI): The aim of practicing Continuous Integration is to maintain a build
environment that is able to generate “Production Ready” builds. As part of this practice, the
following actions will be performed:
 Analyze the code for quality
 Build the code
 Execute unit test cases
 Upload build artifacts
 Post-build and test results
 Alert the team with results
This can be achieved effectively through automation. For further details on CI practice, please refer
to the study material on ‘Continuous Integration and Associated Tools’ of this course.
To aid in this practice following support systems are required:
 Source Version Control tools: Through “hooking” (proactively notifying other tools when
new code changes are made) or “polling” (other tools have to poll the Version Control tool to
determine whether new code changes are made), any new code changes should be determined
and communicated to other tools by the version control tool. Example – Git, ClearCase, SVN
 Build tool: A robust tool/framework that helps in maintaining and code build more easily.
Example – Maven, ANT.
 Static code analysis tool: As described in the above section, these tools are used to check the
code quality. Example – CAST, SONAR.
 Build repositories: A robust repository to maintain the builds that can be
uploaded/downloaded/searched with ease. Example – Nexus (for maven builds)
 CI server: Interacts with all the above components and performs the actual build of the
application along with the execution of tests either automatically or just by a click of a button.
Example – Jenkins, Hudson.
3. Automation in Deployment:
Continuous Deployment (CD): A mature Agile team extends the Continuous Integration practice so
that the application can also be automatically and regularly deployed into multiple environments
(realistically lower environments like DEV and QA). This is required to maintain “Production
Deployable” builds. Any deployment issues will also be validated, as part of this process. This is
known as Continuous Deployment.
A typical CD process includes:
 All Continuous Integration steps
 Deployment into needed environments
 Execution of smoke tests
 Publish the outcomes of the deployment
 Alerting the team with results
Usually, an enterprise application will follow multi-tier architecture which includes multiple
technology (Example – J2EE application with Oracle backend). So, to achieve deployment
automation in a multi-tier architecture, there should be an automated orchestration.
For automating the deployments, the delivery team can have a custom script or use an automation
framework like uDeploy. The CI build servers like Jenkins/Hudson can be configured to perform the
CD activities as well.
4. Automation in Testing:
With the nature of the Agile methodology, the software that is developed iteratively will be subject
to testing multiple times either as part of the system integration testing or regression testing. So it is
imperative to automate test execution as much as possible. There are various testing automation
frameworks that are available like Cucumber, FitNesse, QTP, etc. that help in writing and executing
the test cases. It is recommended to create the automated test cases right from the beginning of Sprint
execution in parallel with the User story development.
Once the test cases are automated, they can be scheduled as part of the build servers to be triggered
automatically. This will ensure that the tests are run often and the failures are reported as early as
possible. Following are the various stages that can be automated:
 Smoke Testing
 System Testing
 Regression Testing
 Acceptance Testing

Emerging Trends:

Today, automation is an exciting focus area for technology organizations and a lot of technologies
and tools are emerging in it.
 LiquiBase: This is a tool that tracks the changes that are made to the database. The changes
to the database are maintained in an XML. This helps in subsequent Rollback of changes or
applying a change in one environment to another. This can be used to create/roll backtest data for
unit test cases or to move the changes from the DEV environment to higher environments.
 Chef: This is a tool that automates the deployment and management of infrastructure. With
this tool, Infrastructure is treated as versionable, testable, and repeatable similar to the
application code.

Challenges in Automation:
There are many obstacles to implementing automation in Agile projects. These are:
 Pressure from Product Owners: Product Owners would like to get their working product
out and may not be willing to let the team spend the time on automation frameworks that might
benefit long term. All the stakeholders must be taken into confidence on the benefits of
automation. Return on Investment (ROI) can be calculated on the adoption of automation and
used for articulation.
 Maintenance of automated scripts: It is important that the automation scripts are well
maintained along with the production code. Enough support to be provided to the team to ensure
that the changes to the maintenance of the automation scripts are taken up along with business
priority. As the total number of automated tests increases, the time taken for building and
executing the tests tends to increase. The team should decide on the priority of the tests executed
along with the build and ensure that needed refactoring of automation scripts is performed to
improve, wherever possible.
 Lack of follow-through: Though the delivery team adopts the best practices early in the
development process, the team might lose sight of the vision and may compromise on the
automation activities. The delivery lead or any member of the team should constantly remind the
team in case of any deviations.
 Agile Maturity: Development team might have the mental makeup of giving preference to
the code than the automation scripts or frameworks. The team should be trained appropriately
and instill the practice of creating automated tests along with development, for sustainable
maintenance of the application.
 Timing of Automation: Automating the build process when the project is nearly over,
provides very little benefit. It can, however, save dozens, if not hundreds of hours when
automated as soon as development/ testing begins.

Benefits of Automation in Agile :

 Improved Efficiency: Automation helps in improving the overall efficiency of Agile teams
by reducing the time and effort required to complete repetitive tasks, such as testing and
deployment.
 Increased Productivity: Automation helps Agile teams to focus on more strategic and high-
value tasks, resulting in increased productivity and faster delivery of software.
 Better Quality: Automation can help in improving the quality of the software by reducing
the risk of human error and ensuring consistency in testing and deployment.
 Faster Time-to-Market: Automation helps Agile teams to deliver software faster by
reducing the time required for testing, deployment, and other repetitive tasks.
 Greater Agility: Automation provides Agile teams with greater agility by enabling them to
quickly adapt to changing requirements and market conditions.
 Cost Savings: Automation can help in reducing the overall cost of software development by
reducing the need for manual intervention and minimizing the risk of errors.
 Improved Collaboration: Automation can help in improving collaboration between Agile
teams by providing a common platform for communication and collaboration.
 Enhanced Customer Satisfaction: Automation helps Agile teams to deliver high-quality
software faster, resulting in enhanced customer satisfaction and improved customer retention.

WHAT IS A SCRUM OF SCRUMS?

We all know that a scrum is an integral part of agile methodology, a daily face to face meeting lasting
about 15 minutes or so. The agile team, usually composed of between five to ten people, hunkers down
and hashes out where the team stands in terms of work progress, what they’re working on now, how
long it will take, and what potential obstacles exist.

A scrum of scrums involves multiple scrum teams meeting together by having one or two
representatives from each separate scrum getting together. Hence, a scrum of scrums. Unlike regular
scrum meetings, however, scrum of scrum gatherings don’t have to meet daily; twice a week is enough
in most circumstances.

Why We Need a Scrum of Scrums?

Since scrum teams work best with under ten members, larger companies create more groups to
accommodate the higher number of developers. However, multiple scrum teams must somehow stay in
contact and coordinate their efforts to avoid pitfalls such as redundancy and inefficiency.

That’s why the best solution is a scrum of scrum meeting, which brings together representatives chosen
from each agile team. This way, no team gets left out of the loop, and everyone’s resources get
allocated in an efficient, productive manner.

Regarding scrum of scrum team size, conventional wisdom recommends following the same standards
applied in the smaller-scale scrum meetings: no more than ten attendees. This limitation could force an
organization to hold multiple scrum of scrums, which in turn can require a scrum of scrum of scrums,
but we’ll save that one for a little later!

Benefits of a Scrum of Scrum

So what are these meetings useful for? Although we’ve briefly touched upon a few advantages, it’s
worth listing them for easy reference.

 Easier for huge companies to use scrum methodology

 Streamlines collaboration

 Guarantees that every team stays informed since everyone is represented

 It provides a forum for airing out issues and difficulties, making problem-solving easier

 Facilitates consensus
 Provides a means of dealing with new, unexpected developments that potentially affect
multiple groups or departments

 Reinforces each team’s role and keeps them on course, preventing them from drifting into
another team’s lane

What are the Goals of a Scrum of Scrum?

They are pretty straightforward, and in line with what we’ve already discussed:

 The coordinate output from all the teams involved

 Integrate multiple team’s productions into a single entity

 Eliminate any bottlenecks

To that end, each team representative must answer each of these questions:

 What has your team accomplished since the last meeting?

 What problems arose, if any, that created a roadblock?

 What tasks does your team plan to accomplish before the next meeting?

 What output from your team’s future sprints do you anticipate interfering with the work of
other teams, if any?

 Have you experienced any obstacles stemming from other teams?

These questions help each scrum “ambassador” contribute towards the ultimate success of the scrum of
scrums. The key is to foster a sense of coordination and cooperation, also called cross-team
synchronization, between all the teams.

Who is Involved in a Scrum of Scrum?

Speaking of teams, it’s time to discuss scrum of scrum team size and precisely who is involved in them.
They should feature between five and ten participants, and conventional wisdom dictates that the
representatives should be the Scrum Masters of each scrum team.
However, if each team sends only their Scrum Master, there is the risk of bringing a limited perspective
to the scrum of scrums. For instance, it’s rare for a tech person to be the Scrum Master, and it’s exactly
that kind of input that larger meetings may require. The possible need for technical input speaks to the
idea of having two representatives from each team, maybe the Scrum Master and the tech person, or
perhaps a member of the development team.

Optionally, the scrum of scrums should also include the product owner. This person’s perspective can
potentially come in handy. Smart planners will invite product owners only if there is little to no risk
that the meeting will lose its focus. The meeting shouldn’t be a forum for product owners to air
grievances and attempt to make development decisions outside of their wheelhouse.

Then we have the issue of who runs the scrum of scrums, or to stay in the jargon, the scrum of Scrum
Master. While many meetings function perfectly well as a self-leading body, a larger group meeting
may require someone to step into the Scrum Master role.

The bottom line, any team or group that is responsible for a deliverable as part of the release plan
should have a representative attending the scrum of scrums.

How to Conduct a Productive Scrum of Scrums?

Here are some tips for having an effective meeting:

 Make sure each team knows what points to share in the meeting. We covered those items above.

 Make sure to appoint the right people to the meeting. Same as the first item, each team needs to
send the right person, and it’s not always the Scrum Master.

 Set the meeting length and frequency ahead of time. No more than twice a week, with a period
between 30 minutes to an hour, tops. If you can keep it to the size of a regular scrum, 15 minutes
long, then so much the better.

 Set aside time to solve problems. This isn’t just an exercise to get a status report.

 Create an environment where everyone feels at ease with sharing concerns and other
information. That means creating trust and transparency with all the team members.
 Emphasize to each attendee that the information covered in the meeting must be brought back
to each team and relayed clearly to them. If people aren’t informed, then why have these meetings
in the first place?

 Remember that it’s a scrum of scrum meetings, not a status meeting. People aren’t here to only
report on what they’ve done. Scrum meetings are more than this. Status meetings are holdovers
from the waterfall methodology and have no place in this agile method.

What is a Scrum of Scrum of Scrums?

Yes, this is a thing. A scrum of scrum of scrums meeting brings the Scrum Masters of each scrum of
scrum meeting together into an all-encompassing, large meeting. When the overall developer team size
is so large that even breaking it down into scrum of scrum teams isn’t enough, it’s time to bring out the
scrum of scrum of scrums.

Meetings of this magnitude are crucial in these cases because the more extensive the project staff, the
higher the risk of things getting unwieldy, including communications breakdowns and confusion over
individual team roles.

These meetings are often referred to as a large-scale Scrum (LeSS) and are designed to handle
hundreds of developers.

WHAT IS AGILE COLLABORATION?

Agile collaboration is the practice of working together effectively within an agile framework, such as
Scrum, to achieve common goals. Agile collaboration is about fostering a high-performing
team culture where team members work together, hold each other accountable, and continuously
improve through shared goals and mutual support.

How Does Collaboration in Agile Teams Feel?

A common metaphor for agile teamwork is a rowing crew: 8 people each pulling an oar in a shell boat.

Unless you’ve rowed on a team you may not know how perfectly it captures the agile collaboration
meaning and spirit.

Rowers use the term swing to refer to a crew whose members are all perfectly synchronized. And I do
mean perfectly synchronized. This means each rower:

 puts an oar into the water at the exact same time

 pulls for the the same time and distance at the same speed
 lifts the oar out of the water at the same time, and
  slides forward at the same pace

Swing doesn’t happen very often. Someone is usually off by a fraction of a second at some point each
stroke, and that’s enough that everyone in the shell feels it. When I rowed, our boat might have gone an
entire race without once truly achieving swing.

(Yes, it was usually my fault. Thanks for asking.)

Benefits of Agile Collaboration

There are many good results when a cross-functional team achieves the feeling of swing that comes
from collaborative agile teamwork.

Small, Frequent Handoffs. Handoffs of work between team members are frequent, small, and without
fanfare, because tasks are designed to overlap. Team members become like couples who’ve been
together long enough that they finish each other’s ... (Did you finish my sentence for me?) But instead
of finishing each other’s sentences, they finish each other’s work.

Short and Valuable Meetings. When teams achieve the swing of cross-functional collaboration,
meetings are short and valuable because feedback loops are short, and happening in real time. Team
members are working together and communicating often, so most people are up to speed already, so
meetings can focus on what matters.

Collaborative Planning. Teams work towards a goal, and they generally achieve that goal. When they
don't meet a goal, everyone (including leaders) understands that goals are not guarantees.

Try-It-and-See Mindset. In agile and collaborative cultures, a try-it-and-see mindset prevails. Instead
of arguing over practices (such as user stories vs. job stories or story points vs. time) or frameworks
(Scrum vs. SAFe or Kanban), empowered teams experiment and decide for themselves what works
best.

Fun and Engaging Work Environment. On an agile team in swing, team members are having fun. I
sometimes decry that work is called work. I sincerely want work to be fun. I’m not naive: I know that
won’t always be the case. But when a team is working together well, it is fun.

Inevitable Success. Finally, with swing there is a feeling that success is inevitable. As a Scrum team
delivers more and more value, achieving outcome after outcome, the team starts to almost consider
itself unstoppable.

Agile Collaboration Is Hard, But Achievable

Achieving all of this isn’t easy, just as it’s not easy for a rowing crew to swing. But when a team is
collaborating well, it is a sign that you have built a successful agile team.

As a company, we’re lucky to work with many different agile teams, training them to improve
collaboration and find their swing.

We’ve learned that there’s no one set path to achieve this. Some teams need to level-set their
understanding of agile, others need to write better user stories together, or collaborate on agile plans.
It’s one of the reasons we designed our Flex and Select passes for agile teams. You get discounted
training seats and don’t have to select a course until a later date. If you’re planning future agile training
but don’t know which classes are best for your team, consider one of these flexible training options.

1. SCRUM OVERVIEW

Scrum is an Agile framework that uses fixed-length iterations, called Sprints, to develop and deliver
high-quality products incrementally. It emphasizes collaboration, flexibility, and delivering value to the
customer.

2. ESTIMATING A SCRUM PROJECT

Estimation in Scrum is done to predict the effort required to complete tasks in the backlog, often using
story points or time-based measures.

Common estimation techniques:

 Story Points: Scrum teams use relative estimation (e.g., Fibonacci sequence: 1, 2, 3, 5, 8, etc.)
to estimate the size or complexity of a user story. Larger stories are broken down into smaller
ones.
 Planning Poker: A group estimation technique where team members independently estimate
the effort for a user story, then discuss and come to a consensus.
 T-shirt Sizes: Stories are estimated using sizes like XS, S, M, L, XL, representing relative
effort.
 Ideal Hours: Estimating the amount of time it would take to complete the story if there were
no distractions or interruptions.

Factors affecting estimates:

 Complexity of the user story

 Dependencies
 Team experience
 Tools or technologies involved

3. TRACKING SCRUM PROJECTS

Tracking progress in Scrum is key to ensure the team is on track and delivering value. This is done
through various tools and techniques:

Key Tracking Tools:

 Burndown Chart: Visual representation of the work completed vs. the work remaining in a
Sprint or Product Backlog. It helps track progress and predict if the team will complete the
work on time.
 Sprint Backlog: A detailed list of tasks identified by the team to complete during a Sprint.
 Product Backlog: The prioritized list of all features, enhancements, and bug fixes that need to
be addressed.
 Kanban Board: Visual representation of work items, showing where they are in the workflow
(e.g., To Do, In Progress, Done).
  Cumulative Flow Diagram: Helps in visualizing the flow of work through different stages of
the process.

TRACKING METRICS:

 Velocity: The amount of work the team completes per Sprint (usually measured in story points).
 Cycle Time: The time it takes for a work item to move from start to finish.
 Lead Time: The time from when a work item is created to when it's completed.

4. COMMUNICATION IN SCRUM PROJECTS

Communication is a vital part of Scrum as it ensures the team is aligned, problems are addressed
quickly, and the project stays on track.

Communication Practices:

 Daily Standup (Daily Scrum): A short meeting (usually 15 minutes) where each team member
answers three questions:

o What did I do yesterday?

o What will I do today?
o Are there any blockers?

 Sprint Planning: A meeting at the start of each Sprint where the team discusses what will be
delivered and how.
 Sprint Review: At the end of each Sprint, the team demonstrates the completed work to the
stakeholders and gathers feedback.
 Sprint Retrospective: A meeting to discuss what went well, what didn’t, and what
improvements can be made for the next Sprint.
 Backlog Refinement: Regular sessions to review and refine the Product Backlog to ensure it is
ready for future Sprints.

Tools for Communication:

 Slack, Microsoft Teams, or Zoom: For remote communication.

 Jira, Trello, or Asana: For task management and communication about individual user stories.
 Confluence: For documenting decisions, progress, and retrospective notes.

5. BEST PRACTICES TO MANAGE SCRUM PROJECTS

Best practices can help ensure smooth execution of Scrum projects and promote a high-performing
team environment.

 Cross-functional Teams: Ensure that your Scrum team has all the necessary skills to deliver
end-to-end work (development, testing, design, etc.).
 Prioritize Product Backlog: Ensure that the Product Owner is actively refining and
prioritizing the backlog to focus on the most valuable items.
 Focus on Small, Iterative Deliverables: Break work into small, manageable user stories that
can be completed within a Sprint.
 Ensure Transparency: Make sure the process is transparent to all stakeholders, including
regular updates and reviews.
 Embrace Change: Agile and Scrum require flexibility. Embrace changes in requirements and
prioritize working software over documentation.
  Continuous Improvement: Hold regular retrospectives to continuously improve the team’s
processes and efficiency.
 Empower Teams: Encourage self-organizing teams where the team members are empowered
to make decisions.
 Definition of Done (DoD): Establish a clear and consistent definition of what it means for a
work item to be "done," including criteria for testing, documentation, and review.

COMMON PITFALLS TO AVOID:

 Overloading the Team: Don’t add too many items to a Sprint. Ensure the team’s workload is
manageable.
 Neglecting Retrospectives: These meetings are essential for improvement, so they should not
be skipped.
 Lack of Product Owner Involvement: The Product Owner should be active in managing and
refining the backlog, and providing feedback.
 Not Adapting the Process: Scrum is iterative. Continuously adapting the process based on
feedback will lead to better outcomes.