Agile Values,Agile Principles-Agile Manifesto, 4 values of Agile,12 Agile Principles

What is agile?
Agile is a set of values and principles. It's documented in the Agile Manifesto.
This set of beliefs helps teams to make better decisions, and by that create better solutions for
customer's problems.
The simple definition of agile is step-by-step. Take something big, and break the most urgent
thing into smaller pieces. By taking small steps you can see clearly if you're doing the right thing.
If not, you can adjust course.

he hard thing about values and principles is they aren't as visible as tools and processes. This is
why you see many companies make the same mistake:
They copy processes and tools they have seen from other companies, but fail to do the hard work
in helping people understand the principles and values.
I'll deep dive on that more in the next chapters.
First, let's have a look at agile's origins.
How was the Agile Manifesto created?
The Agile Manifesto was made early 2001. A group of 17 people met in Snowbird, Utah, to
discuss the future of software development. The Agile Alliance (as they called themselves) had a
shared frustration about the status quo, but all had their own view on how to resolve this.
Their frustration:
Companies were excessively focussed on planning and documenting their software. Because of
that, the companies forgot what really was important. Helping their customers.
(Exactly! Identical to mine during my studies.)
The companies had defined nice company values as "quality" and "impact", but in reality they
were organised in a way that was preventing them from helping their customers early and often.
The Agile Alliance wanted to change that.
They all had a background in software development (Scrum, XP, Kanban, RUP) and years of
experience. The trip to Snowbird was their chance to create a shared vision on how to break the
status quo.
They created the Agile Manifesto in a weekend. A short and to the point document with four
values and twelve principles, that since then has changed the way we do business.
It has made many startups rapidly successful. Because of that, many traditional teams and
organisations are embracing the agile way of working.
But the problem is, that you can't simply copy and paste values from one organisation to the other.
Not without doing the hard work.
The Agile Manifesto authors
The authors of the agile manifesto are:
 Kent Beck
 Mike Beedle
 Arie van Bennekum
1
 Alistair Cockburn
 Ward Cunningham
 Martin Fowler
 James Grenning
 Jim Highsmith
 Andrew Hunt
 Ron Jeffries
 Jon Kern
 Brian Marick
 Robert C. Martin
 Steve Mellor
 Ken Schwaber
 Jeff Sutherland
 Dave Thomas
You might be wondering:
So what's so special about these agile values and principles? And how can I make them work for
me?
That's what I'm going to cover in the rest of the guide.
Keep reading...
When it comes to agile, one of two things can happen:
✅ Thing #1: You Do The Hard Work
Grow, with the people around you, resulting in happier customers and a far more successful
company.
❌ Thing #2: You Copy An "Agile Model" From Somewhere Else
Watch people struggle and get frustrated faster than you can say "what happened?!".
It's like a relationship: You invest in each-other, because in the end you know it's worth it.
With that, these are the four agile values that are dividing the winners from the losing companies.

THE AGILE MANIFESTO

• On February 11-13, 2001, at The Lodge at Snowbird ski resort, 17 people met to drink beer, ski,
relax, and try to find common ground.,and of course, to eat. What emerged was the Agile
‘Software Development’ Manifesto.
• Representatives from Extreme Programming (XP), SCRUM, DSDM, Adaptive Software
Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others
participated. A bigger gathering of organizational anarchists would be hard to find, so what
emerged from this meeting was a signed Manifesto for Agile Software;
• Alistair Cockburn’s initial concerns reflected the early thoughts of many participants. He didn't
expect that this particular group to ever agree on anything. But his post-meeting feelings were
also shared, "Speaking for myself, I am delighted by the final phrasing. I was surprised that the
others appeared equally delighted”.

The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting principles
which lead the Agile approach to software development. Each Agile methodology applies the
four values in different ways, but all of them rely on them to guide the development and delivery
of high-quality, working software.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.”
Valuing people more highly than processes or tools is easy to understand because it is the people
who respond to business needs and drive the development process. If the process or the tools
drive development, the team is less responsive to change and less likely to meet customer needs.
2
Communication is an example of the difference between valuing individuals versus process. In
the case of individuals, communication is fluid and happens when a need arises. In the case of
process, communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development
and ultimate delivery. Technical specifications, technical requirements, technical prospectus,
interface design documents, test plans, documentation plans, and approvals required for each.
The list was extensive and was a cause for the long delays in development. Agile does not
eliminate documentation, but it streamlines it in a form that gives the developer what is needed to
do the work without getting bogged down in minutiae. Agile documents requirements as user
stories, which are sufficient for a software developer to begin the task of building a new function.
The Agile Manifesto values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of a
delivery, with points along the way where the details may be renegotiated. Collaboration is a
different creature entirely. With development models such as Waterfall, customers negotiate the
requirements for the product, often in great detail, prior to any work starting. This meant the
customer was involved in the process of development before development began and after it was
completed, but not during the process. The Agile Manifesto describes a customer who is engaged
and collaborates throughout the development process, making. This makes it far easier for
development to meet their needs of the customer. Agile methods may include the customer at
intervals for periodic demos, but a project could just as easily have an end-user as a daily part of
the team and attending all meetings, ensuring the product meets the business needs of the
customer.
4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The
intention was to develop detailed, elaborate plans, with a defined set of features and with
everything, generally, having as high a priority as everything else, and with a large number of
many dependencies on delivering in a certain order so that the team can work on the next piece of
the puzzle.
With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration
and new features can be added into the next iteration. Agile’s view is that changes always
improve a project; changes provide additional value.
Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method
Tailoring, defined in An Agile Information Systems Development Method in use as: “A process
or capability in which human agents determine a system development approach for a specific
project situation through responsive changes in, and dynamic interplays between contexts,
intentions, and method fragments.” Agile methodologies allow the Agile team to modify the
process and make it fit the team rather than the other way around.

3
 The Twelve Agile Manifesto Principles
The Twelve Principles are the guiding principles for the methodologies that are included under
the title “The Agile Movement.” They describe a culture in which change is welcome, and the
customer is the focus of the work. They also demonstrate the movement’s intent as described by
Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development
into alignment with business needs.
The twelve principles of agile development include:
1. Customer satisfaction through early and continuous software delivery – Customers
are happier when they receive working software at regular intervals, rather than waiting extended
periods of time between releases.
2. Accommodate changing requirements throughout the development process – The
ability to avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the
team operates in software sprints or iterations that ensure regular delivery of working software.
4. Collaboration between the business stakeholders and developers throughout the
project – Better decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to
deliver their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when
development teams are co-located.
7. Working software is the primary measure of progress – Delivering functional
software to the customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a
repeatable and maintainable speed at which they can deliver working software, and they repeat it
with each release.
9. Attention to technical detail and design enhances agility – The right skills and good
design ensures the team can maintain the pace, constantly improve the product, and sustain
change.
10. Simplicity – Develop just enough to get the job done for right now.
4
11. Self-organizing teams encourage great architectures, requirements, and designs –
Skilled and motivated team members who have decision-making power, take ownership,
communicate regularly with other team members, and share ideas that deliver quality products.
12. Regular reflections on how to become more effective – Self-improvement, process
improvement, advancing skills, and techniques help team members work more efficiently.
The intention of Agile is to align development with business needs, and the success of Agile is
apparent. Agile projects are customer focused and encourage customer guidance and
participation. As a result, Agile has grown to be an overarching view of software development
throughout the software industry and an industry all by itself.

What is a stakeholder?
A stakeholder is a person, group or organization with a vested interest, or stake, in the decision-
making and activities of a business, organization or project. Stakeholders can be members of the
organization they have a stake in, or they can have no official affiliation. Stakeholders can have a
direct or indirect influence on the activities or projects of an organization. Their support is often
required for business and project success.
The International Organization for Standardization's ISO 26000 is a set of international
standards for corporate social responsibility. It offers the following criteria for identifying a
stakeholder:
 An organization is legally obligated to stakeholders.
 They might be positively or negatively impacted by an organization's decisions.
 They are likely to express concerns and be involved in the activities of an organization.
Based on this criteria, stakeholders often include customers, employees, investors, suppliers,
boards of directors, community members and organizations, and government entities.
Stakeholder capitalism is a system in which an organization prioritizes stakeholders' interests.
The term stakeholder has its roots in horse racing. A stake race is one in which the prize money is
derived from the entry fees that horse owners pay to enter the race. The entry fee is called a stake,
a synonym for risk. The person or entity that takes care of the entry fees until the prize money is
awarded is called the stakeholder. Traditionally, the stakeholder has no financial interest in the
outcome of the race.

Types of stakeholders

5
 Stakeholders can come from a variety of connections to the organization or project. The most
common types of stakeholders include the following:
 Customers usually expect organizations to deliver products of value.
 Employees are often project stakeholders, who want to contribute to a project that is
related to their job.
 Owners supply an organization's equity and capital and are responsible for organizational
goals.
 Investors are shareholders, who invest in organizations in exchange for financial returns
and often receive regular financial reporting on the companies they invest in as well as voting
power in major decisions.
 Creditors, such as banks and bondholders, lend money to an organization to be paid back
with interest.
 Suppliers are vendors that supply materials and products to organizations and have an
interest in their business and the projects they pursue.
 Communities have an interest in businesses being healthy, safe and beneficial to local
economies. Businesses create jobs and business for local communities. Environment,
sustainability and governance (ESG) are increasingly important values for consumers and
investors.
 Governments collect taxes from companies and their employees.

Transparency and engagement with stakeholders are some of the most important principles for
corporate governance.
Internal vs. external stakeholders
Stakeholders are often categorized into the two main groups of internal stakeholders and external
stakeholders.
Internal stakeholders
Internal stakeholders are those within a company whose interest stems from direct employment,
ownership or investment. Internal stakeholders of a company or project can include
employees, project managers, boards of directors, donors and investors. These individuals are
often referred to as primary stakeholders, or key stakeholders, because they have a direct stake
and important role in the company's or project's success.
External stakeholders
External stakeholders are those outside of a company who are indirectly affected by its decisions
and outcomes. External stakeholders include customers, suppliers, government agencies,
creditors, labor unions and community groups. These entities are also referred to as secondary
stakeholders because their stake in the company or project is often more representational than
direct.
6
 Examples of stakeholders
Stakeholders exist across industries. For example, in healthcare, stakeholders are those who have
a direct interest in healthcare services provided and the decisions made around them. These
include doctors, nurses and other medical professionals; hospitals, clinics and healthcare
providers; healthcare IT, medical equipment and other suppliers; governing
bodies; nonprofit organizations; and patients.
Another example is a stakeholder in a legal process. There, a stakeholder is an individual or
group in temporary possession of money or property while the owner is being determined in
court.
In a project setting, the stakeholders are people who have direct influence on whether a project is
successful. They include the following:
 customers, whose satisfaction with a product or project is the end goal of a project plan;
 project managers, who manage and lead a project;
 project sponsors, who finance a project; and
 project team members, who are the employees executing a project.
Stakeholders vs. shareholders: What is the difference?
Shareholders are stakeholders who are financially invested in an organization. While
stakeholders are interested in a company's overall performance, shareholders have an added
interest in the company's stock performance or return on investment.
A shareholder's investment helps fund an organization and its activities. Depending on the size of
investment, shareholders can sometimes have more influence on an organization and its projects
than stakeholders. Investment can grant shareholders the right to regular financial information
about an organization and to participate in business decisions.
How to manage stakeholders
In the 1984 book, Strategic Management: A Stakeholder Approach, R. Edward Freeman
emphasized the idea that a business is a system that's built on relationships, and no one part of the
system can be viewed as an isolated entity. Freeman's stakeholder theory is an organizational and
relationship-based management model. It is credited with helping to raise social consciousness in
business about the value of treating stakeholders ethically.
In their 1983 article, "Stockholders and Stakeholders: A New Perspective on Corporate
Governance," R. Edward Freeman and David L. Reed proposed that for a business to succeed, it
must create value or be a value driver for the owners or stockholders. They also said that a
business must create value for stakeholders who do not have a direct financial interest in the
company's success, but without their help, the business could not exist. According to Freeman
and Reed's analysis, the job of the entrepreneur is to find out who the stakeholders are and
determine where their interests intersect with those of the stockholders.
Today, the key components in managing stakeholders include analysis, prioritization and
engagement.
Stakeholder analysis
This analysis start with the process of identifying and ranking a project's major stakeholders.
Once stakeholders are identified, stakeholder analysis weighs the demands and influence of those
stakeholders, then ranks which ones are most likely to influence or be influenced by the
company's actions. This information is used to make more balanced and effective business
decisions.
Stakeholder analysis is a central part of stakeholder management, which is a process that studies
the varying motives and concerns of stakeholders to cultivate positive relationships. Both internal
and external stakeholders must be considered when conducting stakeholder analysis.

7
 Creating a communication plan for keeping stakeholders updated is vital to stakeholder and
project management.

Prioritize the major stakeholders

Projects often have several major stakeholders with different interests and values. Once an
organization or project has identified and ranked those stakeholders, it often identifies at what
stage those different stakeholders should be prioritized and engaged with. For instance, investors
are prioritized at the beginning of a project to elicit their investment. They might also get status
reports at set intervals. By contrast, project management best practices recommend that project
team members be engaged more regularly as a project progresses.
Stakeholder engagement
A successful stakeholder management strategy depends on strong, productive stakeholder
engagement. This involves proactive engagement with stakeholders throughout the various
phases of a project. A key part of this engagement is learning and meeting stakeholders'
expectations and goals. Organizations should document stakeholder interests, consistently follow
up with them through a communication plan and provide them with status reports.
The interests and values of stakeholders have a vital influence on modern businesses. Learn
how the benefits of ESG values are influencing consumers, investors and businesses.

Stakeholders and Challenges-Types of stakeholders, role of Stakeholders,Techniques for

effective stakeholder engagement, stakeholder anlysis , Setting a vision for stakeholder
Involvement, Challenges in stakeholder Engagement and Solutions

CONTENT
1. INTRODUCTION
2. CONCEPTS5
3. STAKEHOLDER ENGAGEMENT6
3.1. STEP 1: SET ENGAGEMENT OBJECTIVES
3.2. STEP 2: STAKEHOLDER ANALYSIS
3.2.1. IDENTIFY THE STAKEHOLDERS
3.2.2. ANALYZE
3.2.3. MAPPING
3.3. STEP 3: DEVELOP AN ENGAGEMENT PLAN
3.3.1. SELECTING AN ENGAGEMENT APPROACH
3.3.2. FINDING THE TECHNIQUE
3.4. STEP 4: IMPLEMENT ENGAGEMENT PLAN
8
 3.5. STEP 5: ASSESS THE ENGAGEMENT PROCESS
3.6. STEP 6: REACT TO ENGAGEMENT RESULTS
3.7. STEP 7: MEASURE AND REPORT PROGRESS
4. CONLUSION

1. INTRODUCTION
Internationalisation of SMEs is a key influencing factor of their competitiveness and the
prosperity of their regions. In border areas it offers additional potential for cooperation and new
markets. Borders and peripheral position may however also hinder cross-border and international
business activities, especially in less developed economies of the EU. Coming from that, the aim
of the project Inter Ventures is to promote the internationalization of SMEs in EU border
regions, thus contributing to their growth and increased competitiveness and contributing
though to the development of boarder regions.

Engaging Stakeholders in the process of SME internationalisation is important because, for

example, a particular policy change may disadvantage an established local business or may have
implications for groups of SMEs concerned with the particular issue. Engaging actively with
Stakeholders from the start of the project is essential for achieving the aims of this project. By
engaging with Stakeholders more broadly, rather than just engaging with few other organizations
on the same field, enables the Project Partners to consider the range of individuals, groups and
organizations that might benefit from the project Inter Ventures. In addition, there is an equally
powerful argument that working with Stakeholders, particularly with those who can make
decisions regarding the development of policy or the distribution of resources concerning SME
internationalisation, can enable the Project Partners to do more relevant work that is more likely to
yield beneficial impacts. The latter is because Stakeholders are more likely to feel ownership over
the project if they are embedded in it and are therefore more likely to assist the Project Partners
and help to implement project recommendations.

This Methodology for Stakeholder Engagement has been designed by the Association of the
European Border Regions (AEBR) to support the project Inter Ventures approach on
internationalization of SMEs in cross-border areas by providing a tool to Project Partners to better
understand what is a Stakeholder, why Stakehodleer engagement is necessary, what would the
Project Partners gain from Stakeholders while pursuing the objectives of the project Inter
Ventures, and finally, how to engage / to interact with the Stakeholders.

On the following pages the Methodology with seven steps for engaging Stakeholders will be
introduced together with tips to the Project Partners about how to benefit the most from this
engagement.
2. CONCEPTS
Before continuing with discussions on the Stakeholder engagement, the key definitions, used
throughout this Methodology.

STAKEHOLDER:
A Stakeholder in the project Inter Ventures is any person, organisation or group that is affected
by or who can affect the outcomes of this project1.

STAKEHOLDER PARTICIPATION:
Stakeholder Participation is a process where Stakeholders (e.g. individuals, groups and
organizations) choose to take an active role in making decisions about things that affect them.

STAKEHOLDER ENGAGEMENT:
9
Stakeholder Engagement is everything that can be done with Stakeholders within the project, i.e.
consult, listen, understand, communicate, influence, negotiate, etc., with the broader objectives of
satisfying the needs of the project Inter Ventures through gaining the approval and support of the
Stakeholders, or at least minimising their opposition or obstruction.

STAKEHOLDER ANALYSIS:
Stakeholder Analysis aims to identify people, organizations or groups who may be either
positively or negatively affected by the project Inter Ventures. In addition to identifying those
affected by the particular project, Stakeholder Analysis also seeks to identify those who might
affect the ability to complete the project and who generate impacts, either positive or negative,
i.e. they may have the power to enable or block the outcomes of the project.
STAKEHOLDER ENGAGEMENT
The main aim of the Stakeholder engagement process in the project Inter Ventures is to identify
and engage every important Stakeholder at local, regional, national and international level to
ensure that the outcomes of the project Inter Ventures will be solidly contained in regional,
national and EU policies.

However, even though every Stakeholder engagement process has to be tailored for different
needs and requirements, on the basis of Deming Circle (PDCA – plan, do, check, act), a number
of recurring steps can be identified that are fundamental for an effective Stakeholder engagement
(see Figure 1).

Figure 1: Stakeholder engagement process. Modification from the Deming Circle (PDCA – plan,
do, check, act)

All these seven steps of the Stakeholder engagement will be discussed in the following chapters of
this Methodology.

10
3.1. STEP 1: SET ENGAGEMENT OBJECTIVES
A good planning can help in reducing the lengthiness of the process, reducing its costs and helping
in maintaining the defined objectives of this project. Though, before beginning a Stakeholder
engagement process, the objectives need to be set for the Stakeholder engagement. Answering the
following questions will help to set the objectives for the Stakeholder engagement:

PRIORITY
What is your priority in engaging Stakeholders? / Why a Stakeholder engagement process should
be undertaken? For example, Stakeholder engagement is a reaction to an external pressure.

SCOPE
What is the scope of Stakeholder engagement? For example, what is the geographical area
(particular municipality, region or a border area)? What is the timeline – is it going to be a lasting
process or just one-time-only?

EMBEDDEDNESS
Where does the Stakeholder engagement fit into your organization? For example, what unit is
responsible for the Stakeholder engagement?

WHO
Who has a stake? Even though a full Stakeholder mapping will be discussed in Step 2: Identify
and, main Stakeholder groups should be considered also in here. For example, academics,
chambers of commerce etc. In here should also be considered the possible conflicting interests
between Stakeholders.

ENGAGEMENT
How to engage? / Level of involvement of Stakeholders? The Engagement Plan and techniques
will be discussed in more detail in Step 3, but the overall vision, level of ambition and availability
of resources (financial, human (including capacity building), temporal and technological) will
determine if the engagement is proactive or reactive. For example, the Stakeholder engagement
can take the form of a single meeting or involve the creation of a continuing dialogue mechanism
such as, for example, a Stakeholder Advisory Board. Also, the engagement should be structured in
a way that enables the perspectives of diverse Stakeholders to be considered.

Note that in the context of Stakeholder engagement, an engagement approach should be used that
is culturally sensitive and accessible to all participants. This means considering context, location,
format, and language.
3.2. STEP 2: STAKEHOLDER ANALYSIS

In the beginning of planning a Stakeholder engagement process, a Stakeholder Analysis needs to

be carried out. Through the Stakeholder Analysis will be identified those groups and individuals
that will ultimately affect or will be affected by the process and outputs of the project Inter
Ventures. Stakeholder Analysis is also important to distinguish the pre-mentioned group from those
who are not directly involved or affected by the project Inter Ventures. Therefore, being able to
identify and select the right Stakeholders is of fundamental importance since each Stakeholder has
different types and content of information, perceptions, interest and influence of an issue and not
all of them may result useful in a specific context.

A successful Stakeholder Analysis will help to

- Identify who has a stake in the project
- Categorize and prioritize the Stakeholders that are needed to concentrate on; and
- Identify existing relationships between Stakeholders (whether conflicts or alliances).

There are three stages in this process – identify, analyse and map. Each stage will be discussed
thoroughly below. 11
3.2.1. IDENTIFY THE STAKEHOLDERS

All the relevant Stakeholders should be identified prior to any attempt to engage. The preliminary
list of Stakeholders for the project Inter Ventures can be found in Annex 5.6. However, for every
Project Partner, the list should be amended and modified based on the of the Project Partner, the
institutional context and the objectives for Stakehodler engagement. It can be done via answering
the following questions:
- Who has the best knowledge to enforce the outputs of the project Inter Ventures?
- Who has the power to enable project Inter Ventures to achieve the aimed impacts, and
who has the power to block them?
- Who might be disadvantaged or lose out as a result of this project?

Brainstorm the list of Stakeholders without screening; include everyone who has an interest in
project Inter Ventures in your area today and who may have one tomorrow. Where possible,
identify individuals – not just organizations. Here are some additional considerations to help you
brainstorm:
- Learn from past and current engagements: Which Stakeholders communicate regularly
with your organization?
- Consider the future: assess potential Stakeholders from new groups
- Ensure diversity: make sure to include a rich diversity of Stakeholders embodying a
spectrum of expertise, attitudes and geographies. Include individuals from each of the Stakeholder
categories (see Figure 2 for reference): key players, context setters, subjects, crowd2.
- Use technology tools: analyse your social media, it provides opportunities to understand
who is interested in your organization.
- Consider the impact: it is crucial not to prioritize noisy critics over genuine experts. It
should be carefully considered who is most impacted by the decisions and operations within this
project.

To identify the Stakeholders, you can use also questionnaire with snowball effect (see an example
questionnaire in Annex 5.5).
Note that in creating the list of Stakeholders, it is important to ensure that no significant
Stakeholders have been omitted from the project, as such omissions can significantly compromise
the success of the project.

Lastly, the final list of Stakeholders should not remain static over time, but should change as the
external environment evolves and as Stakeholders themselves make decisions, shift focus or
change their opinions.
3.2.2. ANALYZE
Together with the identification, Project Partners should profile the Stakeholders in order to
properly engage them. Below is provided a list of potential criteria the Project Partners might use to
analyse the Stakeholders. Note that not all of these criteria will be relevant 3 for every engagement,
and we recommend an absolute maximum of four distinct criteria:

Interest: How willing is the Stakeholder to engage with the Project Partner and the overall
process?

Influence: How much influence does the Stakeholder have over the outcomes of the Inter
Ventures project, either directly or via other Stakeholders? How they can influence the targeted
Policy Instrument? In here must be also clarified whom they influence, e.g. SMEs, associations,
policy makers etc.

To determine the connections and influence a Social Network Analysis (SNA) can be conducted
(see Figure 1 for a map that it creates). SNA is a good solution for projects with high-stakes to
identify Stakeholders who may shape the future trajectory of an issue, even if their direct influence
on the project is currently low. 12
Figure 1. An example of Stakeholder mapping. The Stakeholders with many connections and the Stakeholders
which connect smaller groups to the main group are considered as Key Players.

Also, identification of the key relationships is very important to avoid exacerbating conflicts and
enable creation of alliances that empower marginalized groups. It can be very valuable to know in
advance about conflicts between individuals, organizations or groups, so that inflaming conflicts
and disputes can be either avoided or solved.

Expertise: Does the Stakeholder have information or expertise on the issues dealt with within this
project, either directly or because they will shape the future of an issue?

Orientation: is the view of the Stakeholder toward the outcomes of the project Inter Ventures a
collaborative or a combative one?

Vulnerability: to what degree will the Stakeholder be impacted by the project?

Capacity: to what degree does the Stakeholder have the capacity to engage at the level desired by
the Project Partner? To what degree is the Stakeholder able to meet the commitments required by
the entire engagement?

Trust: What degree of mutual familiarity and trust is there between the Project Partner and the
Stakeholder? Is there a track record of both sides adhering to commitments, respecting
confidentiality, and engaging in productive dialogue?

To profile the Stakeholders, select from above criteria to generate a chart with short descriptions of
how Stakeholders fulfil them (for example, see Table 1 below). This data set will help the Project
Partners later to decide which Stakeholders to engage and how.

Table 1. Profiling the Stakeholders

Stake- Influence Interest Expertise Orientatio Vulnerabilit Capacity Trust
holder n y
High: High: High: High: High: theLow: theLow:
Stakeholder Stakeholder Stakeholder’s Proactive Project willStakeholder mutual
is a keyhas high knowledge in Stakeholder directly has few trust is
A shaper of interest and the issue is impact the resources low
opinion in willingness of value to life of this for
this field to engage the Stakeholder engagement
with this Project
project Partner 13
 B Medium Low Medium Low Medium Medium High
C Low Medium Low Medium Low High Medium

In choosing the criteria, note that expertise, influence and interest are the criteria that are likely to
be relevant for any strategic engagement.
3.2.3. MAPPING
Mapping of Stakeholders generates a visual analysis that Project Partners can use to further
determine which Stakeholders will be the most useful to engage with. Mapping allows the Project
Partners to evaluate Stakeholders by using consistent criteria, and helps to visualise the often
complex interplay of issues and relationships. In mapping, the Project Partners may need to create
a number of visualizations to capture all possible sights.
The most commonly used approach is to consider the relative interest of a Stakeholder in the issue
or decision being considered versus their level of influence over that issue or decision. This is
typically done by using an ‘interest-influence matrix’ (Figure 2). To add more dimensions to this
grid, the Project Partners can plot the Stakeholders on the grid by using different circle sizes or
different colours to mark, for example, the expertise of the Stakeholder or its vulnerability.

Using the interest-influence matrix, the Stakeholders can be classified as key players, context
setters, subjects and the crowd.

High Context setters Key players

Level of influence

Low Crowd Subjects

Low High
Level of interest

Figure 2. Interest-influence matrix used to identify stakeholders with differing levels of interest and
influence
over the particular project (adaption from Mendelow’s power-interest matrix)

Stakeholders with high levels of interest and influence are termed key players, and it is argued by
some that priority should be given to engaging actively with this group to affect change.

Context setters are highly influential, but have little interest in the particular project. However,
because of their influence, they may have significant influence over the success of the particular
project, but may be difficult to engage with. Though, particular effort may be necessary to engage
this group in the project.

Subjects have high levels of interest in the particular project but low levels of influence.
Therefore, although by definition they are supportive, they are unlikely to be able to play a
significant role in supporting the implementation of the project outcomes. However, it has to be
kept in mind that the Subjects may become influential in a later stage by forming alliances with
other more influential Stakeholders. Subjects are often the marginal Stakeholders that may also be
considered ‘hard to reach’ and that might warrant special attention to secure their engagement and to
empower them to engage as equals in the Project with more influential Stakeholders.

The crowd are Stakeholders who have little interest or influence on the outcomes of the particular
14
project and though there is little need to consider them in much detail or to engage with them.
 However, it has to be kept in mind that, as with the case of Subjects, the influence or the interest of
the Crowd may change with time.

Finally, it should be noted that all methods for identifying Stakeholders provide a snap-shot in time,
Stakeholders’ interests and influence. This means that Stakeholder mapping exercises should be
revisited and updated periodically to ensure that the needs and priorities of all Stakeholders
continue to be captured.
3.3. STEP 3: DEVELOP AN ENGAGEMENT PLAN

Now when the Stakeholders are identified and mapped, the Stakeholder engagement plan should
be developed. The engagement should be structured in a way that enables the perspectives of the
diverse Stakeholders to be considered. To develop a proper engagement plan, the possible
engagement approaches and techniques for the engagement are discussed thoroughly in the
following sections.

3.3.1. SELECTING AN ENGAGEMENT APPROACH

Based on the mapping exercise, there are several groups of Stakeholders defined. It is not practical
nor smart to engage all identified Stakeholder groups on the same level of intensity, using the same
approach. It is important to be highly selective in choosing Stakeholders for ongoing consultation
and collaboration because being strategic and clear about whom to engaging with — and why —
can help save both time and money. Even more important, it will help better manage the
expectations of the Stakeholders. When Stakeholder groups are consulted and express opinions,
only to find no action taken, can significantly undermine the perceived value of the exercise and
negatively impact trust and reputation.

Moreover, the resources at the disposal of the Project Partner also shape the choice of engagement
approach. For example, a more ambitious strategy costs more.

There are altogether six approaches for the Stakeholder engagement (see Table 2 below). The
engagement approaches are listed based on their resource consumption4.

Table 2. Approaches for the Stakeholder Engagement

Engagement Overview Example Resources
approach
Tracking or monitoring Stakeholder Tracking the issues of greatest €
MONITOR positions via research or discussion concern of selected
with other parties Stakeholder groups
Adapting communications scope Creating and targeting €
MESSAGE and messaging to meet Stakeholder messages to specific
expectations Stakeholders
Activities to enlist support for a Clarification of a position of€€
ADVOCATE specific effort or position that may the Project Partner in
have opposition or reflect an actual response to Stakeholder
or perceived imbalance of power criticism
Soliciting explicit feedback or Consultation with a €€€
input on a project. Implies an Stakeholder advisory board
CONSULT expectation by the Stakeholders that on policy or process changes
the Project Partner will make regarding the projects
concrete changes approach to a particular issue
based on the consultation

15
 Initiating or participating in two- Consultation with local €€€€
way dialogue focused on mutual community and political
COLLABORA learning and solutions. Can include groups to determine the most
TE co-creation of new ideas and mutually beneficial options
approaches
INNOVATE Shared work on common objectives Launch of a new product or €€€€€
of the project and its Stakeholders. service in partnership with
Can include co-creation, as well as expert Stakeholders
co-implementation, of new ideas

On Figure 3 are brought out the proposed engagement approaches for each quadrant. If used
effectively, this tool helps to plan the activities based on the level of support the various
Stakeholders are likely to provide and to prioritise efforts in engaging the Stakeholders, as
appropriate to the needs of the project.

MESSAGE CONSULT, COLLABORATE,

High Keep them satisfied INNOVATE
(moderate priority; Keep them fully engaged
keep them sufficiently involved) (highest priority;
manage through active engagement)

MONITOR ADVOCATE
Level of influence

Provide minimum effort Keep them informed

Low (lowest priority; (moderate priority;
don’t overload them with objective is to sustain their interest
communication) and leverage when useful for the
project)
Low High
Level of interest

Figure 3. The proposed engagement approach to consider in planning Stakeholder engagement

(adaption from Mendelow’s power-interest matrix)
3.3.2. FINDING THE TECHNIQUE
The previous steps – setting the goals, mapping the Stakeholders and finding the approach - have
all led to the final step of preparation – identifying the technique that matches the engagement
approach and level of ambition of the Stakeholder engagement. Table 3 presents the techniques
suitable for the chosen approach. Based on this table the relevant techniques for engaging specific
Stakeholders or Stakeholder groups can be identified. By using a range of techniques, various
stakeholders can be engaged. Also, the Project Partners are not limited to using one engagement
technique at a time.
Table 3. Techniques based on chosen approach

APPROACH TECHNIQUE5

=> Joint venture or partnership

INNOVATE External advisory council
COLLABORATE Collaboration workshop
CONSULT Joint research
Stakeholder engagement summit
Focus groups
Workshop

=> Sustainability report

16
Survey/Questionnaire
 MESSAGE Town hall meeting
ADVOCATE Mass e-mail or newsletter
Social media outreach
Conference
Focus groups
=>
Marketing campaign and tracking
MONITOR Online and social media monitoring
Subscription to Stakeholder newsletter or blog

However, the art of Stakeholder engagement does not actually lie in which technique is chosen, but
in how well the technique is matched to the issue, Stakeholder(s), and situation. To better choose
the technique, the following questions should be considered:

- Familiarity: How well do you know the issue and the Stakeholder(s) involved? What has
the relationship been in the past? What research and pre-work has been done already?
- Frequency: Is this one meeting, multiple meetings, or an ongoing dialogue with no
defined end?
- Guidance/Facilitation: Will the engagement be managed directly by the Project Partner or
will it be facilitated by a third party?
- Participant Profile: Does the engagement involve one representative, many from the
same organizations, or representatives from many different organizations? Are these senior
decisionmakers, impacted or concerned citizens, potential plaintiffs, etc.?
- Complexity: Does the engagement involve one issue or multiple issues? What is the level
of seriousness, potential impacts, etc.?
- Trust/Credibility: How much trust exists between the Project Partner and
Stakeholder(s)?
What credibility does each have with the other?

For example, if the chosen technique is a verbal exchange with Stakeholders, the pros and cons of
various types of conversations should be taken into the consideration. Decide which approach best
matches the objectives of the engagement, including online discussions, teleconferences, webinars,
one-on-one meetings, or group meetings, forums, or events.

In choosing several techniques, consider how certain elements influence the intended engagement
and might change the conversation. Think about the selected Stakeholder groups, and attempt
to
anticipate their perceptions of the criteria that follow below. Then adjust the plans, where
necessary. While the stakes are particularly high for in-person meetings, these considerations apply
broadly.

In choosing the technique is necessary to provide so that everyone is to feel that their interests are
included. This creates the feeling of ownership about the outcomes of the project and though
increases the interest of Stakeholders to provide for the project. The successful completion of a
project usually depends on how the Stakeholders view it. Their requirements, expectations,
perceptions, personal agendas and concerns will influence the project, shape what success looks
like, and impact the outcomes that can be achieved.

The project Inter Ventures has already described meetings as one of the compulsory methods of
Stakeholder engagement. However, the techniques to carry through these meetings is left to decide
for the Project Partners. The compulsory meetings held within the project Inter Ventures and
proposed techniques are brought out in Table 4 below.

17
Table 4. Compulsory Stakeholder meetings determined by the project Inter Ventures and
proposed techniques
Stage Meeting Aim of the meeting Participants Techniques
To introduce the
project,
disseminate learnings on the
evolution of border region Project Partner
A kick-off SME ecosystems, and RSG Workshop
meeting select participants of members
forthcoming interregional
Period 1 events
To provide for the Regional Project
Situation Analyse in each Partner,
region -
a moderated regional AEBR,
situation
Regional and needs analysis event forRSG
RSG members,
Situation members, combining online Internal and Workshop
Analyse lectures and Q&A sessions external Brainstorming
held
Webinar by AEBR; on-site discussion experts of the Focus Groups
and
group work moderated by Project
internal and external experts of Partners
PPs
To discuss the lesson learnt in
Follow up RSG the two Thematic Study Project Workshop Word
Period 2 meeting Visits, review the Thematic Partners and Café
Portfolios, analyse the RSG members
applicable best
practicies and knowledge
To inform Stakeholders on the
First regional process, discuss aspirations, Project
Period 3 Stakeholder review applicable good Partners, RSG Workshop Focus
Workshop practices of the regional members Groups
Applicability Report, and and PI owners
identify potential
interim policy improvements
To discuss the draft actions
and
sustainability issues proposed Project
by
3rd Interregional Meeting; as Partner, RSG
well
RSG Action as hold moderated action members,
Period 4 Planning planning workshop. The AEBR, Workshop
webinar
Webinars will contain online lectures Internal and
and
Q&A sessions held by AEBR external
and
on-site discussion and groupexperts of the
work
moderated by thematic internal Project
and external experts
18 of PPs Partners
 To monitor the
implementation
of Regional Policy Project
Regional Recommendations prepared Partners, RSG Workshop
Policy by
Workshops the previous round of Regional members
Policy Workshops in Period 3 and PI owners

However, apart from the compulsory meetings, we strongly recommend further events to be
included in the planning in order to have a regular contact with Stakeholders.

There is an abundance of participatory techniques that can be used in the meetings in addition to
those brought out in the Table above. The list below includes some of the participatory techniques:
- Problem tree analysis: it is a pictorial representation of a problem, its causes and its
consequences. Both causes and consequences are fitted into the diagram on a hierarchical
preference basis.
- Speed geeking: to quickly view a number of presentations within a fixed period of time
- round table,
- Birds of a feather: meetings with members interested in a particular issue. They carry out
discussions without any planned agenda
- Dotmocracy (dot-voting): participants vote on their chosen options using a limited
number ofstickers or marks with pen
- Fishbowl: a form of a dialogue which can be used when discussing topics within large
groups.
The advantage is that it allows the entire group to participate in a conversation

Logistics are an important aspect of planning the Stakeholder engagement. As follows we provide
an illustrative list with points to cover to help with organizing the event:
- Develop an agenda focused on objectives and outcomes (see also Annex 5.1)
- Develop rules of engagement, confidentiality, and a decision-making process
- Create evaluation criteria and measures for success
- Develop a feedback plan and mechanism (see also Annex 5.3)
- Set up channels of ongoing communication (Twitter feed, voting platform, white boards)
- Determine if facilitation is needed, and select a facilitator
- Secure an appropriate facility (if necessary)
- Distribute invitations with practical information and meeting agenda well in advance to
participants
- Plan for catering, paying attention to special needs or diets
- Create engagement materials
- Communicate clear objectives, scope, and roles for participants
- Assign participants roles and responsibilities
- Decide on how photos are taken
- Who takes the minutes (see also Annex 5.4)
- Prepare Attendance sheets (see also Annex 5.2)
- Agree upon specific dissemination rules
3.4. STEP 4: IMPLEMENT ENGAGEMENT PLAN
There are several aspects to keep in mind during the implementation phase.

INFORMING
It is necessary to inform the Stakeholders in advance about the project and the possibilities to
participate in the project. In communicating the project to the Stakeholders, it must be kept in mind
that different Stakeholder groups require a different approach in communication. However,
the proper invitation to a Stakeholder should include the following:
- the purpose and scope of the engagement;
19
- the engagement process and the expected timelines;
 - what the Stakeholder is expected to contribute;
- logistical and practical information about the engagement process.

Moreover, the invitations to the Stakeholders should be personal and not generic. Different
factors should be considered in order to find the most effective means. Examples of methods
currently used are social networks, media, mailing lists, telephone calls and personal visits.

FACILITATION
For a successful engagement with the Stakeholders facilitation truly counts. To benefit most from
the Stakeholder engagement focus on the following points:
- Help Stakeholders to prepare: make sure that everyone who joins in is aware of the
goals, format, envisaged contribution, and any useful background information so the discussion
will be as productive as possible
- Share Stakeholder expectations: share feedback from the earlier goal-setting
consultation process, or invite Stakeholders to share their expectations for the engagement
- Allow for equal contribution: encourage less-vocal Stakeholders to participate in the
conversation; create a space in which this is possible and comfortable; respect each party’s right to
observe quietly if they choose
- Focus the discussion: dialogues can veer off-topic if not properly focused. Stick to the
agenda
and remain within the issue’s scope
- Manage cultural dynamics: be wary of potential cultural misunderstandings and be
prepared to manage any that arise
- Mitigate tension: certain topics can prove controversial or provocative, and unexpected
dynamics or rivalries may surface among participants. Thorough mapping and preparation will help,
but anticipating a range of outcomes is essential

In implementing the Stakeholder Engagement Plan, it has to be kept in mind that there are
expected two outcomes from this exercise within the project Inter Ventures. Firstly, based on the
results from Stakeholder engagement process, the project Inter Ventures will identify success
criteria and capacity development needs of SMEs’ to promote their integration into international
production and innovation chains and interregional value creation. Secondly, the shortages and
development opportunities of institutional capacities, cooperation structures and SME support
schemes for boosting internationalisation in targeted border regions will be identified.

DOCUMENT THE ENGAGEMENT

In order to measure success and build for future activities, the following should be put in writing
during the engagement: the purpose and aims of the engagement; the methods used; the
participants; a summary of noted Stakeholder concerns, expectations, and perceptions; a summary
of discussions; and a robust list of outputs (decisions, actions, proposals, and recommendations).
This documentary record should be shared with all participants.
3.5. STEP 5: ASSESS THE ENGAGEMENT PROCESS
At the end of each cycle of the Stakeholder engagement process, the whole situation and its
outputs should be analysed, as well as the reasons of the chosen decisions and actions should be
defined. Assessment of the Stakeholder engagement process is necessary to ensure that the chosen
approach is successful. One of the tools to prepare the assessment of the Stakeholder engagement
process is the Evaluation Form (see Annex 5.3.) that will be filled in by each Stakeholder after
every event. These Evaluation Forms should be analysed to assess the Stakeholder engagement
process.

The outcome of Evaluation Form analysis provides input for the following:
- achievement of objectives and expected results;
- effectiveness of allocated resources and means (e.g. budget and expertise);
- internal and external acceptance of outcomes.
20
The assessment report should include the following assessments:
 - commitment and integration;
- purpose, scope and Stakeholder participation;
- process (planning, preparing, engaging, reviewing and improving);
- outputs and outcomes;
- reporting.

To facilitate the process, a list of indicators should be created for the sake of comparison
with previously defined objectives. The proposed indicators are presented in Table 5 below.

Table 5. Proposed indicators to measure the Stakeholder engagement process]

Assessment Proposed indicator
Commitment and integration Planned Stakeholder commitment (how much they provide
input
to the process) versus actual Stakeholder commitment
Purpose, scope and Planned number of participants versus the actual number
Stakeholder participation of
participants
Process Planned process versus actual process
Outputs and outcomes Planned outputs versus actual outputs
Reporting Planned reporting versus actual reporting
3.6. STEP 6: REACT TO ENGAGEMENT RESULTS

Organizations often conduct Stakeholder engagements and then fail to document the results and act
transparently on the information gained through the exchanges. This step – reacting to engagement
results – means that based on the assessment conducted on Step 5, the adopted Stakeholder
engagement Plan should be revised and improvements should be made into the plan where
needed. This applies to each individual engagement. For ongoing, repeated interactions, the action
plan from one engagement should directly inform the planning and execution of the next.

CREATE AN OVERVIEW
Refer back to the written engagement notes and consider the entire range of issues that came up
during the Stakeholder engagement. For each issue, prepare a response that explains the rationale
behind the decision or next step — especially if the response is to take no action.

BUILD A PLAN
The overview is a foundation for the new action plan. For each potential next step, the concerns
and perceptions stakeholders expressed during the engagement, as well as key discussion points
should be considered. Each action should define roles and responsibilities for implementation,
along with milestones and a realistic timeline for completion.
3.7. STEP 7: MEASURE AND REPORT PROGRESS

As a last step, the follow up on the Stakeholder engagement Plan, created in Step 6 should also
be used as a progress report on goals and objectives. Think back to the original objectives and
ambition. Use what was learned from the engagement to address the short-term or long-term goals
that have been previously set. Incorporate successes into the Action Plan and analyse any
misses or failures to help to set more realistic goals in the future.
The measuring and reporting of results of every engagement activity have the following benefits:
- Increased trust and confidence across the project community;
- Increased certainty and pace of progress;
- Clearer understanding of remaining resistance;
- More robust risk management;
- Sustainability compliance management;
- Market development;
- Innovation;
- Strategy improvement. 21
 However, not measuring and reporting the progress may have the following risks:
- Uncertainty of outcome;
- Likelihood of reactive planning;
- Emotional ineptness;
- Diversion and distraction of resources;
- Silo thinking, factions and division amongst all levels: individual, group, organisational;
- Unprofessional and unethical behaviours.

In this stage, an ongoing engagement to tackle strategic or systemic issues of high value to the
organization should be considered. It is good practice to maintain ongoing engagement, for
example via Stakeholder panels and advisory boards. Here are some key considerations before
establishing a more formal, ongoing Stakeholder engagement mechanism:
- Develop a clear mandate: there are many reasons to bring Stakeholders together on a
regular basis, from providing strategic input to co-creating a new initiative. The point is to select
one and then use it to guide the entire process, including the establishment of a mutual
understanding as to how the feedback will be used
- Composition: for an ongoing advisory function, trade-offs must be made in terms of
breadth and depth on issues, as well as the diversity of the country of origin, gender, opinion, and
expertise. A clear mandate will help to select the right balance
- Payment: if you seek an ongoing commitment from Stakeholders, financial compensation
will quickly become a consideration. Common practice includes paying honoraria and travel
arrangements6. Whatever approach is adopted, transparency is key.
- Confidentiality and disclosure: there should be clear guidelines for confidentiality and
the sharing of decisions and key discussion points. Compelling and conflicting arguments for
confidentiality and for transparent disclosure may be encountered. Pick the one that makes the
most sense, and stick to the agreed procedures.
- Effectiveness: term limits for panelists can foster the evolution and diversity of
perspectives.
Panel members should be reviewed regularly for effectiveness - at least annually.

Finally, communication with Stakeholders as transparently as possible is the key. From the
Action Plan, build a public reporting document that tells the whole story and can be tailored to
specific audiences. Use this opportunity to demonstrate how the engagement activities and
Stakeholders affect the project — and their lives. Finally, be sure to invite further Stakeholder
feedback to improve the engagement strategy in future.
3. CONLUSION
A successful Stakeholder engagement process is a vital requirement to achieve the required outputs
of the project. The aim of the project Inter Ventures is to promote the internationalization of
SMEs in EU border regions, thus contributing to their growth and increased competitiveness.
On the regional level, the aim of the project is to change the targeted policy instrument. Though,
the Stakeholder engagement in this project is necessary to support this policy influencing.

This guide about Stakeholder engagement has been designed by the Association of the European
Border Regions (AEBR) to support the project Inter Ventures approach on internationalization of
SMEs in cross-border areas by providing a tool to Project Partners to better understand what is a
Stakeholder, why it is necessary to involve Stakeholders, what would the Project Partners gain
from these Stakeholders while pursuing the objectives of the project Inter Ventures, and finally,
how to engage / to interact with the Stakeholders.

This guide introduced the 7 steps of an effective Stakeholder engagement process:

1. setting engagement objectives;
2. identifying and assessing stakeholders;
3. developing engagement plan and techniques;
4. implementation of engagement plan; 22
5. assessment of the engagement process;
 6. responding to the engagement results;
7. measuring and reporting progress.

By following these seven steps, Project Partners can ensure a successful Stakeholder engagement
and so achieve the planned project outcomes. The latter is because through a proper Stakeholder
engagement, the Stakeholders are more likely to feel ownership over the project and are therefore
more likely to assist the Project Partners and help to implement project recommendations.

Overview of Agile Development Models-Scrum, Extreme Programming,

Feature driven development, Crystal, Kanban and Lean Software Development

Agile Methodologies
Dynamic System Development Methodology DSDM
It is an agile framework for software projects. It was used to fine-tune the traditional
approaches. The most recent version of DSDM is called DSDM Atern. The name Atern
is a short for Arctic Tern - a seabird that can travel vast distances that represents many
features of the method which are natural ways of working such as prioritization and
collaboration.

Scrum
It is the most popular agile framework, which concentrates particularly on how to manage
tasks within a team-based development environment. Scrum uses iterative and
incremental development model, with shorter duration of iterations. Scrum is relatively
simple to implementand focuses on quick and frequent deliveries.

Extreme Programming XP
It is a type of agile software development. It advocates frequent releases in short
development cycles, which is intended to improve productivity and introduce checkpoints
where new customer requirements can be adopted. The methodology takes its name from
the idea that the beneficial elements of traditional software engineering practices are
taken to extreme levels.
ExtremeProgrammingisasoftware − developmentdisciplinethatorganizespeopletoproducehigher −
qualitysoftwaremoreproductively. XP addresses the analysis, development, and test phases
with novel approaches that make a substantial difference to the quality of the end-
product.

Test-driven Development TDD

It is a software development process that relies on the repetition of a very short
development cycle: first the developer writes an automated test case that defines a
desired improvement or a new function, then it produces the least amount of code to pass
that test, and finally brings the new code to acceptable standards.

Lean
It is a production practice that considers the expenditure of resources for any goal other
than the creation of value for the end-customer to be wasteful, and thus a target for
elimination. Working from the perspective of the customer who consumes a product or
service, the term value is defined as any action or process that a customer would be
willing to pay for. Lean is centered on preserving value with less work.

Kanban
It is a system to improve and keep up a high level of production. Kanban is one
method through which Just-In-Time JIT, the strategy the organizations employ to
control the inventory expenses, is achieved. Kanban became an effective tool in support
of running a production system as a whole, and it proved to be an excellent way for
promoting improvement. 23
Conclusion
Over the last 10 years, there is an ever-increasing volume of success stories, where
companies have dramatically improved the success and performance of their IT
development teams and projects with agile practices. This has caused agile to be widely
adopted across a variety of industries, including media and technology, large corporates,
and even government.
 Agile Framework helps teams to benefit from: Faster Time to Deliver/ Market
 Reduce Uncertainty and Risk
 Increase Return on Investment ROI by focusing on Customer Value
Among these different agile methodologies, Scrum has proved to be extremely
successful worldwide over the last 20 years.

Scrum is a framework for developing and sustaining complex products. Ken Schwaber
and JeffSutherland developed Scrum. Together, they stand behind the Scrum Rules.
Scrum Definition
Scrum is a framework within which people can address complex adaptive problems,
whileproductively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product
development since the early 1990s. Scrum is not a process or a technique for building
products; rather, it is a framework within which you can employ various processes and
techniques. Scrum makes clear the relative efficacy of your product management and
development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules. Each component within the framework serves a specific purpose and
is essential to Scrum’ssuccess and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the
relationships and interaction between them. The rules of Scrum are described throughout
this tutorial.
Note - Across the industry, there are misconceptions that Scrum means no
documentation, scrum team consists of only developers, and so on. It is not entirely so;
we will give clarifications on thesein later sections.
Scrum Process Framework
Scrum is a framework for developing and sustaining complex products. Ken Schwaber
and JeffSutherland developed Scrum. Together, they stand behind the Scrum Rules.
Scrum Definition
Scrum is a framework within which people can address complex adaptive problems,
whileproductively and creatively delivering products of the highest possible value.
Scrum is a process framework that has been used to manage complex product
development since the early 1990s. Scrum is not a process or a technique for building
products; rather, it is a framework within which you can employ various processes and
techniques. Scrum makes clear the relative efficacy of your product management and
development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events,
artifacts, and rules. Each component within the framework serves a specific purpose and
is essential to Scrum’ssuccess and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the
relationships and interaction between them. The rules of Scrum are described throughout
this tutorial.
Note - Across the industry, there are misconceptions that Scrum means no
documentation, scrum team consists of only developers, and so on. It is not entirely so;
we will give clarifications on thesein later sections.

24
Scrum Process Framework

In Scrum, the prescribed events are used to create regularity. All events are time-boxed
events, such that every event has a maximum duration. The events are described more
elaborately in thesubsequent chapters.

Sprint
The heart of Scrum is a Sprint, a time-box of two weeks or one month during which a
potentially releasable product increment is created. A new Sprint starts immediately after
the conclusion of the previous Sprint. Sprints consist of the Sprint planning, daily
scrums, the development work, theSprint review, and the Sprint retrospective.
 In Sprint planning, the work to be performed in the Sprint is planned collaboratively
by theScrum Team.
 The Daily Scrum Meeting is a 15-minute time-boxed event for the Scrum Team to
synchronize the activities and create a plan for that day.
 A Sprint Review is held at the end of the Sprint to inspect the Increment and make
changes to the Product Backlog, if needed.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. In this meeting, the Scrum Team is to inspect itself and create a plan for
improvements to be enacted during the subsequent Sprint.
Conclusion
Scrum is a process framework that defines certain rules, events, and roles to bring in
regularity. However, it can be adapted to any organization, based on needs, provided the
basic scrum rulesare not violated.

The Scrum Team consists of three roles, namely a ScrumMaster, a Product Owner, and
the Team.
ScrumMaster
The ScrumMaster some times written as the ScrumMaster, although the official term has no
space after “Scrum” is the keeper of the scrum process. He/she is responsible for-making
the process run smoothly removing obstacles that impact productivity organizing and
facilitating the critical meetings.
Product Owner
The Product Owner is responsible for maximizing the value of the product and the work
of the Team. How this is done may vary widely across organizations, Scrum Teams,
and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog.
ProductBacklog management includes-
Expressing Product Backlog items clearly.
Ordering the Product Backlog items to best achieve goals and missions. Optimizing the
25
value of the work the Team performs.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows
what theTeam will work on further.
Ensuring that the Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Team do it. However, the
Product Ownerremains accountable for these tasks.
The Product Owner is one person, not a committee. The Product Owner may represent
the desires of a committee in the Product Backlog, but those wanting to change a
Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her
decisions. The Product Owner’s decisions are visible in the content and ordering of the
Product Backlog. No one is allowed to tell the Team to work from a different set of
requirements, and the Team is not allowed to act on what anyone else says. This is
ensured by ScrumMaster.
The Team
The Team is self-organizing and cross-functional. That means the team comprises of
analysts, designers, developers, testers, etc. as appropriate and as relevant to the project.
Some people in the industry refer to this team as development team. However, such a
reference is leading to controversy that the team can have only developers and no
other roles. It is an obvious understanding that it is only a misconception. To develop a
software product, we require all the roles and that is the essence of scrum – the team will
function in collaboration. Cross-functional teams have all competencies needed to
accomplish the work without depending on others not part of the team, and thus time
and effort can be saved. The team model in Scrum is designed to optimize flexibility,
creativity, and productivity.
Optimal Team size is small enough to remain nimble and large enough to complete
significant work within a Sprint. The Team size should be kept in the range from five to
nine people, if possible. Fewer than five team members decrease interaction and results in
smaller productivity gains. Having more than nine members requires too much
coordination.
The scrum team works together closely, on a daily basis, to ensure the smooth flow of
information and the quick resolution of issues. The scrum team delivers product iteratively
and incrementally, maximizing opportunities for feedback. Incremental deliveries of a
complete product ensure a potentially useful version of working product is always
available.

ScrumMaster is a trained responsible person, who renders services as described below

-
Scrum Master Services to the Product Owner
The ScrumMaster serves the Product Owner in several ways, including -
 Finding techniques for effective Product Backlog management.
 Helping the Scrum Team understand the need for clear and concise Product
Backlog items.
 Understanding product planning in an empirical environment.
 Ensuring that the Product Owner knows how to arrange the Product Backlog to
maximizevalue.
 Understanding and practicing agility.
 Facilitating Scrum events as needed.
ScrumMaster Services to the Scrum Team
The ScrumMaster serves the Scrum Team in several ways, including
 Coaching the Scrum Team in self-organization and cross-functionality.
 Helping the Scrum Team to create high-value products.
 Removing impediments to the Scrum Team’s progress.
 Facilitating Scrum events as requested or needed.
 Coaching the Scrum Team in organizational environments in which Scrum is not
yet fully adopted and understood.
26
ScrumMaster Services to the Organization
The ScrumMaster serves the organization in several ways, including-
 Leading and coaching the organization in its Scrum adoption.
 Planning Scrum implementations within the organization.
 Helping employees and stakeholders understand and enact Scrum and empirical
productdevelopment.
 Causing change that increases the productivity of the Scrum Team.
 Working with other ScrumMasters to increase the effectiveness of the application of
Scrum inthe organization.
Conclusion
Scrum is a process framework that defines certain rules, events, and roles to bring in
regularity. However, it can be adapted to any organization, based on needs, provided the
basic scrum rulesare not violated.

Scrum Process Framework can be viewed by means of a sequence of events and the
corresponding artifacts. The Scrum events are time-boxed events. That means, in a
project, every scrum event has a predefined maximum duration. These events enable
transparency on the project progress to all who are involved in the project. The vital
events of scrum are-
 The Sprint Sprint
 Planning
 Daily Scrum Meetings
 The Sprint Review
 The Sprint Retrospective
The Sprint
During a Sprint, a working product Increment is developed. It is usually of duration two
weeks or one month, and this duration remains constant for all the sprints in the project. We
cannot have varying durations for the different sprints in a project. A new Sprint starts
immediately after the conclusion of the previous Sprint. The Sprint Goal is an objective set for the
Sprint. It provides guidance to the Team on why it is building the Increment. It is created during
the Sprint Planning meeting. The scope of the sprint is clarified and re-negotiated between the
Product Owner and the Team as more about the requirements is learned. Thus, each Sprint is
associated with it, a definition of what is to be built, a design, and the flexible plan that will guide
building it, the development work, and the resultant product increment. A Sprint should be
cancelled if the Sprint Goal becomes obsolete. This might occur if the organization changes
direction or if market or technology conditions change. A sprint can be cancelled only by product
owner, though others have an influence on the same. Due to the short duration nature of Sprints,
cancellation during a sprint rarely makes sense. As the sprint cancellations consume resources, for
getting re-organized into another Sprint, they are very uncommon. If a Sprint is cancelled, and part
of the work produced during the sprint is potentially releasable, the Product Owner typically
accepts it. All the incomplete Sprint Backlog Items are put back into the Product Backlog. Sprint
Planning The work to be performed in the Sprint is planned in the Sprint Planning Meeting. Sprint
Planning Meeting is of duration of maximum of four hours for two weeks sprints and eight hours
for one month Sprints. It is the responsibility of the Scrum Master to ensure that the meeting takes
place and that all the required attendees are present and understand the purpose of the scheduled
meeting. The Scrum Master moderates the meeting to monitor the sustenance of discussion and
closure on time. Sprint Planning focuses on the following two questions - What needs to be and
can be delivered in the Sprint Increment? How will the work needed for the execution of Sprint be
achieved?
The inputs to this meeting are-
 The Product Backlog
 The latest product Increment
 Projected capacity of the Team during the Sprint
 Past performance of the Team
The Scrum Team discusses the functionality that can be developed during the Sprint.
Product Owner provides clarifications on the Product Backlog items. The team selects the items
27
from the Product Backlog for the Sprint, as they are the best to assess what they can accomplish in
the Sprint. The Team comprises of analysts, designers, developers, and testers. The work is carried
out in a collaborative fashion, thus minimizing re-work.
The Scrum Team then comes up with Sprint Goal. The Sprint Goal is an objective that
provides guidance to the Team on why it is building the Product Increment. The Team then
decides how it will build the selected functionality into a working product Increment during the
Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is
called the Sprint Backlog.
Work during a sprint is estimated during sprint planning and may be of varying size and/or
effort. By the end of the Sprint Planning meeting, the work is divided into tasks of duration of one
day or less. This is to enable the ease of work allocation, and tracking the completion. If the Team
realizes that it has too much or too little work, it can renegotiate the selected Product Backlog
items with the Product Owner. The Team may also invite others not part of Scrum Team to attend
the Sprint Planning meeting to obtain technical or domain advice or help in estimation.
Daily Scrum Meetings
The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted daily
to quickly understand the work since the last Daily Scrum Meeting and create a plan
for the next 24 hours.This meeting is also referred to as Daily Stand up Meeting.
The Daily Scrum Meeting is held at the same time and same place every day to reduce
complexity.During the meeting, each Team member explains -
 What did he do yesterday that helped the Team meet the Sprint Goal?
 What will he do today to help the Team meet the Sprint Goal?
 Does he see any impediments that prevent him or the Team from meeting the
Sprint Goal?
Daily Scrum is mistaken to be a status tracking event, though, in fact, it is a planning
event.The input to the meeting should be how the team is doing toward meeting the
Sprint Goal, and the output should be a new or revised plan that optimizes the team’s
efforts in meeting the Sprint Goal.Though the Scrum Master coordinates the Daily Scrum
Meeting and ensures that the objectives of the meeting are met, the Meeting is the
responsibility of the Team.If necessary, the Team may meet immediately after the Daily
Scrum Meeting, for any detaileddiscussions, or to re-plan the rest of the Sprint’s work.
Following are the benefits of Daily Scrum Meetings -
 Improve communication within the Team.
 Identify impediments, if any, in order to facilitate an early removal of the same, so as
tominimize impact on the Sprint.
 Highlight and promote quick decision-making.
 Improve the Team’s level of knowledge.
Sprint Review
A Sprint Review is held at the end of every Sprint. During the Sprint Review, a
presentation of the increment that is getting released is reviewed. In this meeting, the
Scrum Team and the stakeholders collaborate to understand what was done in the Sprint.
Based on that, and any changes to the Product Backlog during the Sprint, the attendees
arrive at the next steps required that could optimize value. Thus, the objective of Sprint
Review is to obtain feedback and progress unitedly.
The Sprint Review is normally held for two hours for two week sprints and for four
hours for onemonth sprints.
The Scrum Master ensures that -
 The meeting takes place.
 The participants understand the purpose.
 The meeting is focused on the required agenda and is completed within the
requiredduration.
The Sprint Review includes the following aspects -
 Attendees include the Scrum Team and key stakeholders, as invited by the Product
Owner.
 The Product Owner explains what Product Backlog items have been completed
during the sprint and what has not been completed.
28
 The Team discusses what went well during the Sprint, what problems it ran into, and
howthose problems were solved.
 The Team demonstrates the work that it has completed and answers questions, if
any, about the Increment.
 The entire group then discusses on what to do next. Thus, the Sprint Review
providesvaluable input to Sprint Planning of the subsequent Sprint.
 The Scrum Team then reviews the timeline, budget, potential capabilities, and
marketplace for the next anticipated release of the product increment.
 The outcome of the Sprint Review is an updated Product Backlog, which defines the
probableProduct Backlog items for the next Sprint.
Sprint Retrospective
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint
Planning. This is usually a one hour meeting for two-week duration sprints and a three
hour meeting for one month duration Sprints.
The purpose of the Sprint Retrospective is to -
 Combine the learnings from the last Sprint, with regards to people, relationships,
process, and tools.
 Identify the major items that went well and potential improvements.
 Creation of a plan for implementing improvements to increase product quality.
The Sprint Retrospective is an opportunity for the Scrum Team to introspect and
improve within the Scrum process framework so as to make the next Sprint outcome
more effective.
Reference
Scrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.

Scrum Artifacts provide key information that the Scrum Team and the stakeholders need
to be aware of for understanding the product under development, the activities done, and
the activities being planned in the project. The following artifacts are defined in Scrum
Process Framework -
 Product Backlog
 Sprint Backlog
 Burn-Down Chart
 Increment
These are the minimum required artifacts in a scrum project and project artifacts are not
limitedby these.
Product Backlog
The Product Backlog is an ordered list of features that are needed as part of the end
product and it is the single source of requirements for any changes to be made to the
product.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases. Product Backlog
items have the attributes of a description, order, estimate, and value. These items are
normally termed as User Stories. The Product Owner is responsible for the Product
Backlog, including its content, availability, and ordering.
A Product Backlog is an evolving artifact. The earliest version of it may contain only the
initially known and best understood requirements. The Product Backlog gets developed
as the product, and the environment in which it will be used, progress. The Product
Backlog constantly changes to incorporate what is required to make it effective. As long
as a product exists, its Product Backlog also exists.
As the product being built is used and gains value, the Product Backlog becomes a
larger and more exhaustive list. Changes in business requirements, market conditions,
or technology, cause changes in the Product Backlog, making it a live artifact.

29
Product Backlog refinement means adding detail, estimates, and priority order to the
Product Backlog items. This is an ongoing process performed by the Product Owner
and the Team. TheScrum Team decides how and when refinement is to be done.
Product Backlog items can be updated at any time by the Product Owner or at the
Product Owner’sdiscretion.
Higher-ordered Product Backlog items are usually clearer and more detailed than
lower-ordered ones. More precise estimates are made based on the greater clarity and
increased detail. The lower the order, the lesser is the detail.
Product Backlog items that may likely be the candidate requirements for the upcoming
Sprint are refined so that these items can be developed during the Sprint. Product Backlog
items that can be developed by the Team within one Sprint are deemed to be ready for
selection in a Sprint planning meeting.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a
plan for delivering the product Increment and realizing the Sprint Goal.
The Sprint Backlog is a forecast by the Team about what functionality will be made
available in the next Increment and the work needed to deliver that functionality as a
working product Increment.
The Sprint Backlog is a plan with enough detail that can be understood but the Team to
track in the Daily Scrum. The Team modifies the Sprint Backlog throughout the Sprint,
and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Team
works through the plan and learns more about the work needed to achieve the Sprint
Goal.
As new work is required, the Team adds it to the Sprint Backlog. As work is performed
or completed, the estimated remaining work is updated. When elements of the plan are
deemed unnecessary, they are removed. Only the Team can change its Sprint Backlog
during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that
the Team plans to accomplish during the Sprint, and it belongs solely to the Team.
Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint
combined with the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be a working product, which means it must be in a useable condition. It
must be in working condition regardless of whether the Product Owner decides to actually
release it.
The Scrum Team needs to have consensus on what is considered to be an Increment.
This varies significantly per Scrum Team, but, team members must have a shared
understanding of what it means for work to be complete. This is used to assess when
work is complete on the product Increment.
The same understanding guides the Team in knowing how many Product Backlog
items it can select during a Sprint Planning. The purpose of each Sprint is to deliver
Increments of potentially releasable functionality.
Teams deliver an Increment of product functionality every Sprint. This Increment is
useable, so a Product Owner may choose to release it immediately. If the understanding
of an increment is part of the conventions, standards, or guidelines of the development
organization, all Scrum Teams must follow it as a minimum. If it is not a convention of
the development organization, the Scrum Team must define a definition of Increment
appropriate for the product.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that
all Increments work together.
As Scrum Teams mature, it is expected that their definitions of Increments expands to
include more stringent criteria for higher quality. Any one product should have a
definition of Increment that is a standard for any work done on it.
Sprint Burn-Down Chart
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed. The Team tracks this total work remaining for every Daily Scrum to project the
30
likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Team can manage its

31
progress.
Sprint Burn-Down Chart is a practice for trending the work expended by the Scrum Team.
This has been proven to be a useful technique in monitoring the Sprint progress towards the
Sprint Goal.
The Product Owner tracks this total work remaining at least every Sprint Review. The Product
Owner compares this amount with work remaining at previous Sprint Reviews to assess
progress toward completing the projected work by the desired time for the goal. This
information is sharedwith all stakeholders.
Conclusion
Scrum’s roles, events, artifacts, and rules are inevitable. If only some parts of Scrum are
implemented, the result is not Scrum. Scrum needs to be implemented in its entirety and
functionswell if aligned with other techniques, methodologies, and practices.
Reference
Scrum Guide © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved.

As you have understood, the User Stories are commonly used to describe the product features
andwill form part of the Scrum Artifacts – Product Backlog and Sprint Backlog.
User Stories
In software development, the product features play a crucial role. It is the features that the user
ultimately likes to use in the final product. They are known as Requirements in the general
terminology. The software development project success lies in understanding the user
requirements accurately and appropriately, and then implementing them in the final product.
Thus, requirements or product features need to be thoroughly known to the development
project team.
In 1999, Kent Beck came up with a term User Stories for the product features. He described
that a User Story is narrated from user perspective regarding what he or she wants to have
rather that what system can do for him. Thus, the view changed from product to user
completely and User Stories became de facto standard for Requirements in all Agile
frameworks.
In Scrum projects, the Product Backlog is a list of user stories. These User Stories are
prioritized and taken into the Sprint Backlog in the Sprint Planning Meeting.
Estimation is also based on user stories and the size of the product is estimated in User Story
Points.
The User Story Structure The User Story structure is as follows -As a <Type of User>,
I want <To Perform Some Task>,
So that <I can achieve some goal/benefit/value>.
Let us take a look at how a user story is framed for the scenario of a Bank Customer
withdrawingcash from ATM.

User Story: Customer’s Cash Withdrawal

As a Customer,
I want to withdraw cash from an ATM,
So that I don't have to wait in line at the Bank

User Story Acceptance Criteria

Each User Story also has Acceptance Criterion defined, so that correctness of implementation
of the user story is confirmed by passing the Acceptance Test that is based on the Acceptance
Criterion.
Following are the sample acceptance criterion for the example of User Story Customer’s
Withdrawal of Cash.
Acceptance Criterion 1:
Given that the account is creditworthy
 And the card is valid
 And the dispenser contains cash,
32
When the customer requests the cash
Then ensure the account is debited
 And ensure cash is dispensed
 And ensure the card is returned.
Acceptance Criterion 2:
Given that the account is overdrawn
 And the card is valid
When the customer requests the cash
Then ensure the rejection message is displayed
 And ensure cash is not dispensed
 And ensure the card is returned.
Writing User Stories
Product Owner is responsible for the Product Backlog and thus for the User Stories. However, it
does not mean that only product owner writes the user stories. Anyone in the Scrum Team can
write the user stories, and the activity can be spread across the project as requirements get
refined and new functionalities get added.
Non-Functional Requirements in User Stories
It is possible to incorporate the non-functional requirements also in the user stories. In the given
ATM example, the ATM to be available to the user 24X7, 365 days is a non-functional
requirement, which can be described by a use case.
Managing User Stories
User Stories are managed in the Product Backlog. The User Stories are ordered according to
priority. The most prioritized user stories are refined to granular level, while the least priority
user stories are kept at a lesser detail level. For every sprint, the most prioritized and hence more
granulated user stories are taken into the sprint backlog. If a user story is to be added to the
product backlog, its priority is first determined, and it is placed according to its place as per the
priority. The user stories can be reprioritized at any time. It is also possible to remove any of the
user stories if required.
Benefits with User Stories
 The major benefit of User Story lies in the user centric definition itself. This is because,
ultimately, it is the user who will be using the product in the relevant user scenarios. It
connects the end users to the team members.
 The syntax of the User Story itself ensures to capture the goal or benefit or value that the
user wants to achieve.
 Since the acceptance criteria forms part of user story itself, it will be an added advantage to
the Scrum Team.
 It is possible to make changes to a user story in course of the execution of the project. If the
scope of the user story becomes large, it needs to be split into smaller user stories. The
conditions in the acceptance criterion can also be changed.
 As working product increments are delivered to the users at the end of each sprint, the scrum
team can get feedback from the users in sprint review meeting. This enables incorporation of
feedback into the product continuously.
Conclusion
Scrum's User Stories bring the users closer to the Scrum team and prevents last-minute
surprises.

The sprint tracking is usually done using Burn-Down Chart. Burn-Down Chart shows the
remainingeffort in day-wise number of hours. For example, let us consider a 2-week sprint -
Sprint Duration: 2 Weeks No. of Days per Week: 5 No. of Hrs. per Day: 6 No. of
Resources: 6
Hence, total remaining effort at the beginning of sprint is 2*5*6*6 = 360 hrs.
Therefore, in an ideal scenario, 36 hours of work gets reduced in the remaining work and the
burn-down chart looks as follows -

33
If the sprint work is done as planned daily, the scrum progress is almost aligned to the ideal bar.
If the sprint work gets delayed and time commitment is not met, the burn-down chart looks as
follows -

But, as the burn-down chart is drawn daily, and the slippage is known early, corrective actions
can be taken to meet the sprint time line. Suppose, the team stretches to meet the timeline, the
burn- down chart looks as follows-

Thus, at any point in time in a Sprint, the total work remaining in the Sprint can be visualized
andpossibility of meeting sprint timeline can be improved.
Conclusion
Burn-down charts aid the Scrum team to keep track of their progress and what needs to be done
tomeet the sprint goal.
34
In Scrum Projects, Estimation is done by the entire team during Sprint Planning Meeting. The
objective of the Estimation would be to consider the User Stories for the Sprint by Priority and
bythe Ability of the team to deliver during the Time Box of the Sprint.
Product Owner ensures that the prioritized User Stories are clear, can be subjected to estimation,
and they are brought to the beginning of the Product Backlog.
As the Scrum Team in total is responsible for the delivery of the product increment, care would
be taken to select the User Stories for the Sprint based on the size of the Product Increment and
the effort required for the same.
The size of the Product Increment is estimated in terms of User Story Points. Once the size is
determined, the effort is estimated by means of the past data, i.e., effort per User Story Point
called Productivity.
Scrum Estimation Techniques
The Scrum Estimation of User Stories is in terms of the degree of difficulty for each of the User
Stories. To assess the degree of difficulty, a particular scale is used.
There are several types of scales that are used in Scrum Estimation. Following are some
examples-

Numeric Sizing 1through10

T-shirt Sizes XS, S, M, L, XLXXL, XXXL
Fibonacci Sequence 1, 2, 3, 5, 8, 13, 21, 34, etc.
Dog Breeds Chihuahua, ………, GreatDane
The estimation technique is normally chosen in such a way that the entire scrum team is
acquainted and comfortable with scale’s values. The most commonly used and most popular
technique is Planning Poker which is based on Fibonacci sequence.
Planning Poker Technique
In Planning Poker Estimation Technique, estimates for the User Stories are derived by
playing planning poker. The entire Scrum Team is involved and it results in quick but reliable
estimates.
Planning Poker is played with a deck of cards. As Fibonacci sequence is used, the cards have
numbers - 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the Story Points. Each estimator
has a deck of cards. The numbers on the cards should be large enough to be visible to all the
teammembers, when one of the team members holds up a card.
One of the team members is selected as the Moderator. Moderator reads the description of the
User Story for which estimation is being made. If the estimators have any questions, Product
Owneranswers them.
Each estimator privately selects a card representing his or her estimate. Cards are not
shown until all the estimators have made a selection. At that time, all cards are simultaneously
turned over and held up so that all team members can see each estimate.
In the first round, it is very likely that the estimations vary. The high and low estimators explain
the reason for their estimates. Care should be taken that all the discussions are meant for
understanding only and nothing is to be taken personally. The moderator has to ensure the
same.
The team can discuss the story and their estimates for few more minutes.The moderator
can take notes on the discussion that will be helpful when the specific story is developed. After
the discussion, each estimator re-estimates by again selecting a card. Cards are once again kept
private until everyone has estimated, at which point they are turned over at the same
time.Repeat the process till the estimates converges to a single estimate that can be used for the
story. The number of rounds of estimation may vary from one user story to another.
Benefits of Planning Poker Estimation
Planning poker combines three methods of estimation -
Expert Opinion : In an Expert Opinion based Estimation approach, an expert is asked how
long something will take or how big it will be. The expert provides an estimate relying on his or
her experience or intuition or gut feel.
Expert Opinion Estimation usually doesn’t take 35 much time and is more accurate compared to
some of the analytical methods.
Analogy : Analogy Estimation uses comparison of User Stories. The User Story under
Estimation is compared with similar User Stories implemented earlier. This results in accurate
results as the estimation is based on proven data.
Disaggregation : Disaggregation Estimation is done by splitting a User Story into smaller,
easier- to-estimate User Stories. The user stories to be included in a Sprint are normally in the
range of two to five days to develop. Hence, the User Stories that possibly take longer duration
need to be split into smaller Use Cases. This approach also ensures that there would be many
stories that are comparable.
Conclusion
Planning Poker is an enjoyable, yet productive approach to estimating. As the session is open for
discussions before the final estimate is arrived, it would easy for the team to come to a
consensusand also have a broad view of the implementation of the User Story at hand.

Scrum Tools facilitate planning and tracking for Scrum projects. They provide a single place for
managing the product backlog, sprint backlog, planning and tracking Sprints, displaying
Burndowncharts, conducting daily Scrum Meetings, and conducting Scrum Retrospectives.
There are many different types of Scrum Tools available. Some are free opensource, some are
paid, and for some, you get a distilled version of the tool. However, to get all the features and
scalability,you need to buy a full version.
Available Scrum Tools
Following is a list of some Scrum Tools available in market as of day. The Open Source Tools
aremarked with Asterisk.

Axosoft Airgile Agile Cockpit Jira Mingle

GreenHopper

Scrumwise Agilo For Scrum Banana Scrum Kunagi OnTime Now

Version One AgileWrap Daily-Scrum Intervals Pango Scrum
Agile TrackingTool*
Digaboard* iMeta Agility Pivotal Tracker

Agile Agenda Agile Task EasyBacklog Ice Scrum* pmScrum Agile

Bench Agile Soup Explain PMT Hansoft Prj Planner Agile
Buddy Agile Manager Agile Express* GravityDev Project Cards
Agile Fant* Agile Log Fire Scrum* Fulcrum* Quantum
Whisper

Quick Scrum Retrospectiva* Scrum’d Scrumpy Scrum Pad

Scrum
Factory*
Rally Dev Scrinch* Scrum Dashboard*
Scrum
Edge
Redmine Backlogs Scrum 2 Go Scrum Desk Scrum Do Tweet Scrum

Scrumrf Scrum Time* Scrumwise Tackle*

Select
SolutionFactory

36
Urban Turtle ScrumTool Scrum Works Timebox Tangy Orange
Scrum

Conclusion
Agile in general, Scrum in specific does not mean there is no documentation work. The Scrum
Artifacts are defined, Scrum Planning and Tracking are well established.
Scrum Tools facilitate in capturing and tracking information regarding the Scrum Projects. The
choice of the tool depends on the features required by the organization, in addition to the needs
for any other tool.

Scrum supports continuous collaboration among the customer, team members, and relevant
stakeholders. Its time-boxed approach and continuous feedback from the product owner ensures
working product with essential features all the times. Additionally, Scrum provides different
benefits to the different roles in the project.
Benefits to Customer
The Sprints are of shorter duration and prioritized user stories are taken up at every sprint planning.
It ensures that at every sprint delivery, the features as required by the customer immediately are
included. Further, if a customer raises any change request, it will be absorbed in the current sprint,
or included in the very next sprint. Thus, the development team quickly responds to the customer’s
requirements very fast.
Benefits to Organization
Organization can focus on the effort required for development of the prioritized user stories and thus
reduce overhead and rework. Due to the specific benefits of scrum to customer, increased
efficiency of the development team, customer satisfaction and hence customer retention and
customer references will be possible. It increases the market potential of the organization.
Benefits to Product Managers
Product Manager plays the role of Product Owner in the project. The responsibility of the product
owner is to ensure customer satisfaction. Since Scrum facilitates quick responses, work
prioritization, absorbing changes, product manager can easily ensure that the work is aligned to
customer needs, which in turn ensures customer satisfaction.
Benefits to Project Managers
Project Manager plays the role of Scrum Master in the project. The collaborative nature of Scrum
facilitates easy and concrete planning and tracking. The use of Burndown Charts to understand
the work left, and the Daily Scrum meetings give the Project Manager awareness about the state
of the project at all times. This awareness is essential to monitoring the project, and for catching
and addressing issues quickly.
Benefits to Development Team
Due to the time-boxed nature of sprints and working product increment delivery at the end of
every sprint, the development team becomes enthusiastic to see that their work is used immediately.
The built in team collaboration makes the team enjoy the work they do. As the user stories for
every sprint are based on customer priorities, team also understands that their work is valued.

Extreme Programming
37
What is Extreme Programming?
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality
software and higher quality of life for the development team. XP is the most specific of the agile frameworks
regarding appropriate engineering practices for software development.

When Applicable

The general characteristics where XP is appropriate were described by Don Wells on

www.extremeprogramming.org:

 Dynamically changing software requirements

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

Due to XP’s specificity when it comes to its full set of software engineering practices, there are
several situations where you may not want to fully practice XP. The post When is XP Not
Appropriate on the C2 Wiki is probably a good place to start to find examples where you may not want
to use XP.While you can’t use the entire XP framework in many situations, that shouldn’t stop you from
using as many of the practices as possible given your context.
Values

The five values of XP are communication, simplicity, feedback, courage, and respect which are described
in more detail below.
Communication

Software development is inherently a team sport that relies on communication to transfer knowledge from one
team member to everyone else on the team. XP stresses the importance of the appropriate kind of
communication – face-to-face discussion with the aid of a whiteboard or other drawing mechanism.
Simplicity

Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do
only absolutely necessary things such as keep the design of the system as simple as possible so that it is
easier to maintain, support, and revise. Simplicity also means addressing only the requirements that you
know about; don’t try to predict the future.
Feedback
Through constant feedback about their previous efforts, teams can identify areas for improvement and
revise their practices. Feedback also supports simple design. Your team builds something, gathers
feedback on your design and implementation, and then adjusts your product going forward.
Courage

38
 Kent Beck defined courage as “effective action in the face of fear” (Extreme Programming Explained P. 20).
This definition shows a preference for action based on other principles so that the results aren’t harmful to the
team. You need courage to raise organizational issues that reduce your team’s effectiveness. You need courage
to stop doing something that doesn’t work and try something else. You need courage to accept and act on
feedback, even when it’s difficult to accept.
Respect

The members of your team need to respect each other in order to communicate with each other, provide and
accept feedback that honors your relationship, and work together to identify simple designs and solutions.

Practices

The core of XP is the interconnected set of software development practices listed below. While it is possible
to do these practices in isolation, many teams have found some practices reinforce the others and should be
done in conjunction to fully eliminate the risks you often face in software development.

The XP Practices have changed a bit since they were initially introduced. The original twelve practices are listed
below. If you would like more information about how these practices were originally described,

The Planning Game

The idea behind slack in XP terms is to add some low-priority tasks or stories in your weekly and quarterly
cycles that can be dropped if the team gets behind on more important tasks or stories. Put another way,
account for the inherent variability in estimates to make sure you leave yourself a good chance of meeting
your forecasts.
Small Releases
Metaphor
Simple Design
Testing Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-hour week
On-site Customer
Coding Standard

Below are the descriptions of practices as described in the second edition of Extreme Programming
Explained Embrace Change. These descriptions include refinements based on the experiences of many who
practice extreme programming and reflect a more practical set of practices.
Sit Together

39
 Since communication is one of the five values of XP, and most people agree that face-to-face conversation is
the best form of communication, have your team sit together in the same space without barriers to
communication, such as cubicle walls.
Whole Team
A cross-functional group of people with the necessary roles for a product form a single team. This means
people with a need as well as all the people who play some part in satisfying that need all work together on a
daily basis to accomplish a specific outcome.
Informative Workspace

Set up your team space to facilitate face-to-face communication, allow people to have some privacy
when they need it, and make the work of the team transparent to each other and to interested parties outside
the team. Utilize Information Radiators to actively communicate up-to-date information.
Energized Work
You are most effective at software development and all knowledge work when you are focused and
free from distractions.
Energized work means taking steps to make sure you are able physically and mentally to get into a focused state.
This means do not overwork yourself (or let others overwork you). It also means staying healthy, and showing
respect to your teammates to keep them healthy.

Pair Programming

Pair Programming means all production software is developed by two people sitting at the same
machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You
effectively get a continuous code review and quicker response to nagging problems that may stop one person dead
in their tracks.Teams that have used pair programming have found that it improves quality and does not actually
take twice as long because they are able to work through problems quickly and they stay more focused on the task
at hand, thereby creating less code to accomplish the same thing.

Stories

Describe what the product should do in terms meaningful to customers and users.
These stories are intended to be short descriptions of things users want to be able to do with the product that can be
used for planning and serve as reminders for more detailed conversations when the team gets around to realizing
that particular story.

Weekly Cycle

The Weekly Cycle is synonymous with an iteration. In the case of XP, the team meets on the first day of the week
to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team
determines how they will approach those stories. The goal by the end of the week is to have running tested features
that realize the selected stories.

The intent behind the time-boxed delivery period is to produce something to show to the customer for feedback.

Quarterly Cycle
40
The Quarterly Cycle is synonymous with a release. The purpose is to keep the detailed work of each weekly cycle
in the context of the overall project. The customer lays out the overall plan for the team in terms of features
desired within a particular quarter, which provides the team with a view of the forest while they are in the trees,
and it also helps the customer to work with other stakeholders who may need some idea of when features will be
available.

Remember when planning a quarterly cycle the information about any particular story is at a relatively high level,
the order of story delivery within a Quarterly Cycle can change and the stories included in the Quarterly Cycle
may change. If you are able to revisit the plan on a weekly basis following each weekly cycle, you can keep
everyone informed as soon as those changes become apparent to keep surprises to a minimum.

Slack

Ten-Minute Build

The goal of the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten
minutes. The founders of XP suggested a 10-minute time frame because if a team has a build that takes longer
than that, it is less likely to be run on a frequent basis, thus introducing a longer time between errors.

This practice encourages your team to automate your build process so that you are more likely to do it on a
regular basis and to use that automated build process to run all of your tests.

This practice supports the practice of Continuous Integration and is supported by the practice of Test First
Development.

Continuous Integration

Continuous Integration is a practice where code changes are immediately tested when they are added to a larger
code base. The benefit of this practice is you can catch and fix integration issues sooner.

Most teams dread the code integration step because of the inherent discovery of conflicts and issues that result.
Most teams take the approach of “If it hurts, avoid it as long as possible”. Practitioners of XP suggest “if it hurts,
do it more often”.

The reasoning behind that approach is that if you experience problems every time you integrate code, and it takes
a while to find where the problems are, perhaps you should integrate more often so that if there are problems, they
are much easier to find because there are fewer changes incorporated into the build. This practice requires some
extra discipline and is highly dependent on Ten Minute Build and Test First Development.

Test-First Programming

Instead of following the normal path of:

develop code -> write tests -> run tests

The practice of Test-First Programming follows the path of:

41
Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat

As with Continuous Integration, Test-First Programming reduces the feedback cycle for developers to identify and
resolve issues, thereby decreasing the number of bugs that get introduced into production.

Incremental Design

The practice of Incremental Design suggests that you do a little bit of work upfront to understand the proper
breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design
when you deliver specific features. This approach reduces the cost of changes and allows you to make design
decisions when necessary based on the most current information available.

The practice of Refactoring was originally listed among the 12 core but was incorporated into the practice of
Incremental Design. Refactoring is an excellent practice to use to keep the design simple, and one of the most
recommended uses of refactoring is to remove duplication of processes.

Roles

Although Extreme Programming specifies particular practices for your team to follow, it does not really establish
specific roles for the people on your team.

Depending on which source you read, there is either no guidance, or there is a description of how roles typically
found in more traditional projects behave on Extreme Programming projects. Here are the four most common
roles associated with Extreme Programming:

The Customer
The Customer role is responsible for making all of the business decisions regarding the project
including:

What should the system do (What features are included and what do they accomplish)?
How do we know when the system is done (what are our acceptance criteria)?
How much do we have to spend (what is the available funding, what is the business case)?
What should we do next (in what order do we deliver these features)?

The XP Customer is expected to be actively engaged in the project and ideally becomes part of the team.
The XP Customer is assumed to be a single person, however, experience has shown that one person
cannot adequately provide all of the business-related information about a project. Your team needs to make
sure that you get a complete picture of the business perspective, but have some means of dealing with
conflicts in that information so that you can get clear direction.
The Developer

Because XP does not have much need for role definition, everyone on the team (with the exception
of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are
responsible for realizing the stories identified by the Customer. Because different projects require a different

42
mix of skills, and because the XP method relies on a cross-functional team providing the appropriate mix of
skills, the creators of XP felt no need for further role definition.

The Tracker

Some teams may have a tracker as part of their team. This is often one of the developers who spend part of
their time each week filling this extra role. The main purpose of this role is to keep track of relevant metrics
that the team feels are necessary to track their progress and to identify areas for improvement. Key metrics
that your team may track include velocity, reasons for changes to velocity, amount of overtime worked, and
passing and failing tests.
This is not a required role for your team and is generally only established if your team
determines a true need for keeping track of several metrics.
The Coach
If your team is just getting started applying XP, you may find it helpful to include a Coach on your
team. This is usually an outside consultant or someone from elsewhere in your organization who has used
XP before and is included in your team to help mentor the other team members on the XP Practices and to
help your team maintain your self-discipline.

The main value of the coach is that they have gone through it before and can help your team avoid mistakes
that most new teams make.
Lifecycle

To describe XP in terms of a lifecycle it is probably most appropriate to revisit the concept of the Weekly
Cycle and Quarterly Cycle.
First, start off by describing the desired results of the project by having customers define a set of stories.
As these stories are being created, the team estimates the size of each story. This size estimate, along with
relative benefit as estimated by the customer can provide an indication of relative value which the customer
can use to determine the priority of the stories. If the team identifies some stories that they are unable to
estimate because they don’t understand all of the technical considerations involved, they can introduce a spike
to do some focused research on that particular story or a common aspect of multiple stories. Spikes are short,
time-boxed time frames set aside for the purposes of doing research on a particular aspect of the project.
Spikes can occur before regular iterations start or alongside ongoing iterations.
Next, the entire team gets together to create a release plan that everyone feels is reasonable. This
release plan is a first pass at what stories will be delivered in a particular quarter or release. The stories
delivered should be based on what value they provide and considerations about how various stories support
each other.
Then the team launches into a series of weekly cycles. At the beginning of each weekly cycle, the team
(including the customer) gets together to decide which stories will be realized during that week. The team
then breaks those stories into tasks to be completed within that week.
At the end of the week, the team and customer review progress to date, and the customer can decide
whether the project should continue, or if a sufficient value has been delivered.

43
Origins

XP was first used on the Chrysler Comprehensive Compensation (C3) program which was
initiated in the mid-’90s and switched to an XP project when Kent Beck was brought on to the project to
improve the performance of the system. He wound up adding a couple of other folks, including Ron
Jeffries to the team and changing the way the team approached development. This project helped to
bring the XP methodology into focus and the several books written by people who were on the project
helped spread knowledge about and adaptation of this approach.
Primary Contributions
XP’s primary contribution to the software development world is an interdependent collection of
engineering practices that teams can use to be more effective and produce higher-quality code. Many teams
adopting agile start by using a different framework and when they identify the need for more disciplined
engineering practices they adopt several if not all of the engineering practices espoused by XP.

An additional, and equally important, contribution of XP is the focus on practice excellence. The
method prescribes a small number of absolutely essential practices and encourages teams to perform those
practices as well as they possibly can, almost to the extreme. This is where the name comes from. Not
because the practices themselves are necessarily radical (although some consider some of them pretty far out)
but rather because teams continuously focus so intently on continuously improving their ability to perform
those few practices.

Feature driven development

1. What is FDD?

FDD is an agile, highly adaptive software development process that is

 Highly and short iterative.

 Emphasizes quality at all steps

 Delivers frequent, tangible working results at all steps

 Provides accurate and meaningful progress and status information, with the minimum of
overhead and disruption for the developers.

 Is liked by client, managers and developers

2. Why do we have to use FDD?

2.1 Pains in Software Development

2.1.1 Communication
44
In a software development process, communication is taking place constantly at every level. In
fact, no process (work) can occur without it. If we consider developers as nodes in a
communication network, all potentially linked to each other by communication channels, then
the number of potential communication channels increase dramatically as more number of
developers are added.

2.1.2 Complexity

As the size of a software system grows, the complexity of that software system grows “at least as
fast the square of the size of the program” [Weinberg, G., 1992] and quickly outstrips the
relatively fixed capacity of a human brain. Gerald Weinberg calls this law of software
development “the size / complexity dynamic”.

FDD decomposes the entire problem domain into tiny problems, which can be solved in a small
period of time, usually 2 weeks decomposed problems independent to each other reduces the
need of communication.

“Observe that it is perhaps 100 times more costly to make a change to the requirements during
system testing as it is to make the change during requirements definition“ (Fairley, R., 1985).

FDD splits the project into iterations so that the distance in time between analysis and test is
reduced early discovery of errors reduces the cost of fixing the errors.

2.1.3 Quality

Different persons have different perception of software quality. A user talking about the quality
of a system discusses the user interface, the response time, the reliability and the ease of the use
of the system. A developer talking about quality discusses elements of design; ease of
maintenance and enhancement; and compliance to standards, patterns, and conventions. Software
managers will look at quality in terms of ease of maintenance and enhancement, compliance to
standards and conventions, and ability to deliver it on time. Project Sponsors will look at how
well the system meets their business requirements. Does it allow them to meet a constantly
changing business requirement and be proactive in meeting the challenges that are ever present in
the marketplace? This makes necessary to view quality as a spectrum, with internal quality at one
end and external quality at other end.

In FDD concept of Quality is broadened so as not just to test the code, but also include things
such as coding standards, measuring audits and metrics in the code.

3. Projects and People

45
Projects consist of people, process, and technology, but by far the most important aspect is
people. FDD defines six key roles and implies a number of others.
The Project Manager (PM) is the administrative head of the project responsible for reporting
progress, managing budgets, fighting for headcount, and managing equipment, space, and
resources, etc.

The Chief Architect (CA) is responsible for the overall design of the system. He is responsible
for running the workshop design sessions where the team collaborates in the design of the
system. The work requires both excellent technical and modeling skills as well as good
facilitation skills. He or she steers the project through the technical obstacles confronting the
project.

The Development Manager (DM) is responsible for leading the day-to-day development
activities. In a facilitating role requiring good technical skills, the Development Manager is
responsible for resolving everyday conflicts for resources when the Chief Programmers cannot do
it between themselves.

The Chief Programmers are experienced developers who have been through the entire software
development lifecycle a few times. They participate in the high-level requirements analysis and
design activities of the project and are responsible for leading small teams of three to six
developers through low level analysis, design and development of the new software’s features.

The Class Owners are developers who work as members of small development teams under the
guidance of a Chief Programmer to design, code, test, and document the features required by the
new software system.

The Domain Experts are users, sponsors, business analysts, or any mix of these. They are the
knowledge base that the developers rely on to enable them to deliver the correct system. Domain
Experts need good verbal written and presentation skills. Their knowledge and participation are
absolutely critical to the success of the system being built.

3.1 Supporting roles

The Release Manager ensures that the Chief Programmers report progress each week. He then
reports directly to the Project Manager.
A Language Guru is a person who is responsible for knowing a programming language or a
specific technology inside out. In projects where a programming language or technology is used
for the first time, then this role is special.

The Build Engineer is responsible for setting up, maintaining, and running the regular build
process.
46
The Toolsmith creates small development tools for the development team, test team, and data
conversion team.
The System Administrator configures, manages, and troubleshoots any servers and network of
workstations specific to the project team.

3.2 Additional roles

Testers are responsible for independently verifying that the system’s functions meet the users’
requirements and that the system performs those functions correctly.

Deployers convert existing data to the new formats required by the new system and work on the
physical deployment of new releases of the system.
Technical Writers write and prepare online and printed user documentation.

FDD – Practices
FDD blends a number of Industry-recognized best practices into a coherent whole. The best
practices used in FDD are:

6.1. Domain Object Modeling

It consists of building class diagrams depicting the significant types of objects within a problem
domain and the relationships between them. It is a form of object decomposition. The problem is
broken down into the significant objects involved. The design and implementation of each object
or class identified in the model is a smaller problem to solve. When the completed classes are
combined, they form the solution to the larger problem. ”Modeling in Color” is the best technique
for Domain Object Modeling.

6.1.1. UML in Color

Colored UML is regular UML with color-encoded classes. The use of color allows quick
understanding of the problem domain’s dynamics. All the classes are divided into different
categories; each category has its own color. The auxiliary classes and interfaces are colorless.
Figure 1 shows a fragment of a colored UML diagram.
Yellow: a role being played, usually by a person or an organization. For example, the user of an

online auction site may play different roles: it can be a buyer, a seller or a system administrator.

47
Blue: a catalogue-like description. For example, an online store may have descriptions of the CD
players that it sells. The description gives all the characteristics of the player, but it is not the
player itself.

Green: a party, place or thing. In the previous example, the actual CD player in stock would be
modeled as green. The green class usually has some identifying attributes, such as serial number,
person’s name etc.

Pink: a moment in time or an interval of time usually associated with some business process. For
example, the fact of purchase may be shown a pink class, since it has a time of sale, which is
tracked by the online store.

Figure 1 Example of color UML. This figure displays part of the problem domain for Feature
Driven Development for a garage. The purpose of above model is to track cars in a garage.
Service and Regular service class have dates , therefore they are represented by pink interval. Car
is a thing so it has green color. The Model belongs to the description archetype so blue in color.
A person may be car owner or a mechanic hence these classes are yellow in color. (Source:
Palmer, SR., Felsing , JM.2002,p.124)

6.2. Developing by Feature

Any function that is too complex to be implemented within two weeks is further decomposed into
smaller functions until each sub-problem is small enough to be called a feature. In a business
system, a feature maps to a step in some activity within a business process.

By Definition: A feature is a small, client valued function that can be implemented in two weeks

48
The feature naming template is

<action>the <result><by|for |of | to|><a(n)><object>

Example of features are :

Calculate [action] the total [result] of a sale [object].

Assess the fulfilment timeliness of a sale

Calculate the total purchases by a customer

A feature Set is a grouping of business related features.

<action><-ing><a(n)><object>
Example : Making a product sale.

A major feature Set

<object>Management

Example: Product-Sales Management

6.3. Class (Code) Ownership

Class code ownership in a development process denotes who (person or role) is ultimately
responsible for the contents of a class (piece of code). FDD uses individual ownership –
developers are assigned ownership of a set of classes from the domain object model.

6.4. Feature Team

The implementation of a feature may involve more than one class, hence more than one Class
Owner. Thus the feature Owner is supposed to have a team lead job, in which he coordinates the
efforts of multiple developers.

Chief characteristics of a feature team

A feature team, due to small size of features, remains small.
As the feature team owns all the code it needs to change for that feature, there is no waiting for
members of other teams to change code. So we have code ownership and a sense of collective
ownership too.

Each member of a feature team contributes to the design and implementation of a feature under
the guidance of a skilled, experience developer. This reduces the risk of reliance on key
developers or owners of specific classes.

49
Class Owners may find themselves members of multiple feature teams at the same time.

Chief Programmers are also Class Owners and take part in feature teams led by other Chief
Programmers.

Figure 2 Feature teams: Feature teams are formed from class owners as needed. (Source:
Palmer, SR., Felsing , JM.2002,p.47)

6.5. Inspections

The mix of feature team and inspection adds a new dimension to FDD. As a feature team
comprises more than one member, so the fear of humiliation for a particular person is no
more.Applying best known defect detection techniques and leveraging the opportunities it
provides to propagate good practice, conventions, and development culture.

6.6. Regular Build Schedule

At regular intervals all the source code for the features completed is taken is taken, and the
libraries and components on which it depends and the complete system is build. This ensures that
there is always a demonstrable system available.

6.7. Configuration Management

This serves to identify the latest versions of completed source code files and provides historical
tracking of all information artifacts in the project.

6.8. Progress Reporting

Throughout the project frequent, appropriate, and accurate progress reporting at all levels, inside
and outside the project, based on completed work is done.
Processes

FDD starts with the creation of a domain object model in collaboration with Domain Experts.
Using information from the modeling activity and from any other requirement activities that have
50
taken place, the developers go on to create a features list. Then a rough plan is drawn up and
responsibilities are assigned. Small groups of features feature that lasts no longer than two weeks
for each group and is often much shorter are taken up. FDD consists of five processes.

Process I II III IV V

Figure 3 The five processes of FDD with their outputs (Source: Palmer, SR., Felsing , JM.2002,p.57).

7.1. Develop an Overall Model

Domain and development team members work together under the guiding hand of an experienced
Object modeller (Chief Architect). Domain Members perform an initial high-level walkthrough
of the scope of the system and its context. Then the domain members perform more detailed
walkthroughs of each area of the problem domain. After each walkthrough, the domain and
development members work in small groups to produce object models for that area of the
domain. Each small group composes its own model in support of the domain walkthrough and
presents its results for peer review and discussion. One of the proposed models or a merge of the
models is selected by consensus and becomes the model for that domain area. The domain area
model is merged into the overall model, adjusting the model shape as required. The object model
is then updated iteratively with content by process IV, Design by Feature (see figure 3).

Figure 4 Flow diagram of developing an overall model (Source: Palmer, SR., Felsing , JM.2002,p.106).
51
7.2. Build a Features List
A team usually comprising just the Chief Programmers from process 1 is formed to decompose
the domain functionality. Based on the partitioning of the domain by the Domain Experts in
process 1 , the team breaks the domain into a number of areas (major feature Sets). Each area is
further broken into a number of activities (feature sets). Each step within an activity is identified
as a feature. The result is a hierarchically categorized features list.

Figure 5 Flow diagram of building a feature list (Source: Palmer, SR., Felsing , JM.2002,p.135).

Figure 6 Sample feature list

7.3. Plan by Feature

52
The project Manager, Development Manager, and Chief Programmers plan the order that the
features are to be implemented, based on feature dependencies, load across the development
team, and the complexity of the features to be implemented. The main tasks in this process are
not a strict sequence. Like many planning activities, they are considered together, with
refinements made from one or more tasks, then the others are considered again. A typical
scenario is to consider the development sequence, then consider the assignment of features sets to
Chief Programmers, and in doing so, consider which of the key classes are assigned to which of
the developers. When this balance is achieved and the development sequence and assignment of
business activities to Chief Programmers is essentially completed, the class ownership is
completed.

Figure 7 Flow diagram for planning by feature (Source: Palmer, SR., Felsing , JM.2002,p.146).

7.4. Design by Feature

A number of features are scheduled for development by assigning them to a Chief Programmer.
The Chief Programmer selects features for development from his or her “inbox” of assigned
features. Operationally, it is often the case that the Chief Programmer schedules small group of
features at a time for development. He or she may choose multiple features that happen to use the
same class (hence developers). Such a group of features forms a Chief Programmer work

53
Package. The Chief Programmer then forms a feature team by identifying the owners of the
classes (developers) likely to be involved in the development of the selected feature(s). The chief
Programmer then refines the object model based on the content of the sequence diagram(s). The
developers write class and method prologues. A design inspection is held.

Figure 8 Flow diagram for designing by feature (Source: Palmer, SR., Felsing , JM.2002,p.160)

7.5. Build by Feature

Working from the design package produced during the Design by Feature process, the class
owners implement the items necessary for their class to support the design for the feature(s) in
the work package. The code developed is then unit tested and code inspected, the order of which
is determined by the Chief Programmer. After a successful code inspection, the code is permitted
to build.

Figure 9 Flow diagram for building by feature (Source: Palmer, SR., Felsing , JM.2002,p.181).

Progress

8.1. Estimating Progress

FDD does not ask feature teams for a percentage of completeness. FDD tells feature teams what
percentage complete they are!

8.2. Track by Feature

FDD uses six sharply defined milestones to track progress of each feature through process IV and
V, Design by Feature (DBF) and Build by Feature (BBF) (Figure 10). The first three milestones
are completed during the DBF process. The last three milestones are completed during the BBF
54
process. The six milestones are completed sequentially for each feature being developed. A
milestone is reported complete only when all the work for that task has been finished and verified
to be so. These six milestones are as follows:

1. The Domain Walkthrough milestone is attained on completing the domain walkthrough and
the optional task of studying the referenced documents.

2. The design milestone is attained on completion of the three tasks

 Develop the sequence Diagram(s)

 Refine the Object Model

 Write Class and Method Prologues

3. The Design Inspection milestone is attained on successfully passing the design inspection
task
4. The Code milestone is attained on completion of the implement classes and methods task.

5. The Code Inspection milestone is attained on completed of the code inspection task. This
includes the completion of any modifications required by the inspection and the completion
of any unit testing performed after the code inspection.

6. The Promote to Build milestone is attained when all the code for a feature has been checked
into the version control system used to generate “the build”.

Design by Feature Build by Feature

Figure 10 The six milestones of feature development. (Source: Palmer, SR., Felsing , JM.2002,p.77).

8.3. Reporting to the Chief Programmers and Project Manager

A percentage weighting is assigned to each milestone. So we can say that a feature that has
reached the coding stage is 44% complete. The weighting percentages assigned to each milestone
varies from situation to situation, depending upon the level of effort put into it.

55
 Figure 11 Percentage Weighting Assigned to Milestones(Source: Palmer, SR., Felsing , JM.2002,p.80).

Now the percentage of completeness for every feature in the feature list is calculated. Doing this
for all the features in a Feature Set, gives us the completion percentage of the Feature Set. This is
done for each major Feature Set and then for the whole project. In this way we can count the
number of features not started, the number in progress, and the number completed for the project.

Feature Set No of No not No in No Percentage

Features started Progress Completed Completed

Scheduling a 19 9 8 2 27.7%
Service

Performing a 15 8 7 0 30.1%
Service

Billing a Service 6 5 0 1 16.6%

Booking in a 13 2 2 9 75%
Repair

Total 53 24 17 12 38.7%

Table 1 Workshop Management Area (Source: Palmer, SR., Felsing , JM.2002,p.82)

Every week, the rate of progress is shown by plotting a graph for the number of features
completed each week.

56
 Figure 12 A graph plotted for features completed vs. Weeks elapsed

8.4. Reporting to Sponsors and Upper Management

Here we do not need to report for every individual feature, but just to deliver the reporting on
major feature sets and their feature sets. The Figure below shows the progress of the feature set
“Scheduling a Service”

CP Chief Programmer‘s Initials

Scheduling
a Feature Set Name
Service
(19) Number of Features in the
Feature Set
27%
The Feature Set called
2001
DEC 2001 Scheduling a Service has 19
features in it and it is currently 27%
complete and due to be completedby
December 2001
Figure 13 Progress of the Scheduling a Service feature set. (Source: Palmer, SR., Felsing , JM.2002,p.85).

57
Figure 14 Feature sets progress report

58
 In Figure 13 each feature set is represented by a rectangle divided into 3 bands: top, middle and
lower. The top band is the biggest compartment and contains the name of the feature set,
followed by the number of features in the feature set, followed by the percentage completed for
that feature set. The middle band shows a progress bar graphically representing the percentage
of completeness. The progress bar is green; the completed color. The lower band contains the
planned completion date estimated in process 3 and remains white until completed, whereupon
it turns green to match the other two bands.

In Figure 14, Feature Sets are arranged horizontally inside larger rectangles representing
the major feature sets of the system. Each page of paper contains a number of major feature sets
so that the final report consists of a few pages of colored rectangles.

Feature set No of No. not No. in No. No. Behind % complete

Features started Progress Completed
Scheduling 19 9 7 2 1 27.7%
a Service
Performing 15 8 7 0 0 30.1%
a Service
Billing a 6 5 0 1 0 16.6%
Service
Booking in 13 2 2 9 0 75%
a Repair
Total 53 24 16 12 1 38.7%

Table 2 Tracking progress of features (behind schedule) (Source: Palmer, SR., Felsing , JM.2002,p.88).

4. Major Usage

FDD can be implemented with up to 500 developers

 More critical projects

 Bigger projects

 More novice developers

 Environments that demand Waterfall

5. Summary and Conclusion

Feature-driven development is a process for helping teams produce frequent, tangible working
results. It uses very small blocks of client valued functionality, called features. It organizes
those little blocks into business-related feature sets. FDD focuses developers on producing
working results every two weeks. FDD is better prepared to work with team where developers’
experience varies. It offers progress tracking and reporting capabilities. This comforts
managers and makes it more attractive for big companies.

59
Crystal Method
Crystal methods are flexible approaches used in Agile software development to manage projects
effectively. They adapt to the needs of the team and the project, promoting collaboration, communication,
and adaptability for successful outcomes.
 Table of Content
 What is Crystal methods in Agile Development/Framework?
 History of the Crystal Method
 Properties of Crystal Agile Framework
 How does Crystal Methodology Operates?
 Benefits of using the Crystal Agile Framework
 Drawbacks of using the Crystal Agile Framework
 Conclusion
 Frequently Asked Questions related to Crystal Method in Agile Development/Framework
What is Crystal methods in Agile Development/Framework?
The crystal method is an agile framework that is considered a lightweight or agile methodology that
focuses on individuals and their interactions. The methods are color-coded to significant risk to human
life. It is mainly for short-term projects by a team of developers working out of a single workspace.
Among a few Agile Software Development Life Cycle (SDLC) models crystal is considered as one of the
Agile SDLC models.
Two core beliefs of the Crystal method:
 Find your own way and methods to optimize workflow.
 Make use of unique methods to make the project unique and dynamic.
History of the Crystal Method
The crystal method was developed by an American scientist named Alistair Cockburn who worked at
IBM. He decided not to focus on step-by-step developmental strategies, but to develop team
collaboration and communication. Some of the traits of Cockburn’s Crystal method were:
 Human-powered i.e. the project should be flexible and people involved in preferred work.
 Adaptive i.e. approaches don’t have any fixed tools but can be changed anytime to meet the
team’s specific needs.
 Ultra-light i.e. this methodology doesn’t require much documentation.
Properties of Crystal Agile Framework
1. Frequent Delivery: It allows you regularly deliver the products and test code to real users.
Without this, you might build a product that nobody needs.
2. Reflective Improvement: No matter how good you have done or how bad you have done. Since
there are always areas where the product can be improved, so the teams can implement to improve
their future practices.
3. Osmotic Communication: Alistair stated that having the teams in the same physical phase is
very much important as it allows information to flow in between members of a team as in osmosis.
4. Personal Safety: There are no bad suggestions in a crystal team, team members should feel safe
to discuss ideas openly without any fear.
5. Focus: Each member of the team knows exactly what to do, which enables them to focus their
attention. This boosts team interaction and works towards the same goal.
6. Easy access to expert users: It enhances team communication with users and gets regular
feedback from real users.
7. Technical tooling: It contains very specific technical tools which to be used by the software
development team during testing, management, and configuration. These tools make it enable the
team to identify any error within less time.
8. Continuous learning: The framework emphasizes on continuous learning, enabling team
members to acquire new skills and knowledge, and apply them in their work.
9. Teamwork: The framework stresses on the importance of teamwork, promoting collaboration,
and mutual support among team members.
10. Timeboxing: The framework adopts timeboxing to manage project deadlines, ensuring that the
team delivers within set timelines.
11. Incremental development: The framework promotes incremental development, enabling the
team to deliver working software frequently, and adapt to changes as they arise. 60
12. Automated testing: The framework emphasizes on automated testing, enabling the team to detect
and fix bugs early, reducing the cost of fixing errors at later stages.
13. Customer involvement: The framework emphasizes on involving customers in the development
process, promoting customer satisfaction, and delivering products that meet their needs.
14. Leadership: The framework encourages leadership, enabling team members to take ownership of
their work and make decisions that contribute to the success of the project.
How does Crystal Methodology Operates?
Till now, we got to know that crystal is a family of various developmental approaches, and it is not a
group of prescribed developmental tools and methods. In the beginning, the approach is set by
considering the business requirements and the needs of the project. Various methodologies in the Crystal
family also known as weights of the Crystal approach are represented by different colors of the spectrum.
Crystal family consists of many variants like Crystal Clear, Crystal Yellow, Crystal Red, Crystal
Sapphire, Crystal Red, Crystal Orange Web, and Crystal Diamond.
1. Crystal Clear- The team consists of only 1-6 members that is suitable for short-term projects
where members work out in a single workspace.
2. Crystal Yellow- It has a small team size of 7-20 members, where feedback is taken from Real
Users. This variant involves automated testing which resolves bugs faster and reduces the use of too
much documentation.
3. Crystal Orange- It has a team size of 21-40 members, where the team is split according to their
functional skills. Here the project generally lasts for 1-2 years and the release is required every 3 to 4
months.
4. Crystal Orange Web- It has also a team size of 21-40 members were the projects that have a
continually evolving code base that is being used by the public. It is also similar to Crystal Orange
but here they do not deal with a single project but a series of initiatives that required programming.
5. Crystal Red- The software development is led by 40-80 members where the teams can be formed
and divided according to requirements.
6. Crystal Maroon- It involves large-sized projects where the team size is 80-200 members and
where methods are different and as per the requirement of the software.
7. Crystal Diamond & Sapphire- This variant is used in large projects where there is a potential
risk to human life.
The below figure illustrates about crystal team

Crystal Family
Benefits of using the Crystal Agile Framework
Following are the benefits of using Crystal Agile Framework:
 Collaboration: Facilitate and enhance team communication and accountability. 61
 Adaptability: The adaptive approach lets the team respond well to the demanding requirements.
 Empowerment: Allows team to work with the one they see as the most effective.
 Efficiency: Teams talk directly with each other, which reduces management overhead.
 Faster delivery: The framework enables the team to deliver working software faster, which can
help gain a competitive advantage in the market.
 Higher quality: The framework emphasizes on quality, enabling the team to detect and fix
defects early in the development process, resulting in a higher quality product.
 Improved customer satisfaction: The framework promotes customer involvement, enabling the
team to deliver products that meet customer needs, resulting in higher customer satisfaction.
 Increased productivity: The framework enables the team to focus on delivering the highest
value features, which can increase productivity and reduce waste.
 Flexibility: The framework is highly adaptable, enabling the team to adjust to changing
requirements, and make decisions based on real-time feedback.
 Autonomy: The framework promotes empowerment, enabling team members to take ownership
of their work, and make decisions that contribute to the success of the project.
 Reduced risk: The framework promotes risk management, enabling the team to identify and
mitigate potential risks early in the development process, reducing the likelihood of project failure.
Drawbacks of using the Crystal Agile Framework
Following are the drawbacks of using the Crystal Agile Framework:
 Ambiguity: A lack of pre-defined plans may lead to confusion and loss of focus.
 Disorganization: Lack of structure may slow down inexperienced teams.
 Uncertainty: Not clear on how a remote team can share knowledge informally.
 Lack of predictability: The framework’s emphasis on adaptability and flexibility may result in a
lack of predictability, making it difficult to plan and estimate project timelines and budgets.
 Lack of documentation: The framework’s emphasis on communication and collaboration may
result in a lack of documentation, making it difficult to track progress and maintain a record of
decisions.
 Limited scalability: The framework may not be suitable for large or complex projects, as the
lack of structure and predefined plans may make it difficult to manage teams at scale.
 Dependence on team expertise: The framework relies heavily on the expertise and skills of the
development team, which may not be suitable for teams with limited experience or knowledge.
 Lack of clarity on roles and responsibilities: The framework’s emphasis on self-organizing
teams may result in a lack of clarity on roles and responsibilities, leading to confusion and a loss of
focus.
 Inability to handle regulatory requirements: The framework may not be suitable for projects
with strict regulatory requirements, as the lack of documentation and structure may not meet
compliance standards.
 Potential for informal knowledge sharing: The framework’s emphasis on osmotic
communication may result in informal knowledge sharing, which may be difficult to track and
monitor for accuracy and completeness.
Conclusion
The Crystal Method is expandable. It may be used by small teams or large teams to work on simple or
complex objects. Crystal Method places importance on developmental skills and interactions which in
turn encourage the exchange of ideas. Crystal Method is also beneficial for the clients as it delivers the
most important components of the product first. But on the other hand, the Crystal Method does not plan
based on the requirements of the projects.
Frequently Asked Questions related to Crystal Method in Agile Development/Framework

1. What is the difference between scrum and crystal?

While most scrum approaches aim to provide a solution that can be applied to all projects,
Crystal development emphasizes the principle that every project has distinct qualities.
62
2. Is Crystal Clear a method of Agile?

Yes, Crystal Clear is a lightweight methodology within the Agile framework.

3. What are the colors of crystal methodology?

Colors of Crystal Methodology are:

 Clear
 Yellow
 Orange
 Red

63
64
65