What is an epic?

An epic is a large user story which is too big to fit into a sprint. This high-level
story is usually split into smaller ones, each of which can be completed within
a sprint. In that sense, an epic is a collection of user stories with a unified
goal.

Scrum Definition

Scrum is a lightweight framework that helps people, teams and organizations generate value through
adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

Scrum Theory

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from
experience and making decisions based on what is observed. Lean thinking reduces waste and focuses
on the essentials.
Scrum employs an iterative, incremental approach to optimize predictability and to control risk. Scrum
engages groups of people who collectively have all the skills and expertise to do the work and share or
acquire such skills as needed.

ACCEPTANCE CRITERIA & DEFINITION OF DONE (DOD)

Acceptance criteria are the main conditions and standards laid out by the user that a piece of software
must meet before it reaches deployment.
The definition of done, on the other hand, is a comprehensive list of standards and characteristics that
must be met before a project or the user story is considered done or complete and ready for further
development.

Acceptance criteria vs. definition of done similarities

The main similarity between the definition of done and acceptance criteria is that they both
provide an objective measure of a product's quality. Both measures offer transparency into
what the team needs to accomplish for the product increment release.

Another similarity between the two is their use of the user story. Before teams finalize any user
story, they need to ensure it meets both the definition of done and acceptance criteria.

Acceptance criteria vs. definition of done differences

The main areas where acceptance criteria differs from the definition of done are their quality
assessment, scope and creation.
Quality assessment

One of the most important differences between acceptance criteria and the definition of done is
the aspect of quality that each measures. Acceptance criteria assess the quality of the user story
development. They evaluate whether the feature described in the user story meets the user
requirement.

The definition of done is organized into a checklist that ensures that the team has applied the
proper development and testing processes. Some example components of this checklist are the
following:

 has it passed design and code reviews;

 have unit and functional tests passed; and

 has testing covered all acceptance criteria.

Scope

Teams develop and test acceptance criteria for each user story individually, whereas the
definition of done applies to the product increment. Therefore, the definition of done serves as
an overall check on quality. Even when each user story meets its acceptance criteria, the team
could miss processes that could significantly affect the quality of the increment.

Creation

Although the Scrum team creates both acceptance criteria and the definition of done, different
members of the team play different roles in each process.
Product owners serve as the user voice. They create the acceptance criteria with the help of
other members of the team. Quality engineers ensure that the acceptance criteria are specific
and testable. Developers provide input on how to limit code complexity.

Creating the definition of done is a team effort. Product owners, Scrum Masters, developers
and quality engineers must agree. They decide on processes, how to use the processes during
iteration, how to follow those processes and how the processes assess quality.

The Definition of Done can also partially apply to individual stories. E.g., A developer will mark the story
"Done" only when the checklist related to code completion, Test completion, and Acceptance Testing is
complete. However, the other checklist, like deployment to production and Non Functional
Requirements, might be applied at the product increment level.

How the 12 principles in the Agile Manifesto work in real life

The Scrum framework comes with its own guardrails and values, but it is worth
taking a moment to consider the base upon which Scrum is founded by examining
the principles and values of the Agile Manifesto. The Agile Manifesto includes four
values and 12 principles that describe a better way to approach complex
work. Below, we will discuss each of the 12 principles and what they mean in the
real world.
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
The image below is a famous example from Henrik Knilberg demonstrating an agile
approach to product delivery and comparing it with more traditional methods.
The first principle included in the Agile Manifesto starts with “Our highest goal is to
satisfy the customer….” This statement reflects what we all learned after running
our first lemonade stand: to stay in business, we need to keep the customer happy.
But it doesn’t stop there. The agile principles take this a step further and assert that
the way to keep the customer happy is “through early and continuous delivery of
valuable software.” In other words, the best way to keep the customer happy is to
deliver valuable products to the customer frequently. After all, the only thing better
than a great product is a great product that gets better often.

Unlike waterfall or other traditional project management approaches, agilists deliver

early and continuously. We are not producing software once in one large delivery.
Instead, we're delivering it frequently—or iteratively. Further, our customers must
find what we deliver usable and valuable. It's an incremental approach. Rather than
envisioning the end state of a product and working on that step-by-step, agile teams
continuously ask themselves, what is the most valuable thing to do next?

The illustration above shows how this might look. The waterfall team envisions only
the final product and delivers it in silos by working on systems that will be part of
the final delivery, such as the tires, the frame and finally, the car. The agilists below
them focus on the goal, which is transportation. In their first delivery, they manage
to deliver a skateboard. In their second delivery, a skateboard with handles. Next,
they produce a bicycle, then a motorcycle, and, finally, a car. Each delivery is
usable, and each builds upon the previous work. These two scenarios show the
difference between thinking only about the end state versus delivering
value incrementally.

But isn’t that wasteful? Surprisingly, in the real world, incremental delivery is not
wasteful. In fact, it eliminates waste because stakeholders and customers provide
frequent feedback about whether what the team delivered was useful or whether the
team should change direction. This regular feedback loop means that teams are less
likely to spend a lot of time on features that are not useful to the customer.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
The Agile Manifesto’s second principle speaks to a different approach to
requirements. Traditional methods aim to reduce the amount of change while
product development is in flight. Agile does just the opposite. Instead of focusing
on reducing variation and changes to the original requirements, Agile
frameworks welcome change. Delivering value in smaller, usable increments makes
this possible. Agile teams learn something from the customer after each delivery,
and because it's a smaller increment of work, it's possible to introduce new
requirements.

Why do Agile teams welcome change? Teams use an agile framework in complex
environments, where more is unknown than known. In that context, does it make
sense for the team to plan everything at the start, when they know less, or does it
make sense to replan regularly as they learn more?
The benefit of welcoming change means that agile teams are able to respond to
changing circumstances as more information becomes known over time.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
All agile frameworks rely upon the principle of delivering working software
frequently, but this principle takes it a step further. Teams must deliver working
software; not just a cog in the machine, so to speak.

Consider the image below. The left-hand side of the image represents the traditional
way of delivering value to the customer, which is a large deliverable provided after
everything envisioned in the final product is complete. Contrast this with the right-
hand side of the image, which shows an iterative (frequent), incremental (Done)
approach for delivering value. Each piece of what is delivered is usable, but it’s a
smaller piece of the bigger puzzle.
In Scrum, teams determine the frequency of value delivery by the length of the
Sprint. The purpose of each Sprint is to deliver a Done, usable increment of work at
least once per Sprint. The Product Owner then determines when to release the
functionality to the customer. The Sprint length should be just long enough to allow
the Developers to deliver a usable increment of product, and no longer, with a
preference towards the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
To me, this principle generates the most noticeable changes in the day-to-day
experience of an agile team compared to a waterfall or traditional team. Using a
traditional approach, the delivery team often goes through a long, intense
requirements phase where they frequently meet with the business stakeholders.
After they complete the requirements phase, the delivery team disappears to build
whatever they understand the stakeholders specified.

Agile is different. Business stakeholders meet regularly with the agile team at a
lower level of engagement. In Scrum, this engagement may take place in refinement
meetings or at the Sprint Review. In other agile frameworks, this engagement may
take the form of replenishment meetings. Regardless, engagement, and
therefore visibility, is continuous in an agile environment.
In the image above dashed lines represent a waterfall or traditional approach. The
blue lines represent Scrum, which is the most popular agile framework. By engaging
with stakeholders more frequently, agile teams provide greater visibility into product
delivery. Whereas traditional teams rely upon infrequent progress or status reports
to provide visibility, Scrum teams rely upon frequent inspection of Done, usable work
at the Sprint Review.

5. Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get the job
done.
Leaders who work with agile teams focus on ensuring that the teams have the
support (tools, access, resources) and environment (culture, people, external
processes) they need, and then trust them to get the job done. This principle can
scare some leaders who have a more command-and-control management style.
They wonder how they'll know if their team is succeeding and focusing on the right
things. My response to these concerns is to focus on the team’s outcomes. Are
they delivering working product frequently? Are they making progress towards their
goals? Those are the metrics that warrant attention. It is a necessary shift in
perspective and mindset, and it is one that leaders as well as agile teams need to
make to achieve the best results. To learn more about how to support agile teams,
leaders should consider attending the Professional Agile Leadership - Essential class.
Successful agile leaders enable teams to deliver value by providing them with the
tools that they need to be successful, providing guidance when needed, embracing
servant leadership and focusing on outcomes.

6. The most efficient and effective method of conveying information

to and within a development team is face-to-face conversation.
With the greater adoption of Zoom and other meeting platforms, the words face-to-
face have taken on a slightly different meaning lately, but the idea behind this
principle remains. The best way to convey information is to have a real-time
conversation rather than a back-and-forth via email or messaging app. For agile
teams, this may mean that those who deliver the work speak directly to those using
the work. Or it could mean that those who deliver the work collaborate amongst
themselves to solve their problems. Each agile team determines how best to live
this principle according to their unique situation. What matters is that
collaboration is critical for all Agile teams.
The best way to collaborate is to have a conversation.

7. Working software is the primary measure of progress.

This is the third time that the word software has shown up in one of the principles of
the Agile Manifesto. The use of the word reflects the fact that agile “grew up” in
software development, meaning that many of those who originally participated in the
creation of the Agile Manifesto were in the software field. Today, agile frameworks
are used in venues as diverse as human resources, marketing and defense.

The seventh principle speaks to the importance of delivering working software (or
product). Success isn’t about the percentage of the work we have completed or how
well we are sticking to a plan. In agile, we measure success by the product that we
have delivered, and whether it is in a usable state. This means that progress
reports, while they have their place, are not an end in themselves. Working product
is ultimately what matters.

8. Agile processes promote sustainable development. The sponsors,

developers, and users should be able to maintain a constant pace
indefinitely.
Have you ever been a part of a traditional team with a critical delivery scheduled far
in the future? At first, the team approaches the work casually. Then, as the delivery
date approaches, managers ask team members to work progressively longer hours
to make the deadline. Along the way, business stakeholders inevitably change their
minds about some of the requirements, which are difficult to work into the product
at this late stage. Testing start dates get squeezed, and testers have to test more
and more as time begins to run out. It’s exhausting and demoralizing.

Now, consider an agile team. The team tests the work as it goes and has a series of
concrete steps to take. They have an unwavering focus on the end goal. Because
they are delivering value incrementally, each piece is usable and is a step in the
direction of the goal because they get constant stakeholder feedback about its
value. This way of approaching work means that the team establishes a steady
pace. It’s a much more even paced, satisfying experience.
Climbing a flight of stairs in one leap is about as difficult as delivering one giant
product release. Delivery in smaller releases is a much more sustainable approach.

9. Continuous attention to technical excellence and good design

enhances agility.
Agile teams should focus not only on feature development but also on ensuring that
they deliver high-quality products. This might include addressing any existing
technical debt and preventing its accumulation. Agile teams using the Scrum
framework might work with the Product Owner to include items that increase product
quality in the Product Backlog. Teams can also create a Definition of Done that
prevents the accidental accumulation of technical debt by implementing best
practices such as regular code reviews and security standards.
Why does this matter? The accumulation of technical debt can erode product quality
and make frequent, incremental delivery impossible, therefore impacting agility.

10. Simplicity—the art of maximizing the amount of work not done—is

essential.
Because Agile teams focus on smaller, more frequent deliveries, the attitude of the
business stakeholders towards the work often changes. Instead of asking for every
requirement they may need in the future, the agile team can instead focus on the
most valuable thing to do next. This kind of focus can significantly reduce waste, as
the agile teams build trust with their customers and stakeholders through frequent
delivery of working software.
Focus on the next most valuable thing to do next increases business stakeholder
trust through the frequent delivery of working software.

11. The best architectures, requirements, and designs emerge from

self-organizing teams.
The architecture for the product, which is the underlying structure and approach to
delivering the product, emerges along with feature delivery. Adhering to this
principle means that the team doesn’t disappear for six months while they figure out
the best long-term architecture. Instead, team members decide how best to build
the product while they build the product.
The idea of self-organization is that the people closest to the work are best and
figuring out how to do it.

12. At regular intervals, the team reflects on how to become more

effective, then tunes and adjusts its behavior accordingly.
I contend that adhering to this principle has the biggest impact on the happiness and
efficiency of an agile team over the long term. On a regular basis, the team aks
themselves, how it’s going and what changes should they should make. Then they
make those changes and repeat the process regularly. A series of small
improvements made over time is better than any single reorganization or process
improvement project.
Teams that embody this principle continuously improve the way they work together
and the product they deliver. Such teams have higher morale and greater
productivity—and isn’t that what it’s all about?

Conclusion
Revisiting the manifesto regularly is a useful exercise for teams as an additional
layer of accountability. If you’re wondering how your team can better live these
agile principles, discuss it at your team’s next Sprint Retrospective. One way to do
this is to place the 12 agile principles on a shared whiteboard. Then, ask the Scrum
Team members to brainstorm how to better embody these principles in their work
and interactions with the parent organization or business stakeholders. Next, vote
on one or two actionable improvements, and implement them as soon as possible.

The Scrum Master as a Servant-Leader

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is
aware of them and knows when and how to apply them, depending on situation and context.
Everything with the purpose of helping people understand and apply the Scrum framework
better.
Servant-leadership is fully in line with the Scrum values of courage, openness, respect, focus,
and commitment. It's the backbone of the Scrum Master role and therefore the most obvious
one to describe as first.

https://www.scrum.org/resources/blog/scrum-master-servant-leader?
gclid=Cj0KCQiAi8KfBhCuARIsADp-
A56W0SvDuPb1xAs49BKmgfVUDbKzUKrdvvB6cCJoJ8kGnKv7tnwD76UaAuBVEALw_wcB

What is servant-leadership?

It's a philosophy and a set of practices that enrich the lives of individuals, to build better organizations,
and ultimately create a more just and caring world. It's a transformational approach to life and work that
has the potential for creating positive change throughout our society. Servant-leadership focuses on
collaboration, trust, empathy and the usage of power ethically.

Servant-leadership is about:

 Serving others, not yourself

 Not leading by title
 Leadership that endures
 Helping people develop and perform as highly as possible
 Selfless management of team members
 Promoting genuine team ownership
 Harnessing the collective power of a team

What is a servant-leader?

"The servant-leader is servant first. It begins with the natural feeling that one wants to serve. Then
conscious choice brings one to aspire to lead. The best test is: do those served grow as persons: do they,
while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become
servants? And, what is the effect on the least privileged in society; will they benefit, or, at least, not be
further deprived?"

The servant-leaders objective is to enhance and increase teamwork and personal involvement. They
create a participative environment, empowering 'employees' by sharing power and decision-making.

A servant-leader:
  Focuses on building a foundation of trust
 Stimulates empowerment and transparency
 Encourages collaborative engagements
 Is an un-blocker and empathic person able to truly listen
 Shows ethical and caring behaviour, putting others needs first
 Is humble, knowledgeable, positive, social and situationally aware

The Agile Manifesto and servant-leadership

The characteristics of servant leadership can also be found within the Agile Manifesto[3]. The values
‘individuals and interactions over processes and tools’ and ‘customer collaboration over contract
negotiation’ clearly emphasize the focus on collaborative engagements, serving others (the team
members) and not yourself and boosting team performance by supporting individual growth.

Principles of the Agile Manifesto that also characterize servant leadership are:

 "Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done"
 "Business people & developers must work together daily throughout the project"
The Scrum Master as a servant-leader

The Scrum Guide[4] describes the Scrum Master as the servant-leader for the Scrum team. A Scrum
Master is not a master of the team, but a master at encouraging, enabling, and energizing people to gel as
a team and realize their full potential[5]. A Scrum Master is a servant-leader whose focus is on the needs
of the team members and those they serve (the customer), with the goal of achieving results in line with
the organization's values, principles, and business objectives[6].
As a servant-leader, the Scrum Master is responsible for:

 Setting up Scrum as a servant process, not a commanding process[7];

 Guiding the Development team towards self-organization;
 Leading the team through healthy conflict and debate;
 Teaching, coaching and mentoring the organization and team in adopting and using Scrum;
 Shielding the team from disturbance and external threats;
 Helping the team make visible, remove and prevent impediments;
 Encouraging, supporting and enabling the team to reach their full potential and abilities;
 Creating transparency by radiating information via e.g. the product and sprint backlog, daily
Scrum, reviews and a visible workspace;
 Ensuring a collaborative culture exists within the team.
 What do you mean by Agile?
Agile is an iterative project management and software development methodology that
enables teams to deliver value to clients faster and with fewer difficulties. An agile team
provides work in small, consumable pieces rather than putting all on a "big bang"
release. Requirements, strategies, and outcomes are all evaluated on a regular basis,
giving teams a natural method for adapting to change.

What do you mean by Sprint in Scrum?

A Sprint is at the heart of Scrum. It is a two-week or one-month period in which a potentially

releasable product increment is generated. Following the conclusion of the preceding Sprint, a
new Sprint begins. It breaks down large, difficult undertakings into manageable chunks. It helps
teams provide high-quality work faster and more frequently, making projects easier to manage.
Sprints provide them with more flexibility in adapting to changes.
Sprint planning, daily scrums, development work, Sprint review, and sprint retrospective are all
part of a sprint.

 The work to be done in the Sprint is planned collectively by the Scrum Team during Sprint
planning.
 The Daily Scrum Meeting is a 15-minute timed event in which the Scrum Team
synchronizes efforts and creates a strategy for the following day.
 At the end of each Sprint, a Sprint Review is held to review the Increment and, if necessary,
make modifications to the Product Backlog.
 After the Sprint Review and before the following , there is a Sprint Retrospective. The
Scrum Team will inspect itself and prepare a plan for changes to be implemented during
the next Sprint during this meeting.
Sprint Planningbusiness

What are the five Scrum values?

Following are the five Scrum values:
 Commitment: Scrum teams must be able to function as a team to accomplish a common
goal. This entails putting faith in one another to complete their jobs and deliver to the best
of their abilities. It will only occur if each team member is completely dedicated to the
project and the team.
Scrum masters and team leaders can aid commitment by facilitating good sprint
preparation and shielding teams from mid-sprint scope changes and undue product owner
pressure.
 Focus: Each member of the team must remain focused on the work at hand as well as how
it affects the sprint goal in order to get the most out of each sprint.
Scrum masters might limit the number of tasks or priorities assigned to each team
member throughout sprints to help them stay focused. Individuals can also stay focused
on their assigned work by encouraging full team participation in daily Scrum meetings.
 Openness: Each member of the team must be absolutely truthful about their personal
progress in order for the Scrum team to accomplish the maximum progress in the quickest
period possible. The daily Scrum meeting's goal is to identify and solve problems. That
won't happen if team members aren't honest about any problems or hurdles they're
facing. Team members must also be willing to collaborate with one another and see each
other as vital contributors to the project's success.
Being upfront with their teams is one of the finest methods for Scrum masters to foster
openness. Giving honest feedback at daily Scrum meetings is not only crucial for making
 required adjustments, but it will also inspire team members to be honest and open in
return.
 Respect: Respect in a Scrum team implies understanding that no single individual or their
contribution is more valuable than another. Respect also entails putting your faith in your
coworkers to complete their jobs, listening to and considering their suggestions, and
praising their achievements.
Scrum masters may assist their teams to develop regard for each other by exhibiting
respect for the product owner, stakeholders, and team members.
 Courage: Scrum teams must have the guts to be genuine, upfront, and honest about the
project's progress and any bottlenecks they encounter, both with themselves and with
stakeholders. Members of the team must also have the bravery to seek assistance when
needed, attempt new techniques or procedures that they are unfamiliar with, and
respectfully disagree and engage in open debate.
Scrum masters, like respect, can first and foremost promote courage by displaying it. To
avoid mid-sprint adjustments or scope creep, the Scrum Master must have the confidence
to stand up to stakeholders and product owners

What are the three pillars of Scrum?

Following are the three pillars of Scrum:
 Transparency: Those accountable for the outcome must be able to see important
components of the process. Transparency necessitates that those elements be defined by a
uniform standard so that viewers may comprehend what they are seeing. For example, all
participants must speak the same language when referring to the process, and those
performing the job and those inspecting the resulting increment must have the same
concept of "done."
 Inspection: To spot undesired deviations, Scrum users must examine Scrum artifacts and
progress toward a Sprint Goal on a regular basis. Their inspections should not be so
frequent that they become a hindrance to their work. Inspections are most effective when
performed diligently at the point of work by skilled inspectors.
 Adaption: If an inspector concludes that one or more parts of a process deviate beyond
acceptable boundaries, the method or the material being processed must be modified. To
avoid future deviation, an adjustment must be performed as soon as feasible

What is an USER STORY?

A user story is an informal, general explanation of a software feature written from the
perspective of the end user. Its purpose is to articulate how a software feature will provide
value to the customer.
The purpose of a user story is to articulate how a piece of work will deliver a particular
value back to the customer.
User stories are a few sentences in simple language that outline the desired outcome. They
don't go into detail. Requirements are added later, once agreed upon by the team.

How can you assure that the user stories meet the requirements?

A good user story comprises a description as well as set acceptance criteria. It should be a piece
that can be completed in a sprint and has the fewest dependencies possible. Within the sprint's
constraints, the team should be able to build and test while also delivering estimations. In a
nutshell, the INVEST principle is followed by good user stories.
  I stands for Independent - The user story should be such that the team members are less
reliant on others
 N stands for Negotiable - It should describe the functionality and is subject to agreement
between the Team and the Product Owner.
 V stands for Valuable - It should add value to the customer's experience.
 E stands for Estimable - It should be such that the time requirement can be
approximately estimated.
 S stands for Small - It should be small enough so that the team can complete it in a
sprint.
 T stands for Testable - It should have good acceptance criteria.

During backlog refinement or sprint preparation, the scrum master can assist the team in
producing good user stories so that they can be picked up for the commitment.
 Why are the user stories not estimated in man hours?

One of the most common approaches for evaluating teamwork is to estimate in man-hours.
While man-hours are simple to comprehend, they have a number of significant drawbacks:

 Few activities, such as legacy work, are difficult to estimate precisely.

 If one team member delivers the estimate but the task is completed by another, the
estimate is useless.
 The amount of time it takes to perform a task depends on the developer's level of
experience.
 Teams frequently overestimate the obstacles they may face and simply consider the best-
case scenario.

The benefits of estimating user stories in points include the following: There is no association
between the estimator's skills and experience, and story points are independent of the story's
author. The team members can estimate more correctly since story points are a measurement of
relative sizes, and the size of the story cannot be changed by external forces. As team behaviour
takes precedence over individual conduct, Story Points encourages collaboration. The team
comes together when they use planning poker to estimate story points. As teams exchange,
constructively criticize, argue, and have fun playing poker cards to arrive at an agreement on
estimations, it serves as a team-building activity.

What do you mean by Artifacts in Scrum?

Scrum Artifacts contain critical information that the Scrum Team and stakeholders need to know
in order to understand the product being developed, the activities that have been completed,
and the activities that are planned for the project. The Scrum Process Framework defines the
following artifacts:
 Product Backlog: The Product Backlog is a list of all the features, functionalities,
requirements, additions, and fixes that will be included in future releases of the product.
Description, order, estimate, and value are all properties of Product Backlog items. The
Product Owner is in charge of the Product Backlog's content, as well as its availability and
ordering.
 Sprint Backlog: The Sprint Backlog consists of the Product Backlog items chosen for the
Sprint, as well as a strategy for delivering the product increment and achieving the Sprint
Goal. It is the Team's projection of what feature will be available in the next Increment, as
well as the work required to turn that functionality into a working product Increment.
 Increment: The Increment is the total of all Product Backlog items accomplished
throughout a Sprint plus all preceding Sprint increments. The new Increment must be a
 working product at the end of a Sprint, which means it must be in usable form. Regardless
of whether the Product Owner decides to release it, it must be in functioning condition.
 Sprint Burn-Down Chart: The total work remaining in the Sprint Backlog can be totalled
at any point throughout the Sprint. The team keeps track of the overall work remaining for
each Daily Scrum to estimate the chances of meeting the Sprint Goal. The Team can
control its progress by keeping track of the remaining work during the Sprint. The Sprint
Burn-Down Chart is a method of tracking how much work the Scrum Team has done in a
given sprint. This has been shown to be an effective method for tracking Sprint progress
toward the Sprint Goal.

What are the five steps of Risk Management?

To manage risk, there are five essential measures to follow. They are as follows:
 Identification of Risk: The first step is to determine the risks that the company faces in its
current operational environment. There are numerous forms of risks, including legal risks,
environmental risks, market risks, regulatory risks, and so on. It's critical to recognize as
many of these risk variables as possible.
 Analysis of the Risk: It is necessary to examine a risk once it has been recognized. The
risk's scope must be assessed. It's also crucial to comprehend the relationship between risk
and other internal components. It is crucial to establish the severity and importance of the
risk by looking at how many business operations it affects.
  Ranking the Risk: Risks must be prioritized and ranked. Based on the intensity of the risk,
most risk management solutions have several risk categories. Risks that can result in
serious loss are ranked the highest, while risks that may cause some inconvenience are
rated the lowest.
 Treating the Risk: Every risk must be minimized or eliminated to the greatest extent
practicable. This is accomplished by contacting specialists in the field to which the risk
pertains. In a manual situation, this means calling each and every stakeholder and then
scheduling up meetings for everyone to talk about and debate the concerns.
 Reviewing the Risk: The risk is then reviewed to ensure that the risk has been eliminated
completely.

How are Epic, User Story and Tasks different from one another in the context of
Scrum?
 Epic - It is something so large that it will almost certainly not fit into a sprint, is unclear in
terms of client requirements, and should be split down into stories. Epics are often defined
at the early stages of product road mapping and then broken into stories in the product
backlog when additional information becomes available.
 User Story - A story is anything actionable that can be fit into a sprint. These are INVEST
criteria-based story points and definitions. By the end of an iteration, stories should give a
vertical slice of functionality to the client that is both valuable and complete. Typically,
stories are developed throughout the product development process, particularly prior to
iteration planning and throughout higher-level product road mapping.
 Task - They are the decomposed parts of a story that define how the story will be finished.
If needed, tasks can be estimated by the hour. Tasks are typically defined by the individuals
who execute the job, whereas stories and epics are typically developed by the customer.
Because tasks are temporary, they are produced within the confines of an iteration
 What do you mean by Sprint 0 and Spike?

The modest amount of effort put in to establish a rough skeleton of the product backlog is
referred to as Sprint 0. It also contains information on calculating product release dates. Sprint 0
is necessary for the following tasks:

 Creating a skeleton for the project, as well as research spikes

 Maintaining a minimalist design
 Creating a few stories completely
 Being lightweight and having a low velocity

The spike is a collection of activities that use Extreme Programming for research, design,
investigation, prototyping, and other purposes. It tries to mitigate the technical approach's risks
by assisting with the acquisition of knowledge in order to better comprehend requirements and
increase reliability.

Differentiate between Product Backlog and Sprint Backlog.

Product Backlog Sprint Backlog

It is a list of all the tasks that must be It is a list of all the items collected from the Product
done before the final product may be Backlog that must be done in order for the Sprint to
Product Backlog Sprint Backlog
be completed. It also has a strategy for converting the
created.
selected items to an Increment.
The Product Owner is in charge of The Development Team is in charge of developing the
gathering, prioritizing, and refining the Sprint Backlog and working on it in order to complete
Product Backlog items. the Sprint on time.
The Product Backlog is dedicated to the The Sprint Backlog solely pertains to the Sprint goal
product's overall goal. for that Sprint.
The Sprint Goal will not change throughout the Sprint,
Depending on the customer's vision, there
but the Sprint Backlog may change depending on the
may be opportunities to alter.
Sprint.
It has nothing to do with the Sprint
The Product Backlog is the sole determinant.
Backlog.
It is the entire set or list of tasks that must
It's a subset of the Product Backlog that gets finished
be accomplished in order to fully develop
in a Sprint.
the product.
The Product Backlog exists and must be
Every Sprint has its own Sprint Backlog, which expires
maintained until the entire product is
when the Sprint does.
developed.

What do you mean by DoD?

DoD stands for Definition of Done. It is the set of deliverables that contain written codes,
comments on coding, unit tests, integration testing, design documents, release notes, and so
on. This provides project development with quantifiable and demonstrable benefits. It is quite
beneficial to scrum when it comes to identifying deliverables that will assist the project reach its
goal.
It assists with:

 Identifying the steps necessary to complete the iteration.

 The use of appropriate technologies, such as burndown, to improve the efficiency of the
process.
 Providing timely input at all stages of the project's life cycle.
 Assuring that the product backlog items are properly walked through and understood.
 The establishment of a checklist for the backlog items in the product.
 Assuring that it is defined in such a way that it is task-oriented.
 Including the product owner in the sprint review and sprint retrospective.

What do you mean by ‘Confidence Vote’ in Scrum? Why is it important?

After the risk analysis, the Confidence Vote is conducted at the Program Increment Planning
session. It is when all members of the team meet together and raise their voices and vote with
their fingers on their confidence level in the completion of the PI Targets. Only when all of the
features and user stories have been appropriately estimated and prioritized can the confidence
vote be used. All of the work that is being done must be transparent to all parties involved, with
all dependencies and hazards clearly defined.
With a vote of confidence, you can create an environment where individuals feel free to share
and express their opinions. It boosts team members' morale since they should feel that their
opinions are respected

What do you mean by Scrum of Scrums?

Scrum of Scrums is a scalable agile technique for connecting several teams that must collaborate to
produce complicated solutions.
It enables teams to design and deliver complicated products at scale by facilitating transparency,
inspection, and adaption. It's especially effective when all members of a high-performing Scrum team
work toward a single purpose, have complete trust and respect for one another and are completely
aligned. It is a virtual team made up of delegates who are connected to the original delivery teams
via embedded linkages. These interconnected team architectures simplify communication paths
when compared to traditional organizational hierarchies or project-based teams. The goal is to
coordinate smaller, self-contained groups.

Differentiate between MVP and MMR .

Minimum Viable Product (MVP) is a Lean Startup concept that emphasizes the importance of
learning while developing a product. This enables one to test and understand the concept by
exposing target consumers and users to the initial version. To accomplish this, one must first
gather all pertinent data and then learn from it. The MVP concept is to create a product,
provide consumers access to it, and observe how the product is used, perceived, and
understood. This will also give you a better idea of what the needs of your clients or users are.

Successful products are released into the market in stages over time, with each "significant"
deployment referred to as a release. An MMR (Minimum Marketable Release) is a product
release with the minimal possible feature set that solves your customers' current new needs.
MMRs are used to shorten time-to-market between releases by condensing each release's
coherent feature set to the lowest increment that provides new value to customers

What are the three C’s in an User Story?

 Card: It is a written account of the story that is utilized to plan and estimate. To keep user
stories succinct, they are manually written on index "cards."
  Conversation: The Conversation is required to learn more about the Card. The
conversation encourages the agile team to work together in small steps to develop a
shared understanding of the problem and potential solutions.
 Confirmation: Confirmation is an acceptance criteria that contains the fundamental
requirements and turns them into test criteria so that we can determine when the user
story has been properly provided

What do you understand about Scope Creep? How can Scope Creep be
managed?

Scope creep describes how a project's requirements tend to grow over time, such as when a
single deliverable product gets split into five or when a product with three essential features
needs ten essential features or when the customer's needs change midway through a project,
prompting a reassessment of the project requirements. Scope creep is frequently caused by
changes in project requirements from key stakeholders, as well as internal miscommunication
and conflicts.
Controlling scope creep through a change control procedure is the key to managing scope
creep. This entails:

 Keeping track of the project's progress and establishing a baseline scope

 Using variance analysis to compare actual work performance metrics to the baseline scope,
i.e., "How different is the present project from the initial plan?"
 Identifying the source and severity of the observed changes
 Choosing whether corrective or preventive action is required in response to change
requests
 Using the Perform Integrated Change Control procedure, manage all change requests and
recommended actions (whether corrective or preventive).
 BRD & FRD
The main difference between BRD vs FRD is that BRDs focus on what the product should
do while FRDs focus on how the product should do it.

A business requirements document (BRD) is a formal contract between the client and
supplier that captures all the work in a project. A functional requirements document
(FRD) comprehensively defines the solution required to meet the business needs
identified in the BRD.

Main Differences Between BRD vs FRD

The main differences between BRD vs FRD are:

 The primary audience of a BRD is the business stakeholders, clients, and customers, whereas
the primary audience of an FRD is the development team, engineers, and testers.
 A BRD describes what the product should do, whereas an FRD describes how the project
should do it.
 A BRD intends to elicit requirements from the client, whereas an FRD intends to define
requirements for the development team.
  The format of a BRD is free form with a mix of text and visuals, whereas the format of an FRD
is more rigid, often using Unified Modeling Language (UML).
 A business analyst prepares the BRD document, whereas the business analyst prepares the
FRD under the supervision of a technical expert (i.e., an architect).

FAQs
Question: Are BRD and FRS/FRD the Same?

Answer: BRD and FRS are not the same. The main difference between a BRD and an FRD is that a BRD is a
high-level document that outlines the business goals, while an FRD is a more detailed document that
outlines the functional requirements for a system.

Question: What is the Difference Between a BRD and an FSD?

Answer: BRD stands for business requirements document, whereas FSD stands for functional specification
document. The difference between the two is that BRD outlines the business goals for a project, while
FSD describes the intended capabilities, interaction with users, and the overall appearance of the system.

Question: Who Prepares the FRD document?

Answer: A business analyst under the supervision of a technical expert such as a software engineer
prepares the FRD document. When creating an FRD, the business analyst uses information gathered from
the BRD and input from stakeholders and subject matter experts.
 Story points and estimation
Story points are units of measure for expressing an estimate of the overall effort required to
fully implement a product backlog item or any other piece of work.
1. Executive summary
TO BEGIN, YOU’LL NEED TO CREATE AN EXECUTIVE SUMMARY THAT PROVIDES AN OVERVIEW OF THE

ORGANIZATION AND THE CHALLENGES FACING THE BUSINESS. YOU’LL EXPLAIN THE ISSUES AND WHAT THE

ORGANIZATION IS TRYING TO ACHIEVE TO ENSURE EVERYONE IS ON THE SAME PAGE. THIS SECTION

SHOULD BE SHORT, LIKE AN ELEVATOR PITCH, SUMMARIZING THE REST OF THE BUSINESS REQUIREMENTS

DOCUMENT.

The executive summary is a high-level statement outlining what

your project is and its purpose.

Even though your executive summary is the first thing in your BRD, you should
actually only write it after writing the other sections. That way, you can
review everything and ensure you’ve created a comprehensive opening
statement.

2. Project objectives
Your project objectives are the business goals you want to achieve by putting
your project into action. It’s important to state your project objectives before
kicking off any work so you can use them to measure your progress.
List your project objectives as SMART goals to ensure that they’re:
 Specific
 Measurable
 Achievable
  Relevant
 Time-specific
Measuring your project objectives can help determine whether you need to
adjust your workflow to better meet your goals. For example, if one of your
objectives was to increase your customer base by 10% by the end of the
quarter, you can look at your numbers when the quarter ends and clearly see
whether you hit your goal or not. You can then look at the actions you took
along the way and determine the reasons why you may have fallen short.

3. Project scope
Your project scope communicates the boundaries of your project on your
business requirements document. By defining your project scope, you’ll keep
everyone on the same page and prevent scope creep, which is when your project
expands outside of the boundaries you set for it and becomes hard to
control.
Details to outline in your project scope include:

 Timeline
 Budget
 Deliverables
 Project requirements
 Project team
You can also make a list of project exclusions—or things you specifically want
to leave out of your project—like business processes or risky strategies you want
others to avoid when they’re working on the project

4. Business requirements
The business requirements are the meat of your BRD template. In this section,
you’ll list the actions required to accomplish your project. Depending on the
project complexity, this list may be just a few items or it may be extensive.

In addition to listing your requirements and describing them, rank them by

priority and assign each item a level of importance based on how critical they
are. This will help others understand which requirements they need to
complete first.

If one of your requirements is to code a website, you may assign this task as a
number one priority. You can also label this task as highly critical because,
without coding your website, you won’t have a foundation to complete other
business requirements.

5. Key stakeholders
Project stakeholders include anyone with an interest in your project. These
are likely the people who will read your BRD template to understand what the
project is about. Your key stakeholders may be:

 Team members working on the project

 Project managers leading the project
 Executives approving the project
 Clients influenced by the finished project
In this section, list the names and job roles of each stakeholder and describe
their duty in relation to the project. This section will give everyone clarity on
who else is involved and can improve team communication.

6. Project constraints
You likely presented an overview of your project constraints within your project
scope, but here, you’ll explain these boundaries in more detail. When the
reader reviews this section, they should see the shape of the project and its
limits.
Project constraints may include:

 Project risks
 Team availability
 Resources
 Project dependencies
 Deadlines
  Project budget
Project constraints help stakeholders visualize the complexity of the project
and how easy it will be to achieve project objectives. Anyone involved in the
project should first review the project constraints.

7. Cost-benefit analysis
Ending your business requirements document with a cost-benefit analysis is a
strategic move. If you’re using your BRD to get approval for your project, this
section may be the deciding factor. Clients and executives care about the
project objective, but if you can’t prove that you’ll make a profit, then all is
lost.
To create a cost-benefit analysis:

 Describe all the costs associated with your project

 Explain the associated benefits
 Write the total expected cost of your project
 Estimate the expected ROI by subtracting your estimated costs from your estimated income
What is a Functional Requirements Document
(FRD)?
An FRD or Functional Requirements Document serves as a contract for formal statement,
between the business stakeholders and the technology team, on an application’s functional
requirements. The FRD is produced by business analysts or sometimes the technical team
in response to the business requirements (captured in a BRD – Business Requirements
Document).

The key purpose of an FRD is to translate business needs into technological functions in a
system. It’s where project stakeholders and the technical development team meet. The
creation of the FRD facilitates and ensures collaboration between business and technical
stakeholders

The FRD / FRS includes all or part of the following sections:

1. Introduction
1.1 Purpose of Document
1.2 Project Summary
1.3 Background
1.4 Project Scope
1.5 System Purpose
1.5.1 Users
1.5.2 Location
1.5.3 Responsibilities
 1.5.4 Need
1.6 Overview of Document
2. Functional Objectives
2.1 High Priority
2.2 Medium Priority
2.3 Low Priority
3. Non-Functional Objectives
3.1 Reliability
3.2 Usability
3.3 Performance
3.4 Security
3.5 Supportability
3.6 Online user Documentation and Help
3.7 Purchased Components
3.8 Interfaces
4. The Context Model
4.1 Goal Statement
4.2 Context Diagram
4.3 System Externals
5. The Use Case Model
5.1 System Use Case Diagram
5.2 Use Case Descriptions (for selected cases)
6. User Stories
7. Appendix
Glossary
Use Cases Model and Use Cases
Use cases describe the interaction between the system and external users that leads to
achieving particular goals.

Each use case includes three main elements:

 Actors: These are the external users that interact with the system.
 System: The system is described as functional requirements that define an
intended behavior of the product.
 Goals: The purposes of the interaction between the users and the system are
outlined as goals.

There are two formats to represent use cases:

 Use case description

 Use case model (diagram)

A use case specification represents the sequence of events along with other information that relates to this
use case. A typical use case specification template includes the following information:

 Use Case Name

 Summary
 Basic Flow
 Alternative Flows
 Extension Points
 Preconditions
 Postconditions
 Business Rules
A use case diagram doesn’t contain a lot of details. It shows a high-level overview of the relationships
between actors, different use cases, and the system.

The use case diagram includes the following main elements:

 Use cases. Usually drawn with ovals, use cases represent different interaction scenarios that
actors might have with the system (log in, make a purchase, view items, etc.).
 System boundaries. Boundaries are outlined as boxes that groups various use cases in a
system.
 Actors. These are the figures that depict external users (people or systems) that interact with
the system.
 Associations. Associations are drawn with lines showing different types of relationships
between actors and use cases.
<<INCLUDE>> -- Defines the necessity which needs to perform before attending other Use case
<<EXTEND>> -- The extend relationships are important because they show optional functionality or
system behavior. The <<extend>> relationship is used to include optional behavior from an extending
use case in an extended use case. Take a look at the use case diagram example below. It shows an
extend connector and an extension point "Search".

Communication Link
Use Case Example - Generalization Relationship
A generalization relationship means that a child use case inherits the behavior and
meaning of the parent use case. The child may add or override the behavior of the parent.
The figure below provides a use case example by showing two generalization connectors
that connect between the three use cases.

Use Case Diagram - Vehicle Sales Systems

The figure below shows a use case diagram example for a vehicle system. As you can see
even a system as big as a vehicle sales system contains not more than 10 use cases! That's
the beauty of use case modelling.
The use case model also shows the use of extend and include. Besides, there are
associations that connect between actors and use cases.
Swimlane Diagram:
User Stories – What are they, and the need for it
The Agile Alliance describes user stories as work that is divided up into functional
increments. User stories are developed and represented in a format that emphasizes the
value to the end user of the system. A typical user story describes three components:

1. The end goal for the user to use the system. This is the most important factor
when it comes to developing functional requirements. Always begin with the
end in mind; the value being delivered to the user. For example, the ability to
order products (ecommerce like Amazon), track deliveries (ecommerce like
Flipkart, Alibaba), enjoy relevant content (streaming like Netflix, Spotify, Zee or
social media like Instagram, TikTok), interact with people (messaging or social
media apps like Twitter, Facebook, Whatsapp), etc.
2. The action that the user intends to perform, which when performed will lead to
the goals being achieved (point #1). For example, placing an order, making
payments, reviewing products, navigating pages, etc.
3. The user role or type of user. For example, user roles may be customers,
prospects, administrative users, etc.

Format of a user story

User stories are modelled on the following lines:

As a (role) I want to do (something) so that I can (benefit).

INVEST in a good user story
INVEST in an acronym that serves as a guideline for us to generate clear and useful user
stories, and functional requirements in general.

The INVEST for a good user story stands for:

 “I” – Independent (of all other user stories)

 “N” – Negotiable (not a specific contract for features; the user story can be
modified without much ado)
 “V” – Valuable (its creation should add value to the user)
 “E” – Estimable (to a good approximation)
 “S” – Small or Size Appropriate (so as to fit within an iteration or sprint)
 “T” – Testable (the user story should create something tangible that can be
tested / verified, even if there isn’t a test for it yet)

 The INVEST checklist for evaluating user stories originated in Bill

Wake’s 2003 article, which also utilized acronym SMART (Specific, Measurable,
Achievable, Relevant, Time-boxed) for deliverables resulting from the
decomposition of user stories.
 The INVEST acronym was one among the techniques recommended in Mike
Cohn’s “User Stories applied“, which discusses the concept at length in
Chapter 2.
What does INVEST for good user stories stand for?
Frequently Asked Questions about the
Functional Requirements Documents (FRD)
1. Who creates the functional requirements documents (FRD)?

The business analyst (BA) usually is the one who creates the FRD. The BA is best
suited to propose a functional solution because of their deep understanding of
the domain and the business needs.

2. When is the functional requirements documents (FRD) created?

The development of the functional requirements document (FRD) generally

occurs after the finalization of the business requirements in the form of the
BRD.

3. What is the use of the functional requirements documents (FRD) for

downstream processes?

The FRD serves as a basis for all subsequent project development activities
including the development of detailed system designs, technical
specifications, and test cases.

4. How can the functional requirements documents (FRD) be used in software

testing?

The development of test cases primarily relies on the FRD as the best source of
information. This is applicable for system integration testing (SIT) and user
 acceptance testing (UAT). Expected behaviors of the system, along with impact
implications are derived from the FRD.

What Is Requirements Gathering?

Requirements gathering is the process of identifying your project’s exact

requirements from start to finish. This process occurs during the project
initiation phase but you’ll continue to manage your project requirements
throughout the entire project timeline.

Requirements gathering, or requirements elicitation, is the process of determining all

the requirements of a project. There are two main types of project requirements,
business and technical requirements.

Business requirements define what an organization will accomplish with the project,
while technical requirements explain how the project must be executed. They’re
gathered during the initiation phase of the project life cycle, but project managers need
to monitor them throughout the project timeline, as they can change.

Truly effective requirements gathering and management is started at the very

beginning of the project, and must answer the following questions:
  How long will the project timeline be?
 Who will be involved in the project?

 What are the risks for the requirements gathering process?

 What is our ultimate goal in understanding our project

requirements?

 What are our technical and business requirements?

Why is Requirements Gathering Important?

Remember back to the last project you managed. What were the risks that came to
light? Which resources did you run out of? Was there any scope creep or budgetary
mishaps? And overall, what were the impacts of those shortcomings on the project as
a whole?

Deadlines, scope, cost overrun—without proper requirements identification at the

outset, all of those elements will be affected. Design issues to the product will be
impacted, and developmental delays will occur. Ultimately, your product won’t be set
up for optimal success as it faces an overrun budget
Requirements Gathering Process

So, how do you gather requirements in the most effective and manageable way
possible? Typically, requirements gathering is made up a few discrete steps.

1. Appoint and Assign

First things first: who’s going to be the person that tells everyone you’re the project
manager? Ensure that that person understands why this role is so important—
everyone must go to you with all project updates, as you will act as the knowledge
center for project progress.

You’ll also want to identify who the key stakeholders will be. These will be the people
who brainstorm, analyze, approve or deny project updates. They’re typically made up
of customers, team leads, department managers, board members, business partners
or manufacturers. They’ll have the most say in the progress of the project overall.

2. Elicit Requirements & Interview

Next, you’ll want to interview all of the stakeholders that you identified. Ask them
questions like:

 What is on your wishlist for this product update?

 What is your ultimate goal for this project?

  What do you wish this product would do that it doesn’t already?
 What got you interested in this product in the first place?

 What changes would convince you to recommend this product to

others?

 What tools would you need to make this project successful?

 What are the concerns you have for this project process?
3. Gather and Document

Write absolutely everything down. Write until you can’t write anymore. Record every
single answer, and create an easily-accessible repository where (approved) others
can access if they need to reference any information that was collected during the
requirements gathering phase.

Not only will this documentation be helpful at the end of the project when you reflect
back on goals achieved, updates accomplished, features added and bugs fixed, it will
also act to help manage stakeholder expectations, and keep team members focused
and on track.

4. List All Assumptions & Requirements

This is the meat of the process. Once you’ve documented everyone’s goals and
expectations, you can create a requirements management plan that’s actionable,
measurable and quantifiable.

During this phase you’ll answer:

 How long will the project timeline be? Map out your
timeline, and then map out your requirements on that timeline. This
will help in case some requirements are contingent on
dependencies.

 Who will be involved in the project? Will it be the entire design

and development teams, or just a select few from each? Which
team members will be available? Which team members specialize
in the types of issues the project will tackle?

 What are the risks for the requirements gathering

process? Define all assumptions, and document all risks that
might impact your requirements. Understand that your assumptions
are typically divided into three categories: time, budget and scope.
They can range from assuming PTO, holidays and sick days, to
assuming stakeholders will provide feedback in a timely manner.

 What is our ultimate goal in understanding our project

requirements? What is the time-based goal, the budget goal and
the scope goal? Will it be to compete in the market more directly
 with a competitor? Will it be to solve a customer problem, or fix a
bug?

By answering all of the questions above in a clear and concise manner, you’ll have a
full map of your requirements ready to present to stakeholders.

5. Monitor Progress

Once you’ve gotten stakeholder approval on the requirements you’ve presented, you’ll
implement them into the project timeline and process. At this point, you’ll want to make
sure you have a method in place to monitor and track all of your requirements across
all teams to ensure that triggers for risk stay low.

You’ll also want to use this data to report project progress to stakeholders, give
feedback to department managers, and ensure the project is on track from a time,
scope and budget standpoint.
Requirements Gathering Techniques

Now that we know what requirements gathering is and we’ve explored the steps of the
requirements gathering process, you’ll want to have good sources from which to get
them. The primary sources are stakeholders, such as customers, users, et al. Other
sources could include experts, analysts and information about competitors.

Once the sources have been identified, there are a number of techniques that can be
applied to gather the requirements. This is an iterative process and no one
requirements gathering technique is going to do the job by itself. You’ll need to use as
many as you feel necessary. Here are some of the top requirements gathering
techniques.

Use Case Scenarios

A use case is a document that explains how users will perform tasks on your product.
It is written from a user’s point of view and done in steps that include: who’s using the
product, what they want from the product, the user’s goal, the steps they take to
accomplish their task and how the product responds to their action.

Brainstorming

Conduct a brainstorming session with a group of participants who can say whatever
they want about the product as long as they feel it’s important. Have a facilitator lead
the group, organizing and prioritizing their responses. Start by explaining the objective
of the brainstorming session, get the group to provide as many ideas as possible,
don’t criticize or debate and when done gather all the information.

Mind Mapping

Mind mapping is another way to gather ideas. It involves creating a mind map, which
starts by placing the central idea in the center of a page. Then use lines, arrows,
speech bubbles and different colors to show the connection between the central
theme and the ideas that stem from it. It allows for an organic development of ideas
relating to your central idea. It shows how different facts are related.

Requirements gathering
techniques
While the basic process of requirements gathering involves asking
stakeholders for their input, sometimes stakeholders won’t know what’s best
for a project. In those cases, you're responsible for gathering the information
necessary to understand what your project requirements should be.
Requirements Gathering Techniques:

1) Interviews: These are most commonly used and valuable technique. In this
technique Business Analyst asks certain questions from clients/stakeholders,
regarding their requirements. Business Analyst should make sure that
interviews cover diverse cross-section of different stakeholders.
After unstructured, the next step should be Structured interviews. In
Structured Interview, Business Analyst uses a prepared set of questions to
gather requirements from stakeholders.
2) Questionnaires: The technique is an electronic or paper based approach of
collecting needs from stakeholders. Questionnaires are distributed among
stakeholders. Questionnaires list all the questions relevant per a particular
process. Questionnaires are good technique to gather requirements from
remote locations. Questionnaires are appropriate method to gather input
from huge number of people.

3) Prototyping: Sometime stakeholders don't have clear understanding

about their requirements. In such scenario, several different prototypes are
constructed with available requirement sets. It helps the clients to understand
the system and further requirements. You need to repeat the process until the
application meets the major requirements.

Focus Group
A focus group is a gathering of people who are representative of the users or customers of a product to get
feedback. The feedback can be gathered about needs/opportunities/ problems to identify requirements, or
can be gathered to validate and refine already elicited requirements. This form of market research is
distinct from brainstorming in that it is a managed process with specific participants.

Requirement workshop
Requirement workshops are a great way to gather information and as a facilitator, it is
important to be prepared for the session to go well. Gather and prepare materials and an
agenda to give structure to the workshop—this helps ensure you get quality insights. Know
who is attending the workshop to get the most out of it and plan better knowing what each
person's expectations are. Consider meeting some attendees ahead of time to know how
their personalities and work styles will integrate and to understand their views of where
they see the project going.

This method often requires the most planning and preparation, and since you can't always
have the right people in the room together, it is wise to run a few workshops to get the
most requirement information gathering possible. It also typically takes the longest,
though the quality of the information is high.

#Guidelines for Requirement Gathering:

Here are the few guidelines that can help the Business Analyst to capture complete, correct
requirements:
1) Pick the Interview Groups wisely. Business Analyst should consider various factors while group
selections: Technical Maturity, Business Process Knowledge, Specialization, Interest, Departments,
Organization sections, and Time Availability.
2) Before starting the Requirement Gathering, it’s good to summarize/introduce the project and
associated purpose, to avoid misconceptions of teams involved in this phase.
3) Business Analyst should follow up each question with a set of clarifying questions to dig it
further.
4) Always take collaborative approach while gather the requirements.
5) Keep the questionnaire descriptive and simple to understand.
6) Initially, ask the Vendors for the list of requirements with associated details. This will help
Business Analyst to frame questions.
7) Carryout the Polls, so that users rank their needs, and have a place to provide feedback.
 REQUIREMENT GATHERING
Requirements gathering is the process of understanding what you are trying to build and why you are building it.
Requirements gathering is often regarded as a part of developing software applications or of cyber-physical systems like
aircraft, spacecraft, and automobiles (where specifications cover both software and hardware). It can, however, be applied
to any product or project, from designing a new sailboat to building a patio deck to remodeling a bathroom.

Three Main Subprocesses of Requirements

Gathering
The key ingredients of the requirements gathering process are three overlapping subprocesses: requirements elicitation,
requirements documentation, and requirements understanding.

Requirements elicitation is the process of asking for and collecting top-level requirements from all relevant
stakeholders. Effort should be made to account for the needs of customers, their users, the internal stakeholders within
your own company, and your key suppliers.
Requirements documentation organizes the input from the requirements elicitation process into whatever format
is appropriate for your organization. This formatting may include:
 User stories
 Functional decompositions (especially for complex cyber-physical systems)
 Feature descriptions
These will be collected in a top-level requirements specification like a product requirements document (PRD) or a system
specification. The purpose of this top-level specification is to make those stories and descriptions available to all members
of the project team.
Requirements confirmation is the process of making sure all stakeholders and team members have a common
understanding of what you’re trying to build. This involves reviewing and refining the requirements. It will very
likely require additional elicitation and revision of the documentation as well.

A 6-Step Requirements Gathering Process

The requirements gathering process consists of six steps. Three of those (steps three through five—the
bulk of the process) we’ve already mentioned as the key subprocesses of requirements gathering. The full
six steps are:

 Identify the relevant stakeholders

 Establish project goals and objectives
 Elicit requirements from stakeholders
 Document the requirements
  Confirm the requirements
 Prioritize the requirements

It is important to note that while these steps are typically initiated in the order listed, there is a great deal
of overlap and iteration among them. It may, therefore, be better to think of them as subprocesses rather
than steps as we look at each one individually.

Identify the Relevant Stakeholders

Find qualified representatives from each relevant stakeholder group. Depending on your
project, these may include:

 Customers stakeholders
 Decision-makers
 Users
 System administrators
 Other impacted customer departments
 Internal stakeholders
 Executives
 Engineering
 Marketing
 Saless
 Customer support (including on-site maintenance teams, if applicable)
 Key suppliers
  Distributers and other partners

Remember to search for “hidden stakeholders.” Ask probing questions in early meetings, before you
begin eliciting requirements. Identify all stakeholder groups who need to be involved. Ideally, you want
input from every group who has skin in the game; give them all the opportunity to state their needs.

Establish Project Goals and Objectives

What are you trying to achieve with this new product or project? What are the overall outcomes your
customers want from the product? What are your company’s business goals? What are the actionable,
measurable objectives you need to achieve to realize those goals and outcomes?

Write them down. State them clearly, and get all your stakeholders to sign-off on them. Your goals and
objectives will act as a framework for your decision-making.

Each requirement you write should help satisfy a project objective and accomplish a goal. If it
doesn’t, you should either discard it or made it a candidate for a future release.

Elicit Requirements From Your Stakeholders

This is the first of three requirements gathering subprocesses which are highly iterative and
overlapping. Even in an agile environment, you are likely to go through several cycles of elicitation,
documentation, and review/confirmation before you achieve a workable specification to begin
development.
Elicitation can be performed in several ways. Time-tested techniques include surveys, questionnaires, and
interviews. Interviews and follow-up meetings will be prevalent during later iterations.

Be sure to listen actively during interviews. Ask probing questions and take copious notes. Afterward,
organize your notes and follow up as necessary. Document each exercise or encounter thoroughly.

Document the Requirements

As soon as requirements begin to emerge from your elicitation process, start documenting them.

Write them down and collect them in whatever format your organization has agreed upon. That
could be a product requirements document (PRD) of your company’s design, a government-
mandated system requirements specification, a vendor-supplied requirements
management (RM) tool like Jama Connect, a spreadsheet, a database, or any
other appropriate repository your entire team can access.

What’s most important is that the requirements documentation…

 Can be easily navigated and understood by your team

 Is available for review by all stakeholders
 Provides a facility for traceability to other documentation.

Templates are extremely useful, both for the specification as a whole and for individual
requirements. Solid, battle-tested templates and standardized formats help provide clarity and aid
navigation.

Confirm the Requirements

Review the requirements with all stakeholders. Make sure the requirements clearly capture what was
intended and that all parties have a common understanding of each of them. If you find any ambiguity in
a requirement, revise it.

You should also validate your requirements through prototyping and testing, where possible. Modern
prototyping tools make it fast and easy to create a working model of your specification. You can then use
that model to perform feasibility, usability, and product concept testing.

Get stakeholder sign-off on individual requirements as you get them nailed down. Do the same
for the specification as a whole during a final review.

Prioritize the Requirements

Most engineering development programs run into unexpected challenges along the way. Unanticipated
obstacles are encountered. Schedules slip. Priorities change. It’s important to be able to adapt to those
challenges and changes.

That’s why it is crucial to prioritize your requirements based on how each will impact your goals and
objectives for your release.

Many product managers prioritize features by tagging them with labels, such as “must have,” “high
want,” and “nice to have.” But it’s also important to rank order each requirement within those categories.
There are two reasons for this.
The first is time to market. Schedules often slip. When they do, you may need to trim features and
requirements to meet your release date. You don’t want your team implementing the easiest
requirements first only to find that there’s not enough time to complete all your must-haves.

The second reason is that requirements evolve. During implementation, you’re likely to discover new
needs. Some may be critically important and supersede existing requirements in terms of priority. You
need to know where those new requirements fit in your pecking order. If you don’t, less important factors
will determine what gets implemented first, which may have an adverse impact on your product’s
success.

LIVE SCENARIOS OF REQUIREMENT GATHERING

EX: SOFTWARE TO MANAGE ALL THE ACTIVITIES IN THE SCHOOL:

 Can I please know what is the actual requirement? – (Need of the Business requirement)
 Can I know who are the potential users of this software? -- Students, Teachers, Parents, Admin
and Management
 What are the capabilities of each user should have in the software?
** They should be able to Login & Reset Password
** They should be able to view class & Exam Timetable
** They should be able to communicate with teachers/management through char feature
** They should be able to view and submit their home-works/projects
** They should be able to view their attendance
 ** They should be able to view their exam results

 What is the preferred type of username should student should have? – I would prefer student
email id as a preferred username to Login
 Do you have any preferred steps which student has to go through to reset their password? – He
should receive password reset link to his email id
 Do you need to have a capability for students to download timetable, attendance and Results? –
Yes I need download capability
 Do you need a capability where student can request for leave from student module? I don’t
want student to request leave in Student module.
 Do you need to send a notification to student email id when Home-work or results are updated
by the teacher? – Yes I need
 Do you want capability where student can pay fees through student module? – No I don’t want
to have payment capability in student module, I would wish to have it in parents module which we
will discuss when we talk about Parents module requirement.
 Can I know how many students may use this software? – Approximately 1000 Students
 What is the age limit of this student? – Only students above 14 can use this software
 Do you need mobile app for this software? – No I don’t need a mobile app but please make sure
this software is mobile responsive so that the user can access it on mobile browsers as well.
 Do you have any preferred coding language to built this software? – No you can build it any
language which is feasible for your team
  Do you want the entire product to be delivered at One time? - No I don’t want to wait till the
entire product is developed. I would like to implement module by module based on user type, so
that I can see working product as soon as possible which will add business value to us.
 In this case, what is the priority? – Yes I want student, parent, teacher, admin and Management
module to be delivered one after the other in order. Hmm…. I just remember one thing, I need a
capability where student can view and download recorded Zoom class which may be useful during
pandemic situations.
 Anything else which you would like to add in the requirement? - As of now nothing and if any
requirement comes I will contact you.
 Sure, Since we work on agile principal, we can accommodate changes at any time during the
product development.—That’s great.
 Ok, I have noted all the requirements and further communicate the requirement with the
development team and will start the work as soon as possible – Thank you I have one request.
Can you demo the work completed so that I will know everything is going according to the
requirement.
 Sure will do thatIf you have any doubts you can reach out to me at [email protected]

Please capture the requirement for other modules in a similar way.

Once all the requirements are done, then capture all these in step-by-step EPIC, User
Stories etc.,
Main Documents to be prepared by Business Analyst?

 BRD
 FRD
 User Stories
 Use Cases
 Test Cases
 Release Document

What is business modelling?

Business modelling is a step- by -step approach for identifying the value proposition for operating the
business.

The key attributes of business modelling to develop a strategic plan for an organization are:

 Vision

 Mission

 Objectives

 Strategies

 Action plan

What are personas, and how they are useful in user-centred design methodology?
Personas are created in place of real users to understand their behavioural patterns in different scenarios. In
user-centred design methodology, a system is developed, keeping the viewpoint of end-users in mind.
Personas help create such systems.

During the development of a system, how do you manage frequently changing customers'
requirements?

It is one of the most frequently asked business analytic interview questions. The first task of a business
analyst is to draft a document stating the number of changes that are allowed, and after a certain point, no
amendments will be accepted. It is vital to get this document signed by the user.

In case the change required is accepted, make sure to note down all the changes and find out their overall
impact on the project. Calculate the timeline, cost, and resources needed for this change

What is Scope creep and how can you avoid Scope creep?

Scope creep is a problem that can occur during the development of a project, when the scope of the project
gradually expands beyond its original parameters. This can happen for a variety of reasons, such as changes
in the requirements or objectives of the project, or simply due to poor planning.

Avoiding scope creep can be difficult, but it is essential in order to keep a project on track. One way to do
this is to have a clear and concise definition of the project's scope from the outset, and to make sure that all
stakeholders agree on this definition. It is also important to have a well-defined change management
process in place, so that any changes to the scope are carefully considered and approved by all relevant
parties. Finally, regular communication with all stakeholders can help to ensure that everyone is aware of
the project's current parameters and objectives.

If you are experiencing scope creep in your own project, it is important to take action to address the
problem as soon as possible. Allowing the scope to continue to expand unchecked can lead to significant
delays and cost overruns, and can ultimately jeopardize the success of the project.

What are non-functional requirements and how do you capture them?

Non-functional requirements are those that specify conditions that a system must meet in order to be
successful. They are often contrasted with functional requirements, which detail the specific behaviours
that a system must exhibit.

There are many different types of non-functional requirements, but some common ones include
performance, security, scalability, and usability. Capturing these requirements can be challenging, as they
are often less well-defined than functional requirements.

One way to approach this is to think about the different types of users that will be using the system, and
what their specific needs are. For example, if you are building a website, you will need to consider the
needs of users with different levels of internet access speed, as well as those with different levels of
computer literacy.

Another way to capture non-functional requirements is to use scenarios. Scenarios are stories that describe
how a system will be used in a real-world setting. They can be useful for uncovering unanticipated
requirements, as well as for helping to define the acceptable limits of system performance.
Overall, non-functional requirements are an important part of any system development project. By taking
the time to think about the different types of users that will be using the system, and by using scenarios to
capture real-world usage, you can ensure that your system meets the needs of all its users.

35. Which documents are used to capture non-functional requirements?

There are a few different types of documents that can be used to capture non-functional requirements. One
type of document is called a Use Case. Use cases can be used to capture information about how a system
should work and what its capabilities should be. Another type of document that can be used to capture non-
functional requirements is called a Business requirements document. This type of document can be used
to capture information about the business goals of a system and what functions it should perform. In
addition, technical specifications can also be used to capture non-functional requirements. These types of
documents can be used to capture information about the technical details of a system and how it should be
implemented.

What is an activity diagram and what are the important elements of it?

An activity diagram is a graphical representation of the sequence of activities that take place in a system.
The main purpose of an activity diagram is to model the flow of control within a system.

There are four important elements that should be included in an activity diagram:

1. Activities: These are the actions that take place within the system.

2. States: These represent the different states that an activity can be in.
 3. Transitions: These indicate the order in which the activities take place.

4. Objects: These are the objects that are affected by the activities.

What is the difference between exception flow and alternate flow?

The main difference between exception flow and alternate flow is that exception flow deals with
unexpected events that occur during the execution of a program, while alternate flow deals with expected
events.

Exception flow is used to handle errors or unexpected conditions that may occur during the execution of a
program. Alternate flow is used to specify the order in which different parts of a program are executed.

Exception flow is typically used to deal with errors, such as unexpected input from a user or an unexpected
condition that occurs during the execution of a program. Alternate flow is typically used to specify the
order in which different parts of a program are executed. For example, alternate flow can be used to specify
that one part of a program is executed if a condition is true, and another part of the program is executed if
the condition is false.

Exception flow and alternate flow are both important concepts in programming. Exception flow is used to
deal with unexpected events that may occur during the execution of a program, while alternate flow is used
to specify the order in which different parts of a program are executed.

Do you think a business analyst should be involved in testing?

There is no one-size-fits-all answer to this question, as the level of involvement of business analysts in
testing will vary depending on the specific project and organization. However, in general, it is beneficial
for business analysts to be involved in testing, as they can provide valuable insights into the requirements
and help ensure that the final product meets the needs of the business.

What is BPMN and what are its basic elements?

BPMN, short for Business Process Model and Notation, is a standard graphical notation used to model
business processes. BPMN was created to provide a common language that both business users and
technical developers could use to document and communicate business processes.

The basic elements of BPMN are:

 Event: An occurrence that triggers a process

 Gateway: A decision point in a process

 Activity: A task that needs to be performed

 Data Object: Information that is required or produced by an activity

These elements can be combined to create a visual representation of a business process. BPMN diagrams
are typically used to model processes that are repetitive and have well-defined start and end points.
However, they can also be used to model more complex processes that are less structured.

BPMN diagrams can be created using a variety of software tools. Some of these tools are designed
specifically for creating BPMN diagrams, while others are general-purpose diagramming tools that support
BPMN.

BPMN is a powerful tool for modeling business processes. It can be used to document and communicate
processes, and to identify potential improvements. When used correctly, BPMN can help organizations to
improve their efficiency and effectiveness.

What is Benchmarking?

Benchmarking is the process of comparing the performance of a company or individual against others in
the same industry. This can be done in terms of specific metrics such as profitability, productivity, or
customer satisfaction. Benchmarking can also be used more broadly to compare any aspect of a business's
operations.

The main purpose of benchmarking is to identify areas where a company can improve its performance. By
understanding how others in the industry are operating, a business can develop strategies to better compete.
Benchmarking can also help companies keep track of their own performance over time and ensure that they
are making progress towards their goals.

What do you know about Kanban?

Kanban is a popular system for managing workflows, and has been used in a variety of businesses and
industries. It is based on the Japanese word for "sign" or "card," and was originally developed as a way to
manage assembly line production in manufacturing.

Kanban has since been adapted for use in other industries, and has been found to be helpful in managing
workflows in a variety of businesses. In recent years, it has become popular in the software development
industry as a way to manage agile software development.

Is there any difference between incremental and iterative development?

Both incremental and iterative development are software development processes that focus on delivering
small, frequent updates rather than large, infrequent ones. The main difference between the two approaches
is that incremental development delivers functionality in small,

discrete chunks, while iterative development focuses on delivering larger pieces of functionality
incrementally.

Difference between extreme programming and scrum?

There are a few key differences between extreme programming (XP) and scrum. The most notable
difference is that XP focuses on code quality and customer satisfaction, while scrum emphasizes delivering
working software quickly. Additionally, XP requires developers to work in close collaboration with
customers, while scrum relies on input from a product owner. Finally, XP uses a "test-first" approach to
development, while scrum employs an "iterative and incremental" approach. Despite these differences,
both XP and scrum are agile software development frameworks that emphasize collaboration, customer
involvement, and iterative development.

API(APPLICATION PROGRAMME INTERFACE)

An Application Programming Interface (API) allows software applications to interact with each other. It
is a fundamental part of modern software patterns, such as microservices architectures.

An API is an application programming interface. APIs are a set of protocols that enable

different software systems to connect and share data.

What Is API Integration?

For example, ask Siri or Google Assistant to play a song right now on your phone. There’s a
good chance that digital voice is connected through an API to a music program on your phone
that’s willing to fetch the song you asked for.
This operation takes place when Siri or Google Assistant’s API interacts with the API of your
music program. In this way, APIs work as software intermediaries between two or more
technologies.

‘API integration’ is an explicit means of describing this connection. And as you can see,
this can be a very critical part of any technical endeavour.

The simplest way to explain APIs is that while the user interface is meant for the user, a human
being, APIs are made for the entirety of the application or the computer.

To elaborate, the human accesses the application. In web applications of websites, the API lies
between the application and the server and responds to the human user accessing the
application after they make a certain request.
Using the predefined protocols APIs are by definition given, the API will ask the server to
fulfill the user’s request. To put it frankly, APIs are the middlemen of software.

They’re the waiter collecting your orders and serving them up to the kitchen, making
sure you get your food fresh and hot!
Why Are API Integrations Important?
API integrations give modern businesses the tools they need to be successful. Alright, maybe
you’re not the kid behind Siri or Google Assistant, so knowing the ins and outs of API
integration is not of use to you in that regard.

But if you’re managing a tech startup or any other company for that matter, you’ll probably run
into API integrations one way or the other.
If you want to build an application of any kind, mobile or web, APIs will play a crucial
role. Representational state transfer (REST) APIs, particularly, are integral for using
networks.

How To Build API Integrations

Building an API integration is much like developing a regular old software application. It
requires dedication and skill. There are four essential steps that you should account for.

Research
Any endeavor you’ve undertaken whole-heartedly likely involved some research. APIs are no
different. You need to get a fundamental understanding of how APIs work.

Starting with the domain where you want your API to run might be a good idea. If you’re
building API integrations for web development, for one, you should read up on REST APIs.

Prototype

Designing a prototype is the next step. Prototypes have minimum functionality but they should
provide a base foundation for what your API will look like. This stage shouldn’t take long at
all, a week at most.

Minimum Viable Product (MVP)

An MVP is a step up from a prototype. It represents a beta version of your API which you can
test. Not unexpectedly, this will take longer to build than a prototype. Set aside two weeks max
for MVP development.
Related reading: Know The Top 7 API Integration Tools

Transaction Management
Transactions describe an API call on your website or application. Your job where
transaction management is concerned is to figure out what to do if a transaction doesn’t go as
planned. Withdraw the transaction if necessary and debug the problem.
Conclusion
Building an API is only the beginning of API integration. And it might not be the easiest either.
APIs rely on technical expertise to keep everything running smoothly. Note that the secret fifth
step to building API integrations is servicing your integration on a regular basis.

It may have just occurred to you that all of this is going to take a lot of work. Well, you’re
right.

Different Type Of REST Requests

Here we will discuss each and every method of REST API along with the collections.

Method Description

GET Fetch status line, Response body, Header etc.

HEAD Same as GET, but only fetch status line and header section

POST Perform request using request payload mostly in creating a record at the server

PUT Useful in manipulating/updating the resource using Request payload

DELETE Deletes information relating to the target resource.

OPTIONS Describe the communication options for the target resource

PATCH Very much similar to put but it is more like a minor manipulation of resource content
Rest API Response Codes
Here are some sample Response Codes which we will normally see while performing REST API testing over
POSTMAN or over any REST API client.

#1) 100 Series

These are temporary Responses
 100 Continue
 101 Switching Protocols
 102 Processing
#2) 200 Series
The client accepts the Request, being processed successfully at the server.
 200 – OK
 201 – Created
 202 – Accepted
 203 – Non-Authoritative Information
 204 – No Content
 205 – Reset Content
 206 – Partial Content
 207 – Multi-Status
 208 – Already Reported
 226 – IM Used
#3) 300 Series
Most of the codes related to this series are for URL Redirection.
 300 – Multiple Choices
 301 – Moved Permanently
 302 – Found
 303 – Check Other
 304 – Not Modified
 305 – Use Proxy
 306 – Switch Proxy
 307 – Temporary Redirect
 308 – Permanent Redirect
#4) 400 Series
These are specific to client-side error.
 400 – Bad Request
 401 – Unauthorised
 402 – Payment Required
  403 – Forbidden
 404 – Not Found
 405 – Method Not Allowed
 406 – Not Acceptable
 407 – Proxy Authentication Required
 408 – Request Timeout
 409 – Conflict
 410 – Gone
 411 – Length Required
 412 – Precondition Failed
 413 – Payload Too Large
 414 – URI Too Long
 415 – Unsupported Media Type
 416 – Range Not Satisfiable
 417 – Expectation Failed
 418 – I’m a teapot
 421 – Misdirected Request
 422 – Unprocessable Entity
 423 – Locked
 424 – Failed Dependency
 426 – Upgrade Required
 428 – Precondition Required
 429 – Too Many Requests
 431 – Request Header Fields Too Large
 451 – Unavailable For Legal Reasons
#5) 500 Series
These are specific to the server-side error.
 500 – Internal Server Error
 501 – Not Implemented
 502 – Bad Gateway
 503 – Service Unavailable
 504 – Gateway Timeout
 505 – HTTP Version Not Supported
 506 – Variant Also Negotiates
 507 – Insufficient Storage
 508 – Loop Detected
 510 – Not Extended
  511 – Network Authentication Required

Main types of Web APIs

There are four main types of APIs:

 Open APIs: Also known as Public API, there are no restrictions to access these types of APIs

because they are publicly available.

 Partner APIs: A developer needs specific rights or licenses in order to access this type of API

because they are not available to the public.

 Internal APIs: Also known as Private APIs, only internal systems expose this type of API. These

are usually designed for internal use within a company. The company uses this type of API among

the different internal teams to be able to improve its products and services.

 Composite APIs: This type of API combines different data and service APIs. It is a sequence of

tasks that run synchronously as a result of the execution, and not at the request of a task. Its main

uses are to speed up the process of execution and improve the performance of the listeners in the

web interfaces.

There are 3 different types of API protocols:

 REST (Representational State Transfer)

  SOAP (Simple Object Access Protocol)

 RPC (Remote Procedural Call)

REST API:

 The representational state transfer (REST) architecture is perhaps the most popular
approach to building APIs. REST relies on a client/server approach that separates front and back
ends of the API and provides considerable flexibility in development and implementation.

 REST is stateless, which means the API stores no data or status between requests.
 REST supports caching, which stores responses for slow or non-time-sensitive APIs. REST APIs,
usually termed RESTful APIs, also can communicate directly or operate through intermediate
systems such as API gateways and load balancers.

SOAP API:

 The simple object access protocol (SOAP) is a messaging standard defined by the World Wide Web
Consortium and broadly used to create web APIs, usually with XML.
 SOAP supports a wide range of communication protocols found across the internet, such as HTTP,
SMTP and TCP/IP. SOAP is also extensible and style-independent, which enables developers to
write SOAP APIs in varied ways and easily add features and functionality.
 The SOAP approach defines how the SOAP message is processed, the features and modules
included, the communication protocol(s) supported and the construction of SOAP messages.

RPC API:
The remote procedural call (RPC) protocol is a simple means to send multiple parameters and receive
results. RPC APIs invoke executable actions or processes, while REST APIs mainly exchange data or
resources such as documents. RPC can employ two different languages, JSON and XML, for coding; these
APIs are dubbed JSON-RPC and XML-RPC, respectively.

What are the differences between SOAP and REST?

SOAP REST
There are loose guidelines to follow allowing developers
It has strict rules and advanced security to follow.
to make recommendations easily
It is driven by Function It is driven by Data
It requires more Bandwidth It requires minimum Bandwidth
SOAP API REST API
Relies on REST (Representational State Transfer)
Relies on SOAP (Simple Object Access Protocol)
architecture using HTTP.

Generally transports data in JSON. It is based on URI.

Transports data in standard XML format. Because REST follows stateless model, REST does not
enforces message format as XML or JSON etc.

Because it is XML based and relies on SOAP, it

It works with GET, POST, PUT, DELETE
works with WSDL
Works over HTTP, HTTPS, SMTP, XMPP Works over HTTP and HTTPS
Highly structured/typed Less structured -> less bulky data
Designed with large enterprise applications in mind Designed with mobile devices in mind
What is SAFe?
SAFe is nothing but Scaled Agile Framework which implements Organizational and Workflow patterns for
implementing Agile practices at Enterprise Scale.

SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams. It was
formed around three primary bodies of knowledge: agile software development, lean product
development, and systems thinking.

As businesses grow in size, SAFe provides a structured approach for scaling agile. There are four
configurations in SAFe to accommodate various levels of scale: Essential SAFe, Large Solution
SAFe, Portfolio SAFe, and Full SAFe.
What Is Private Banking And
How Does It Work?
Private banking is an elite service that generally features concierge-like attention to
your finances, plus other perks and customized financial services. In most cases,
however, only high-net-worth customers can access private banking.

Private banking, also known as “relationship management,” pairs banking clients with
individuals or teams that handle all of their financial tasks within the bank.

The clients can skip the teller and call their private banker directly to get help or
complete transactions. The private banker is already familiar with the client’s specific
financial situation and is in an ideal position to make suggestions and
recommendations.

While the concierge nature of private banking is one of its selling points, that’s not all a
private banker offers. In addition to being the point of contact for private clients, a
private banker can also pay bills, provide wealth management services and arrange for
unique products outside the bank’s standard offerings.
In short, private banking offers clients a single coordinator for nearly all their banking
and financial needs.

Private bankers are financial professionals who provide concierge banking services.
They are experts on the benefits a private bank can offer. They also know how to
navigate channels and advocate for clients when necessary.

Most financial institutions hire only certified private bankers licensed by the Financial
Industry Regulatory Authority (FINRA) or the North American Securities
Administrators Association (NASAA).

Like a resort concierge, a private banker helps you maximize your banking experience
with minimal stress. They provide guidance and suggestions based on the financial
institution’s products and partnerships. They may also earn bonuses or commissions
on financial products they recommend.

How Private Banking Works

Private banking takes a holistic approach to your finances. Whether you’re an

executive, entrepreneur or owner of a family business, private banking considers the
solutions that best fit your unique needs.

What Does a Private Banker Do?

A private banker helps craft a financial strategy and reduces friction when connecting
you to additional banking resources. Private bankers should be well-versed in your
financial situation and familiar with your short- and long-term financial goals.

Private bankers closely monitor the performance of your accounts and educate you on
investment risk. During major life changes and tumultuous seasons in the market,
private bankers explain your options and work with you to refine your plan. Your
private banker can also coordinate any borrowing needs and provide you with
preferred interest rates and customized terms for various loans.

Private bankers can support business owners with credit increases, succession
planning, risk-protection strategies and cash flow solutions. And they may inform you
of changes to tax regulations or connect you to external legal advisors.

Another aspect of a private banker’s role is generating new business and promoting
financial services. While a certified private banker looks after your finances, they are
also considering the bank’s and their own financial interests.

Private Banking Services

Private banking services vary from bank to bank. But you are likely to find the
following services and products from many banks offering private banking:
 Preferential rates and pricing on deposit accounts. Private banking
clients may be eligible for higher APYs on savings accounts, CDs, interest-
bearing checking accounts and money market accounts. They also may enjoy
lower fees or waived fees on their accounts.
 General financial planning. A private banker can walk clients through major
financial decisions, such as deciding how much to spend on a house or when to
start saving for a child’s education.
 Investment advice and wealth management. Private bankers often fill the
role most commonly associated with financial planners and advisors by advising
their clients on investing, including everything from asset allocation to tax-loss
harvesting to risk management.
 Estate planning. Clients can confer with private bankers on how to set up an
estate plan, although some aspects of planning require a visit to another
professional, such as an estate attorney. Private bankers will often refer their
clients to trusted professionals for that purpose.
 Lending. Clients looking to purchase a home, investment property or
commercial property can contact their private banker for assistance. A private
mortgage banker with expertise in custom home lending solutions may offer
better options for complicated home acquisitions. The bankers may also provide
loans for luxury items. Even if the bank does not generally offer loans for your
specific purchase, a private banker may be able to arrange the loan you need.
 Tax planning and philanthropy. Private bankers may stay on top of
important tax laws on your behalf to reduce your tax burden. They may also
provide access to professionals experienced in nonprofit management and
philanthropic strategy to develop a specialized investment plan for
contributions.
 Credit and cash-flow management. Institutions typically offer their private
banking clients lines of credit with low rates. Private bankers can also help
 derive cash flow from illiquid assets to manage business costs and avoid loss
from excessive cash on hand.
Private Banking Minimum Requirements

Not all private banking is equal. Banks like Chase, HSBC and Wells Fargo advertise
enhanced service-based checking accounts using the terms “private client” or “premier
accounts.” However, these accounts are not true private banking.

Eligibility requirements for bona fide private banking vary from bank to bank. But the
services are generally reserved for high-net-worth individuals, which, according to the
Securities and Exchange Commission, means people with at least $750,000 in
investable assets.

Investable assets include any liquid or nearly liquid assets you own, such as money in
your checking and savings accounts, CDs, money market accounts, stocks, bonds,
mutual funds, retirement accounts and trusts. Although the minimum amount for
private banking eligibility varies, $1 million is a common benchmark requirement.

However, some private banks require investable assets of $5 million or $10 million for
account consideration. And even within those banks, those assets will not grant you
access to the most exclusive products from the bank.
The Cost of Private Banking

There are a variety of fee structures for private banking. Some banks that sell products
to their private banking clients rely on commissions from those sales. Clients of these
private banking services do not pay anything out of pocket, but they should be aware of
the products’ commission-based nature.

Banks may also use fees to pay for private banking—either instead of or in addition to
commissions. Fees for private banking may be fixed or sliding. Fixed fees are similar to
typical account maintenance fees you’d pay for a checking account. You may be able to
avoid fees by maintaining a minimum balance, or the fees may be nonnegotiable.

Some banks use a sliding fee instead of fixed fees, charging private banking customers
a percentage of their assets under management (AUM). This percentage is generally
around 1% of the AUM.

Private Banking Advantages and Disadvantages

Pros
 Single point of contact. Private banking provides access to a dedicated
private banker who can address concerns, troubleshoot financial challenges and
refer you to experts within your bank. That can increase banking privacy and
reduce the number of times you need to explain your finances.
  Benefits for business owners. Juggling your personal and company finances
can be challenging, but a private banking relationship can help you find the
balance between maximizing your personal finances and growing your business.
 Access to alternative investments. Private banking can open the door to
exclusive hedge funds and private capital opportunities.
Cons
 Lack of transparency. Due to the elite nature of private banking, a complete
list of services and fees isn’t always available. Finding the best fit for your needs
may be difficult without a full picture of products.
 Potential conflict of interest. Although some private banks claim to follow a
fiduciary standard, few certified private bankers are fiduciaries. That means your
banker may prioritize their interests ahead of yours. According to a 2021
study from the accounting and consulting firm Crowe, 62.4% of financial
institutions have pay-for-performance incentives.
 Private bankers are generalists. While a certified private banker may be
able to connect you to a private mortgage or investment banker, you could
receive better service if you assemble your own team of financial advisors, CPAs,
mortgage brokers and business consultants.

Private Banking vs. Wealth Management

Both private banking and wealth management offer financial planning and investment
management, and each may include portfolio management, tax and estate planning.
Yet while some wealth management programs operate within large banks, wealth
management firms aren’t required to operate under banking charters as private banks
are.
And, wealth managers often lack access to all of a client’s financial accounts.
Meanwhile, many private bank clients rely on their certified private banker to manage
their day-to-day funds, overseeing checking, savings, CDs and investments.

Can Tax Loss Harvesting

Improve Your Investing
Returns?
When you start investing, you don’t set out with the goal of losing money. But part of
having a well-diversified portfolio is embracing the reality that while some stocks
perform well, you always pick a few duds.

Luckily, you aren’t destined to be a loser just because some of your stocks are. Tax loss
harvesting is an investing strategy that can turn a portion of your investment losses
into tax offsets, helping turn financial losses into wins.

What Is Tax Loss Harvesting?

Tax loss harvesting is when you sell some investments at a loss to offset gains you’ve
realized by selling other stocks at a profit. The result is that you only pay taxes on your
net profit, or the amount you’ve gained minus the amount you lost, thereby reducing
your tax bill.

Investors can use the proceeds from selling their floundering assets to fund purchases
of similar investments that may grow over time and help recoup their losses. These
future gains can then be offset by future losses in turn, perpetuating a virtuous cycle of
tax savings.

A quick reminder: When you sell an investment asset for a profit, you owe capital
gains taxes on the profits based on how long you held the asset. If you owned it for less
than one year, you’ll pay your normal income tax rate on any gains. If you held it for
more than one year, you’ll owe the preferential long-term capital gains rate, which
could be as low as 0% but won’t exceed 20%, even for top earners.
Keep in mind that if you hope to harvest losses and enjoy the benefits they offer, sales
transactions must be completed before the end of the tax year. For example, if you
want to harvest losses from 2020, the transactions would have had to be completed by
December 31, 2020.

Wash Sales
Besides reducing your taxes, tax loss harvesting also frees up cash so you can buy new
assets that may be more likely to generate positive performance. You’ll probably want
to buy a similar type of investment to keep your asset allocation and risk profile
unchanged.
There are rules to keep in mind while navigating your next purchase. You can’t, for
instance, sell a stock to realize a loss and minimize your tax burden—and then rebuy
that exact same stock, or even one that’s nearly identical.

This maneuver is referred to as a wash sale. A wash sale occurs when you sell securities
at a loss and within 30 days before or after the sale buy “substantially” identical
securities, or acquire a contract or option to do so.
The wash sale rule does not, however, preclude purchasing securities in the same
industry. For example, you can sell shares of Pfizer and replace them with shares of
Merck. Alternatively, you could invest in an industry-specific exchange-traded
fund (ETF) or mutual fund that fits into your investment strategy.

Check: What It Is, How Bank Checks Work, and How To Write One

What Is a Check?
A check is a written, dated, and signed instrument that directs a bank to pay a specific sum of money to the
bearer. The person or entity writing the check is known as the payor or drawer, while the person to whom
the check is written is the payee. The drawee, on the other hand, is the bank on which the check is drawn.

Checks may be cashed or deposited. When the payee presents a check to a bank or other financial
institution to negotiate, the funds are drawn from the payor’s bank account. It is another way to instruct the
bank to transfer funds from the payor’s account to the payee or the payee’s account. Checks are
generally written against a checking account, but they can also be used to negotiate funds from a savings or
other type of account.

In some parts of the world, such as Canada and England, the spelling used is “cheque.”
KEY TAKEAWAYS

 A check is a written, dated, and signed instrument that directs a bank to pay a specific sum of money to the
bearer.
 It is another way to instruct a bank to transfer funds from the payor’s account to the payee or that person's
account.
 Check features include the date, the payee line, the amount of the check, the payor’s endorsement, and a
memo line.
 Types of checks include certified checks, cashier’s checks, and payroll checks, also called paychecks.
How Checks Work
A check is a bill of exchange or document that guarantees a certain amount of money. It is printed for the
drawing bank to give to an account holder—the payor—to use. The payor writes the check and presents it
to the payee, who then takes it to their bank or other financial institution to negotiate for cash or to deposit
into an account.

The use of checks allows two or more parties to make a monetary transaction without the need of actually
exchanging physical currency. Instead, the amount for which the check is written is a substitute for
physical currency of the same amount.

Checks can be used to make bill payments, as gifts, or to transfer sums between two people or entities.
They are generally seen as a more secure way of transferring money than cash, especially when there are
large sums involved. If a check is lost or stolen, a third party is not able to cash it, as the payee is the only
one who can negotiate the check. Modern substitutes for checks include debit and credit cards, wire
transfers, and internet banking.

The use of checks cuts out the need for one party to transfer a large sum of physical cash to another party.

History of Checks
Checks have been in existence in one form or another since ancient times. Many people believe a type of
check was used among the ancient Romans.1 While each culture that adopted a form of check had its own
system, they all shared the basic idea of substituting the check for physical currency.

In 1717 the Bank of England was the first organization to issue preprinted checks.2 The oldest American
check dates to the 1790s.3
Modern checks, as we know them today, became popular in the 20th century. Check usage surged in the
1950s as the check process became automated and machines were able to sort and clear checks. Check
cards, first created in the 1960s, were the precursors to today’s debit cards.4 Credit and debit cards—and
other forms of electronic payment—have since overshadowed checks as the dominant means of paying for
most goods and services. Checks are now somewhat uncommon but still used among the general
population.

Check Features
While not all checks look alike, they generally share the same key parts. The name and contact information
of the person writing the check is located at the top left-hand side. The name of the bank that holds the
drawer’s account appears on the check as well.

There are a number of lines that need to be filled in by the payor:

 The date is written on the line on the top right-hand corner of the check.
 The payee’s name goes on the first line in the center of the check. This is indicated by the phrase "Pay to
the Order Of."
 The amount of the check in a dollar figure is filled out in the box next to the payee’s name.
 The amount written out in words goes on the line underneath the payee’s name.
 The payor signs the check on the line on the bottom right hand corner of the check. The check must be
signed to be considered valid.

There is also a memo line on the bottom left hand corner of the check underneath the drawing bank’s
information. The payor may use it to fill in any pertinent information, such as a reference number, an
account number, or any other reason for writing the check.

A series of coded numbers are found along the bottom edge of the check, directly underneath the memo
line and the payor’s signature line. These numbers represent the bank’s routing number, the payor’s
account number, and the check number. In certain countries, such as Canada, the routing number is
replaced with an institution number—which represents the bank’s identifying code—and the transit or
branch number where the account is held.

Image by Sabrina Jiang © Investopedia 2020

The back of the check has an endorsement line for the payee’s signature when the check is negotiated. The
receiving bank stamps the back with a deposit stamp at the time it is negotiated, after which it goes for
clearing. Once the drawing bank receives the check, it is stamped again and filed. In some cases the check
is sent back to the payor if they request it.

Types of Checks
Checks can be used for several different purposes.

Certified check

One example is a certified check, which verifies that the drawer’s account has enough funds to honor the
amount of the check. In other words, the check is guaranteed not to bounce. To certify a check, it must be
presented at the bank on which it is drawn, at which time the bank will ascertain its authenticity with the
payor.

Cashier's check

A cashier’s check is guaranteed by the banking institution and signed by a bank cashier, which means the
bank is responsible for the funds. This type of check is often required in large transactions, such as buying
a car or house.

Payroll check

Another example is a payroll check, or paycheck, which an employer issues to compensate an employee for
their work. In recent years physical paychecks have given way to direct deposit systems and other forms of
electronic transfer.

Bounced Checks
When someone writes a check for an amount larger than what is held in their checking account, the check
cannot be negotiated. This is referred to as a “bounced check.” The check bounces because it cannot be
processed, as there are insufficient or non-sufficient funds (NSF) in the account (the two terms are
interchangeable). A bounced check usually incurs a penalty fee to the payor. In some cases the payee is
also charged a fee.
 Certified Check vs. Cashier's Check
There are a variety of available checks in the banking world and there are multiple
checks that can verify the funds in an account. While one example is a certified
check, another commonly used check is a cashier's check.

A banking institution usually guarantees a cashier's check, specifically, a bank cashier

signs the document, whereas a certified check is signed by the account holder and
then verified by the bank.

A certified check does not draw funds right away from an account holder's account;
the money stays in their account until the check is cashed. A cashier's check, on the
other hand, immediately withdraws the funds from an account and is then held by the
bank until the payee cashes the check. This is an additional step that makes a
cashier's check more secure.

That being said, there is not a tremendous amount of difference between the two.
Both are guaranteed forms of checks and will ensure payment to the check holder.

Besides checks, payment can be ensured through other means, such as wire
transfers. A good or service will only be released or performed once the funds from a
transfer hit the recipient's account.

What Is a Financial Instrument?

Financial instruments are assets that can be traded, or they can also be seen as packages of
capital that may be traded. Most types of financial instruments provide efficient flow and
transfer of capital all throughout the world’s investors. These assets can be in the form of
cash, a contractual right to deliver or receive cash or another type of financial instrument, or
evidence of one’s ownership in some entity.

Examples of financial instruments include stocks, exchange-traded funds (ETFs), bonds,

certificates of deposit (CDs), mutual funds, loans, and derivatives contracts, among others.

KEY TAKEAWAYS

 A financial instrument is a real or virtual document representing a legal agreement

involving any kind of monetary value.
 Financial instruments may be divided into two types: cash instruments and derivative
instruments.
 Financial instruments may also be divided according to an asset class, which depends
on whether they are debt-based or equity-based.
 Foreign exchange instruments comprise a third, unique type of financial instrument.

Types of Financial Instruments

Financial instruments may be divided into two types: cash instruments and derivative instruments.

Cash Instruments
  The values of cash instruments are directly influenced and determined by the markets. These can
be securities that are easily transferable. Stocks and bonds are common examples of such
instruments.
 Cash instruments may also be deposits and loans agreed upon by borrowers and lenders. Checks
are an example of a cash instrument because they transmit payment from one bank account to
another.

Derivative Instruments

 The value and characteristics of derivative instruments are based on the vehicle’s underlying
components, such as assets, interest rates, or indices.
 An equity options contract—such as a call option on a particular stock, for example—is a
derivative because it derives its value from the underlying shares. The call option gives the right,
but not the obligation, to buy shares of the stock at a specified price and by a certain date. As the
price of the underlying stock rises and falls, so does the value of the option, although not
necessarily by the same percentage.
 There can be over-the-counter (OTC) derivatives or exchange-traded derivatives. OTC is a market
or process whereby securities—which are not listed on formal exchanges—are priced and traded.

Types of Asset Classes of Financial Instruments

Financial instruments may also be divided according to an asset class, which depends on whether they
are debt-based or equity-based.
Debt-Based Financial Instruments

Short-term debt-based financial instruments last for one year or less. Securities of this kind come in the
form of Treasury bills (T-bills) and commercial paper. Bank deposits and certificates of deposit (CDs) are
also technically debt-based instruments that credit depositors with interest payments.

Exchange-traded derivatives exist for short-term, debt-based financial instruments, such as short-dated
interest rate futures. OTC derivatives also exist, such as forward rate agreements (FRAs) .

Long-term debt-based financial instruments last for more than a year. Long-term debt securities are
typically issued as bonds or mortgage-backed securities (MBS) . Exchange-traded derivatives on these
instruments are traded in the form of fixed-ietfncome futures and options. OTC derivatives on long-term
debts include interest rate swaps, interest rate caps and floors, and long-dated interest rate options.

Equity-Based Financial Instruments

Securities that trade under the banner of equity-based financial instruments are most often stocks,
which can be either common stock or preferred shares. ETFs and mutual funds may also be equity-based
instruments.

Exchange-traded derivatives in this category include stock options and equity futures.

Foreign Exchange Instruments

Foreign exchange (forex, or FX) instruments include derivatives such as forwards, futures,
and options on currency pairs, as well as contracts for difference (CFDs) . Currency swaps are another
common form of forex instrument. In addition, forex traders may engage in spot transactions for the
immediate conversion of one currency into another.

What Is Over-the-Counter (OTC)?

Over-the-counter (OTC) is the process of trading securities via a broker-dealer network as opposed to on
a centralized exchange like the New York Stock Exchange.

Over-the-counter trading can involve stocks, bonds, and derivatives, which are financial contracts that
derive their value from an underlying asset such as a commodity.

When companies do not meet the requirements to list on a standard market exchange such as the NYSE,
their securities can be traded OTC but may still be subject to some regulation by the Securities and
Exchange Commission.

KEY TAKEAWAYS

 Over-the-counter (OTC) securities are traded without being listed on an exchange.

 Securities that are traded over-the-counter may be facilitated by a dealer or broker specializing in
OTC markets.
  OTC trading helps promote equity and financial instruments that would otherwise be unavailable
to investors.
 Companies with OTC shares may raise capital through the sale of stock.

What is Cash Equity?

The term cash equity refers to the liquid portion of an investment that can easily be
converted into cash. In relation to investing, cash equity refers to the company
issuing stocks to the public. It may also refer to institutional trading of these shares. In
relation to real estate, the amount of property’s value that is not borrowed against a
mortgage or line of credit.
How Does Cash Equity Trading Work?

In the capital market, cash equity trading refers to the trading of equities or stocks done by large financial
institutions on major stock exchanges. For example, the Bombay Stock Exchange (BSE) and National Stock
Exchange (NSE). These companies trade in shares using the firm’s capital. Also, they place trades on their
behalf and trade on behalf of retail investors or institutional clients.
For example, ABC broking firm buys 20 lakh shares of Reliance Industries because the firm’s analysts
believe that the stock price is increasing over the next week. This, ABC Broking firm invests its own capital
and uses computerized trading to place the trade instantly. Hence, the company hopes to generate short
term profit and the profit to the firm’s capital. Similarly, ABC Broking company can place trades for large
institutional clients like mutual funds. Also, if an individual investor wants 100 shares of Reliance
Industries, the ABC Broking company places the trades immediately using the same computerized
system.
In both instances, the broking firm must place customer trades before placing the trades for the from
accounts. Therefore, to ensure fair trading executions for clients, this policy has been put in place.
Furthermore, if the brokerage firm wishes to buy Reliance Industries using the firm capital, and already
has customer orders to purchase the same stock, the broker must place the client’s orders first.

Equities Trading
Equity shares are one of the most common terms of equity capital markets. These shares are a primary
source of funds for any organization. The trading of equity shares happens in the stock market.
A stock market is a place where buyers and sellers meet to trade stocks. To trade in equity shares, one
must have a demat account and a trading account compulsorily. In this account, the company issues
shares which are in the electronic form in the demat account. Also, through this account, the investor can
purchase and sell shares.
Equity indicates ownership in that company. One can purchase shares and retain them for longer
durations as a long term investment tool. Also, shares can be traded for shorter durations to make quick
profits.
Cash Equity trading by investment firms focuses on short term trading. They intend to generate quick and
large profits from changing market prices. Therefore, the traders back their trade with firm capital rather
than with the borrowed money.

Benefits of Cash Equity Trading

The following are the benefits of cash equity trading –

 Investors receive equity shares in the digital form in return for the cash invested in the company.
 An investor or trader can hold equity shares for any duration.
  The risk involved in cash equity trading is comparatively lesser than in derivatives.

Investing in equity shares for a longer duration reduces the overall risk to the investor.
What is Computerized Trading?
A large portion of the institutional cash trading is computerized trading programs. These firms use
computers to buy and sell large volumes of stocks in a fraction of a second. When news reports are
discussing electronic and computerized trading, these reports are referring to the cash equities trading
market. Through computerized trading, a large volume of stock trading is happening on the
big stock exchanges. Also, financial firms can generate profits from marginal fluctuations in the individual
share prices.
What is Customer Equity Trading?
Cash equity trading from financial firms also includes trading for its customers. These trades include large
volume trades, special off-exchange trades and trading with customer funds. Equity trading is suitable for
customers who have a substantial amount to invest. The firm handover over the customer’s money to
traders who are professional stock market traders. These stock trading desks use cutting edge technology
to deliver superior services to customers. Also, these advanced stock trading tools are available only in
the trading firms. Generally, individual traders do not have access to this facility.

Difference between Options and Futures

The basic and most prominent difference between options and futures is related with the obligations they
create on part of the buyers and sellers.
  An option offers the buyer the basic right, but not an obligation, to buy (or sell) a certain
kind of asset at a decided or settled price, which is specific at any time while the contract is
alive.
 On the other hand, a futures contract offers the buyer the obligation to buy a specific asset,
and the seller the obligation to sell and deliver that asset on a specific future date, provided
the holder does not close the position prior to expiration.
 An investor can go in into a futures contract with no upfront cost apart from commissions,
whereas purchasing an options position does not need to pay a premium. While comparing
the absence of any upfront cost of futures, the premium of the option can be considered as
the fee for not being obligated to purchase the underlying asset in the case of an adverse
movement in prices. The premium paid on the option is the maximum value a purchaser can
lose.
 Another important difference between futures and options is the size of the given or
underlying position. Usually, the underlying position is considerably bigger in case of
futures contracts. Moreover, the obligation to purchase or sell this given amount at a settled
price turns the futures a bit riskier for an inexperienced investor.
 The final and one of the prominent differences between futures and options is the way the
gains or earnings are obtained by the parties. In case of an option, the gains can be realized
in the following three ways −
o Exercising the option when it is deep in the money,
o Going to the market and taking the opposite position, or
o Waiting until expiry and gaining the gap between the asset and the strike
prices.
On the other hand, gains on the futures positions are naturally 'marked to market' every day. This means
that the change in the price of the positions is assigned to the futures accounts of the parties at the end of
every trading day. However, a futures call-holder can also realize gains by going to the market and opting
for the opposite position.
 SYSTEM INTEGRATION

System integration is the process of joining software and hardware modules into one

cohesive infrastructure, enabling all pieces to work as a whole.

There are different ways to achieve connectivity between separate systems. We’ll review the

most common “connectors” in a nutshell.

Application programming interfaces (APIs) provide the most common and

straightforward way to connect two systems. Sitting between applications and web services,

they enable the transmission of data and functionality in a standardized format. Most online

service providers — from social media to travel platforms — build external APIs so that

clients can easily link to their products.

How to approach system

integration
System integration is multifaceted and can be approached through different architectural
models, depending on the number and nature of components that need to be connected.

Point-to-point model
Point-to-point integration (P2P) is the architectural pattern in which every system is
directly connected to all other systems and apps it needs to work in tandem and share
information with. This model can be realized via APIs, webhooks, or custom code.

With a point-to-point connection, data is extracted from one system, modified or

formatted, and then sent to another system. Each application implements all the logic for
data translation, transformation, and routing, taking into account the protocols and
supported data models of other integrated components.
Pros and cons: Among the main advantages of point-to-point integration is the ability of an

IT team to build a small-scale integrated system quite quickly. On the flip side, the model is

hard to scale and the management of all the integrations gets very demanding when the

number of applications grows. Say, to interconnect six modules you need to perform 15

integrations. This results in the so-called star/spaghetti integration.

When to use it: This approach suits companies that don’t have complex business logic and

run their operations on just a few software modules. It is also a perfect option for

businesses aiming at connecting to SaaS applications.

Hub-and-spoke model

The hub-and-spoke model is a more advanced type of integration architecture that

addresses the issues of point-to-point and helps to avoid the star/spaghetti mess. The
connections between all subsystems are handled by a central hub (message broker), so
they don’t communicate with each other directly.

The hub serves as a message-oriented middleware with a centralized integration engine to

translate operations into a single canonical language and route messages to the right
destinations. The spokes (adapters) connecting the hub to the subsystems are managed
individually.
Pros and cons: As opposed to P2P, the model brings quite a few benefits to the table including higher
scalability. Since every system has only one connection to the central hub, things get better in terms of
security and architecture simplicity. However, the centralization of the hub can be a weakness in such a
model. The whole infrastructure is dependent on the single integration engine which can become the key
bottleneck as the workload increases.

When to use it: The hub-and-spoke model is widely-used in e-commerce, financial operations, and
payment processing. Besides, it’s a preferable architecture for highly regulated industries that face
significant security risks.
Enterprise Service Bus (ESB) model

The ESB architecture involves the creation of a separate specialized subsystem — an enterprise service
bus — that serves as a common user interface layer connecting other subsystems.

The ESB can be described as a set of middleware services that glue multiple systems, serving as a
messaging backbone. In contrast to hub-and-spoke with a single centralized integration engine, in ESB,
each system is supplied with a separate integration engine and an adapter that translates a message into
the canonical format and back into the destination supported format. Initially designed to bridge complex
internal systems of large enterprises, ESBs can work with cloud services too.
Pros and cons: One of the best things about ESBs is that each subsystem is decoupled by a “messaging
bus,” so it can be replaced or changed without affecting the functionality of other subsystems. This plays
in favor of high scalability. Also, such projects are reliable and quite easy to design. As far as the cons,
maintenance and troubleshooting get more complex with the spreading of integration tasks across the
systems.

When to use it: An ESB model is an optimal way to implement large projects such as enterprise
application integration (EAI), allowing them to scale when needed. It’s a good fit if a company needs to
bring it together on-premises.

How to search DOMAIN Name and how to query it

WHOIS (pronounced as the phrase "who is") is a query and response protocol that is widely used for
querying databases that store the registered users or assignees of an Internet resource, such as a domain
name, an IP address block or an autonomous system, but is also used for a wider range of other
information. The protocol stores and delivers database content in a human-readable format. [1] The
current iteration of the WHOIS protocol was drafted by the Internet Society, and is documented
in RFC 3912.

Whois is also the name of the command-line utility on most UNIX systems used to make WHOIS protocol
queries.[2] In addition WHOIS has a sister protocol called Referral Whois (RWhois).
LOAN MANAGEMENT SYSTEM (LMS)
 Q&A
1.What you will do in a situation where the stakeholder is not satisfied with the outcome/
wants some enhancement in the product increment?
A) 1st Thing is we will see if the enhancement is small, and so we will enhance and present in
the same sprint.

If the enhancement is big we certainly take it to next sprint and get it complete.

If the Stakeholder is asking for completion of this enhancement before moving to next sprint,
then we will take sometime for another GO LIVE DATE, complete the enhancement and
present it to stakeholder.

Another situation is , when the project is going to end and you are handing the same to new
team. In this case we will inform stakeholder we have handed over the changes or requirements
to new team and to work along with new team and we inform new team and we will handover
the requirements to new team .

2. If you joined newly and there is no document to refer for requirement?

It is bit scary when u joined and do not have any document to refer

 First, I will speak with my team member, team leads and try to get some share point
Folders we are having and see if some documents which are not completed and
unfinished documents. I will get all the documents from here and there and bring it to
one place. (Bring all the scattered documents at one place)
 Then I will see stage by stage document and see if the particular document is satisfying
which requirement and I will be creating a REQUIREMENT TRACEABILITY
 MATRIX and align the document with concern requirement(Clearly defines which
document is for which requirement)
 Structuring the document and making it easy to search. Create the sub-folders and
Based on the functionalities and use cases, try to dump in whatever documents I have
collected then give the entire document to review and ask for their inputs to
add/remove/modify something. This will give me something to start or work with.
 After review and inputs, I will create share-point link and share the same with team for
easy reference.
 Then I will contact the client and get some more requirements.

3. What do you do if the requirements are not feasible?

I will see if the requirement is not feasible, then we have to leave the requirement or we
have to halt the project for further discussion. Because if the requirement is not feasible and if I
carry out , 2 things will happen:

 After sometime when the user ask about the requirement, he will be dis-appointed as the
requirement was left and he was informed on in initially
 If I gave it to development team, they also feel that this is not feasible and why it has
been given to them and it cannot be done for development. Both the parties are not
happy.
  Either we should leave it out or we should halt the project for further discussion and find
ways to make it feasible.

4. What are the challenges you faced and how you handled while working with cross-
functional team?

* A situation has come when I was supposed to work cross functional team and to whom I have
no authority or less authority. I used to ask for specific things and requirements from him but
he used to tell wait for sometime , I will give or I will respond. Then I decided and came to an
idea , whenever team meeting used to happen every week I used to appreciate him about his
good works and I used to tell the team that he has helped me in getting the things done. After
that his approach was completely changed and finally complete the work which is not possible
or is delayed if collaboration was not there.

5. Imagine is someone with whom you work does not like you for whatever the reason it may
be and how to do you deal this?

6.If whatever the requirements you have written and submitted and the Reviewer does
not like it and has not given good review. What you will do?

In this case , 1st I will try to understand their inputs. I will discuss on call personally and
separately with them and try to understand their inputs and at the same time I will give my
inputs and make them understand that I might not have understood the requirement properly
and make changes according to their inputs and submit. If you resolve any inputs and
implement and work as per the stakeholder, then that will be easy job to complete the project.

7.If you are placed on completely new domain, how u will handle?

* I will first refer all the documentation available with that project and try to get some
understanding.

* I will speak with senior BA’s or BA lead and understand about the domain and get some
inputs.

* I will refer online channels and this is the best way to get the inputs on the domain.

* I will create the documentation, PPT & Flowcharts and when I create personally I will come
to know and I can used to it quickly.

8.As a Business Analyst what is your role in the organization?

* Business Analyst is a vital role in the organization. BA role is to find out the needs of the
organization, finding out the problems they are facing , predicting the future issues and then
suggesting the suitable solutions to them based on the organizations achievements.

* The role also differs from organization to organization or sometimes different projects
demands different things from a BA and even some different domains we have to play our role.
We have to do Business analysis, planning and as a BA we should have skills like effective
communication, creative thinking, leadership skills .

9. How will you handle the changes in the requirements?

* The very first task of the BA is to taking the sign off from the documents he has created and
he has showed it to all the stake holders and get the signature of the document to close the task
or to close the requirements.

* But sometimes changes will come in the requirements. So 1st thing is to note down what are
the changes of the requirements that should be given to them and we’ll go through the changes
and see how it will impact my project. I will calculate how it is impacting the cost, the
timelines, the resources by doing those changes and then after this I will come up with changes
that will affect or create gaps to the functional design documents or the testing or the coding.
So that is the way I will handle the changes.

10.What are the different tools Business Analyst work on?

* Microsoft Excel

* Powerpoint

* Word
* Trello

* Jira

* Confluence

11.How can you say that requirement is good or perfect?

* Rule is SMART – Specific, Measurable, Attainable, Relevant and Timely

Specific: The requirement is clear and Unambiguous. Explains to the project team exactly
what’s expected
Measurable: The requirement can be measured (i.e., tested) to determine whether its been met.

Achievable/Attainable: The requirement is attainable otherwise you are setting yourself up to

fail.

Relevant: The requirement must be relevant to the Business needs of the organization and be
realistic as well.

Time Framed: The requirement has a clearly-defined time frame for when it will be
achievable

12. What are the Task that are not part of the Business Analyst Job?

* Yes BA should not involve in Coding, testing and is not required to attend all the meetings.

13. List out the documents handled by the BA?

* Functional Specification Document

* Business requirement document

* Use Case document diagrams

* Requirement Traceability matrix

14. When can we say the requirements are done?

 Requirements should be aligned with the objectives of a business. It means that the views of
business stakeholders should align with the needs to be built for the project.
 All the possible views and ideas of key stakeholders are to be extracted.
 The quality of the requirements should meet/satisfy the organization’s set of criteria through
which the quality of the requirements is tested.
 One can say that the requirements are complete when they could be done within the possible
available resources.
 All the stakeholders of the project should be in consent with the gathered requirements.
15. Main Documents to be prepared by Business Analyst?

 BRD
 FRD
 User Stories
 Use Cases
 Test Cases
 Release Document
Process Flow for Enrolling an Insurance Policy
The image given below shows the high-level process flow for policy enrollment and how it is processed
through different insurance applications.