Академический Документы
Профессиональный Документы
Культура Документы
Product Owner identifies the features that will be included in the next 30-sprint and set the
priority of each. This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesnt exist.
Scrum Master acts much like the project manager. While the Scrum Master does not micromanage the teams deliverables, this person ensures that the 30-day sprint is on track and
enforces the key rules that guide Scrum such as; no new features can be added to the sprint
once it is kicked off, and team members cannot be pulled off to work on other side project in the
middle of a sprint.
Team Member unlike traditional software development methods, in Scrum there is little
separation of duties between team members. Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.
Delivery of a complete build with an initial set of limited features within a few months (often 1-2
months)
Most Agile methods begin with a prioritized feature list where features are group together into deliverable
chunks and assigned to a particular iteration in which they will be developed and delivered. Using small
teams and daily communication among all team members the Agile team can achieve a high level of
efficiency.
Agile methods are intended to overcome or circumvent many of the recurring challenges that are
encountered during software development projects. The iterative nature of these methods, along with the
desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving
requirements, unclear project stakeholder direction, and unforeseen project complexities that typically
arise during the latter stages of analysis and development. Some of the most salient advantages of
Agile methods include:
Availability of working software much sooner which allows for more immediate feedback from
application users.
More immediate, and therefore larger, Return on Investment from software features that are
developed in short iterations and release to production immediately.
2.
3.
The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes. Standardizing the
time and place of the meeting results in increased efficiency by eliminating overhead associated with finding rooms
to schedule and team members determining where they should be each day. It also tends to decrease the number of
late arrivals. A primary key to the Daily Scrum Meeting is to keep it short. Any topics unrelated to the 3 questions
asked of each team members should be tabled during the meeting and handled at a later time.
The Card: Named for the standard index cards on which a user story is often captured. The cards are used
for planning the work that will be completed during each iteration of development.
The Conversations: Discussions about each user story are had with the users/customers of the system to
flesh out details. The conversations are captured and documented as part of the user story.
The Confirmation: Test scenarios that capture details about the user story that can be used to verify that the
user story has been successfully implemented.
Using these three parts, the goal of the user story is to provide enough detail that a developer can understand what
needs to be done while providing a means to verify that they have achieved the goal. User stories are often equated
to a single use case scenario, such as the main use case scenario or an alternative path. The Card portion of the
use case scenario is written in a manner similar to a brief description of a use case.
PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for
Plan, Do, Check, Act. It was popularized by Dr. W Edwards Deming in the 1950s during his work in
Japan where he taught top management how to improve product design, quality, testing and sales.
The process is originally attributed to Walter A. Shewhart and was referred to by Deming himself as the
Shewhart Cycle. The Shewhart Cycle steps were listed as Specification, Production, and Inspection.
However, over time, the steps were shortened to the more easily remembered Plan, Do, Check, Act (also
referred to as PDSAPlan, Do, Study, Act) where the Act step emphasized the need to take action on the
knowledge gained from the prior step.
PDCA (or PDSA) is firmly rooted in the Scientific MethodHypothesis, Experiment, Evaluation. A
fundamental principle of these methods is iteration. Once the result of a process is confirmed (or
negated) the cycle is repeated and the new knowledge can be acted upon. It is this process of taking
action, measuring the results, and utilizing those results to develop the next course of action that make
the PDCA method and others like it, such as the Six Sigma DMAIC process (Define, Measure, Analyze,
Improve and Control), so powerful and beneficial as a tool for the Business Analyst.
These methods, and others like them, which employ and iterative feedback loop embody two key points:
What techniques do you use to ensure that you have identified the principle
problem or requirement?
Problem solving and problem resolution is a common part of a business analysts role. But before you
spend time figuring out resolutions to the problem, you should be sure that youre solving the right
problem or that you have the true requirement.
Problem Restatement is one category of techniques that can be used to determine that the principle
problem has been identified. Some problem restatement techniques are:
1. Problem Paraphrasing Alter the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. Repeat the process until you have arrived at
the principle problem.
2. 5W + 1H (Who, What, When, Where, Why, + How) Create multiple variations of the problem
statement beginning each statement with one of the 5W + 1H keywords.
3. Repeatedly Ask Why Starting with the original problem statement, ask Why to identify a new
problem statement. Continue to ask why to each new problem statement until you arrive at what
is clearly the principle problem.
Give an example of how you would use the problem restatement technique of
Repeatedly Ask Why.
The Repeatedly Ask Why technique starts with the original problem statement and asks Why to identify a
new problem statement. The Business Analyst continues to ask why to each new problem statement until
he or she arrives at what is clearly the principle problem.
This technique is so natural that all of us have used it as toddlers. Using the Repeatedly Ask Why
technique allows the Business Analyst to overcome any assumptions that may have been made when
developing the original problem statement. So revert back to that 2 year old kid and ask Why.
Example:
Because they keep reusing leftovers and using lower quality products. Why?
Because over the last few months fewer people have been going to the cafeteria. Why?
Because we had layoffs and there are less people on our company campus.
At this point we can identify that the principle problem is the layoffs resulting in fewer people using the
cafeteria. No matter what vendor you hire, they will have troubles being profitable under these
conditions. So the original problem statement stating that a new vendor is needed is incorrect.
Give an example of how you would use the problem restatement technique of 5W
+ 1H.
The 5W + 1H technique (Who, What, When, Where, Why, + How) is used to create multiple variations of
the problem statement beginning each statement with one of the 5W + 1H key words.
Example:
Rewriting the statement using the 5W + 1H technique broadens the focus of the Subject Matter Experts
and Business Analysts. This technique can be used at anytime, but is particularly important if the initial
problem statement is close ended phrase requiring a simple yes or no answer. This often constrains the
thought process of the Subject Matter Experts and Business Analysts. The resulting statements often
shed new light on the problem and help the group determine the principle issue.
Give an example of how you would use the problem restatement technique of
Problem Paraphrasing.
Problem Paraphrasing is altering the wording of the problem statement just slightly resulting in a new
problem statement which is very similar in meaning. The process is repeated until you have arrived at the
principle problem.
Example:
Drivers keep changing lanes to pass me and then pulling back in front of me.
Im driving to slow!
A Subject Matter Expert can tell you if each new statement still reflects a valid scenario. Its important that
each statement be valid and correct. However, this technique is useful because a Subject Matter Expert
may not be able to jump directly to the principle problem. The paraphrasing technique helps the group
gradually arrive at the principle problem.
other projects. Each week all of the pieces of broken pieces are collected and discarded. What other
options might the company have to reduce or eliminate their losses due to broken product?
Step 1: Brainstorm
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch
Season the broken product and market and sell it as a new product of its own
Give the broken product to a food shelter and take it as a tax write off
Develop a product that affixes the pieces together to form a bio-degradable clay pigeon for
skeet shooting
Sell the broken product to a dog food company as a filler ingredient for dog food
Sell the broken product to a mulching company to be used as mulch (impractical)
Season the broken product and market and sell it as a new product of its own
Develop a product that affixes the pieces together to form a bio-degradable clay pigeon for
skeet shooting
Category: Tax write off
Give the broken product to a food shelter and take it as a tax write off
Facilitator 1 (only one) - usually a Senior Business Analyst - facilitates discussions, enforces rules,
Scribe 1 or 2 sometimes more junior BAs take meeting notes and clearly document all decisions,
Technical Experts 1 or 2, question for clarity and give feedback on technical constraints,
Tie Breaker Senior manager (executive) - breaks end user ties, usually doesnt attend,
BUSINESS ANALYSIS
What is PEST Analysis?
PEST is an acronym that stands for Political, Economic, Social, Technological. PEST analysis is
one way that a business can analyze the environment in which it operates.
Political Environment: refers to government laws, regulations, and policies. These are things
that impact the business either directly or indirectly. This may include trade laws, tariffs, labor
laws, taxes, environmental regulations, zoning restrictions, etc. Some of these, if passed
recently, may have a long term affect on the economy as well. While PEST covers the economic
environment, some political environment considerations, such as leadership changes that come
from elections, may not have impacted the economy yet (this is an example of an indirect
impact). So the analyst should watch for how new government regulations may impact the
economy longer term and assess its impact on the business.
Economic Environment: refers to the forces at play within the economy that the business has
little control over. These may include interest rates, inflation rate, exchange rates, increase in
Gross Domestic Product (GDP), the financial and stock markets, the job market, etc. All of these
have impacts on the business from the ability to generate revenue to the cost of borrowing money
to the salaries they will need to pay employees.
Social Environment: refers to the demographics of the environment that the company operates
within. Since demographics are nothing more than characteristics of a human population this
could include a nearly infinite number of groups. Some common demographics that are
considered are gender, race, age, income, disabilities, educational attainment, employment status,
and religion. Ultimately, if the strategic plans of a business affect a particular group, they may
react positively or negatively. A business may face criticism, negative publicity or even protests
based on the decisions it makes. These factors could have an enormous impact on the operations
and revenue of the business.
Technological Environment: refers to the technology that currently exists that the business has
accessible to them. This could include servers, computers, networks, software and software
frameworks, database technologies, wireless capabilities, availability of Software as a Service
(Saas), and more. The rate of technological progress should also be considered, particularly if
the business has plans to develop a system or product that takes advantage of cutting edge
technology.
What is meant by Forming, Storming, Norming, and Peforming?
The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce
Tuckman. He described that most teams follow a consistent path from the point when they are first
assembled to the time when they become a highly proficient, highly effective group. This path leads them
through four distinct stages; Forming, Storming, Norming, and Performing.
The Forming stage begins when new team members are first brought together. Initially everybody is
very positive and polite to one another. Some people are anxious, some are excited. The team members
are fairly unaware of the details of the work ahead (blissfully nave perhaps) and they look for clear
direction from the leader. Formal processes and project frameworks are not yet established. This stage is
usually short in comparison to the others.
Next is the Storming stage. At this stage team members become clear about their roles and what is
expected of them. Processes and project structures are put into full effect. The team may feel frustrated
and overwhelmed by the work as they become more aware of the realities of the job. They may be
stressed by how much there is to accomplish and they may have uncertainties about their ability to do the
assigned work. Or, they may simply be uncomfortable with the approach that is laid out by the leader.
Team members still dont know each other that well as they continue to form opinions of one another.
They may be jockeying for position within the team or even challenging the leaders authority. Conflicts
arise more often during this stage. A great deal of oversight is needed by the team leader to ensure the
processes are followed and the work is completed to expectations.
The Norming stage is where the team begins to catch their stride. The pecking order of the team is
established and team processes and workflow are beginning to solidify. Each team member understands
the strength of the other members and they all begin to work more as a team. They help each other and
provide peer reviews and constructive criticism. At this point, the team is following the processes and
project framework but may not be working as efficiently as they could be. They still need oversight but
significantly less than in the storming stage.
Finally, the Performing stage is reached. The team has a solid understanding of the processes and
project framework that have been put into place and follow them efficiently. The team has become
efficient and productive and it reaches its goals with regularity. At this stage if a team member joins or
leaves it will have little impact on the rest of the teams performance. The team leader can delegate to
team members with confidence and provide minimal oversight.
Determine how costly a system is to maintain based on the number of function points it supports
To state things differently, Function Points are good for answering questions like:
How big is system A? Is system A bigger than system B and by how much? (It answers
these in terms of features)
How much will it cost me to build system A?
Counting Function Points can be a tricky task to do well. Getting consistent results is a challenge
unless you are a skilled practitioner at counting function points. There is a sizable Function Point
Counting Practices Manual available to direct the practitioner in this exercise.
FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.
While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try
to compensate for these challenges.
representative will often participate in a relatively unstructured dialogue in which the analyst asks
questions such as:
Why is x important?
Then based on the answers given the analyst will continue to ask follow up questions. The success of the
fact finding is typically dependent upon the experience level of the analyst. While this method can work,
the analyst will often walk away with several pages of unstructured notes. The important information must
then be extracted and organized into something meaningful and useful. Only then will the analyst be able
to determine if they have discovered all of the necessary pieces of information or if there are still gaps in
their understanding.
The H-method uses the following H shaped diagram to provide a structured framework to guide the
interview and to allow the analyst to captured information in an organized way from the start.
This diagram also asks the business representative questions is a business friendly manner. As
information is gathered, the analyst can document it in the appropriate area of the H shaped diagram.
Finally, the information gathered using the first diagram can be mapped to more business analysis centric
concepts on the following revised diagram.
The H-method is successful because it provides both a structured framework to guide the interview
process and because it reminds the business analyst to avoid business analysis jargon that may confuse
the business representative. Instead it asks questions that align more closely with how the business
representative views their world.
dotted-line border. The use case and its corresponding use case realization are linked using a realization
dependency which is shown in UML as a dashed line with a triangular arrowhead at the end
corresponding to the realized element (the use case).
Each use case realization will define the physical design in terms of classes and collaborating objects
which support the use case. Therefore, each use case realization typically is made up of a class diagram
and a number of interaction diagrams, most commonly sequence diagrams, showing the collaboration or
interaction between physical objects.
Use case realizations allow the analyst to clearly separate the concerns of the logical and physical
design. Since a logical design (the business behavior and requirements) can be implemented or realized
via a number of different physical implementations, if a physical design changes the logical use case can
remain unaffected. Also, a use case realization is an excellent form of requirements traceability from the
logical business requirements down to the physical implementation of the solution.
Project Charter
Business Requirements Document
Functional Specifications
Project Champion
Project Manager
Analysis Lead
Analyst/Analysis Team
Finally, at each intersecting cell the type or degree of involvement is documented (Responsible,
Accountable, Consulted, Informed).
Ultimately, each organization varies a bit in how they define each level of participation in a task or creation
of a document. The following are some commonly accepted definitions.
Accountable This is the person who is ultimately on the hook to ensure that the deliverable or task has
been completed and is thorough and correct. This is usually a lead or manager of some kind. The
accountable person may be directing the work of the responsible person, but in the end the buck stops
here. There can only be one truly accountable person. This avoids finger pointing when something
doesnt get done or is done incorrectly.
Responsible The responsible person(s) is the worker bee. It can be one person, or a team of people.
They will be the ones getting their hands dirty finding the information they need and putting it to use to
complete the task or create the deliverable. They may be reporting to a lead or manager who is
accountable for the task or deliverable. However, for smaller tasks or deliverables, when there is only one
responsible person listed, they may ALSO be listed as the accountable party.
Consulted The consulted person(s) is a subject matter expert. They are the person whose opinions or
knowledge of a particular system or process is sought. They dont usually participate in completing a task
or deliverable other than by providing the information that the responsible person needs to achieve their
task or deliverable.
Informed These are the people who need to be kept up to date on a task or deliverable. They may
need to track the amount of progress being made, but usually these people care only about the
completion of a task or deliverable. Typically they are either reviewers of the completed document and
provide formal sign-off and approval, or they may be dependent on the information that results from the
task or deliverable.
What strategies might a business analyst consider when planning for a company's growth?
If a company is to ensure its growth, it needs to plan for it. There are a number of growth strategies that
can be used. Deciding which is the right growth strategy for a company depends on it current success
and position within the marketplace in which it operates. Four of these growth strategies are:
Market Penetration focuses on getting more out of the current markets serviced by an organization while
offering the same products. New products and new markets can mean additional unknowns which, in
turn, increase risk and chances of failure. For this reason, a company may choose to select a growth
strategy of market penetration. The goal of market penetration is to increase the percentage of market
share that the organization possesses through pricing, marketing, loyalty programs, incentives,
advertising, etc.
Market Development is used to describe the growth strategy of an organization which chooses to
venture into new markets or new customer segments with their existing products. Their existing products
are likely proven which provides a degree of stability, but moving into new markets increases risk. This
may still be viewed by some organizations as a fairly conservative strategy and is often adopted by
companies as they feel their current markets getting squeezed tighter and tighter by competition.
Entrance into new markets often requires skilled marketing professionals to ensure a company receives
the attention it is looking for.
Product Development describes the growth strategy of creating new products for existing markets. An
organization may have the benefit of understanding the intricacies of their market but this can create a
false sense of security. Not all new products carry the same risk. However, for certain types of product,
especially those in fast moving technology markets, projecting the outcome of a new product launch can
be very difficult. To overcome some of this risk organizations should be prepared to continuously adapt
their products after launch to ensure marketplace success.
Diversification is the term given to the strategy of delivering new products to entirely new markets. The
growth strategy accepts the risks of two unknowns; the product and the market. Diversification is highrisk but, as with many things, high risk often can mean high reward. Organizations with a track record of
innovation will have the greatest success with this strategy. With diversification as a growth strategy,
everything will be new and the company will need to be prepared to quickly eliminate any risks that
manifest themselves.
The four growth strategies described here are based on a simple 2 x 2 matrix called Ansoffs Matrix which
considers markets and products along its two axis.
Ansoffs Matrix
Existing Products
Existing
Markets
New Markets
New Products
Diversification
What is Benchmarking?
When companies want to improve, they first need to have an accurate means of measuring performance.
Without accurate measurement, determining process improvement is not feasible. Measurement
establishes a baseline against which the organization can determine the degree of improvement that has
been made.
However, improvement alone may not be enough. If an organization doesnt know what the standard is it
cannot compare itself against it. For example, if an organization obtains a customer satisfaction rating of
80%, but its competitor receives 90%, they will lose ground in the long run. Benchmarking is the key to
understanding how an organization measures up against others.
Benchmarking is the process of determining how an organization stacks up against industry leaders by
measuring its performance across a series of standard metrics and then comparing the performance
against other best-of-breed organizations within the same industry or service line. Companies may
measure and compare policies, practices, philosophies, and other performance measures.
Benchmarking is usually part of a larger process re-engineering or quality improvement initiative such as
Six Sigma or Total Quality Management.
The Learning and Growth Perspective focuses on the development of metrics around training of
employees and education of the organization as a whole. These metrics should be structured in a way to
guide managers to focus their training funds where they will help most. They should also drive other
methods of learning such as mentoring and ensuring that knowledge can easily be communicated and
shared throughout the organization.
The Business Process Perspective focuses on the development of metrics that allow managers to know
how well the internal business processes are running and how well they meet the needs of the
organizations customers.
The Customer Perspective focuses on the development of metrics around customer satisfaction. This
perspective cannot be underestimated as it has been found that customer satisfaction is a leading
indicator of the future performance of the company. Over time, dissatisfied customers will seek out other
organizations that can meet their needs better.
The Financial Perspective focuses on traditional financial metrics. Companies often already place a
heavy emphasis on financials which can lead to an unbalanced view of a situation. While this perspective
is very important, Balanced Scorecard aims to balance this perspective by considering it in conjunction
with the metrics and data of the other perspectives.
Benchmarking studies
Business plans
Company memos
Customer contracts
Customer suggestions
Training guides
How is the Business Analysis Planning and Monitoring (BABOK v2.0) knowledge area
defined?
The Business Analysis Planning and Monitoring knowledge area describes the process of how a business
analyst determines which activities will be needed to complete the business analysis effort. The tasks
within this knowledge area govern the business analysis tasks in all of the other knowledge areas. These
tasks include:
1. Plan Business Analysis Approach
2. Conduct Stakeholder Analysis
3. Plan Business Analysis Activities
What is BPMN?
BPMN stands for Business Process Modeling Notation. BPMN is an industry standard
that provides businesses with the capability of visualizing and communicating their
internal business processes and their external business to business processes in a
standard manner. Beyond the obvious use of modeling business processes, BPMN
has been created with the key goal of creating a bridge between the business
process modeling notation (BPMN) and IT-oriented execution languages that will
implement the modeled business processes within a business process management
system. This is done by maintaining and supporting a strict internal model that
maps the rich set of graphical objects and object attributes of BPMN to executable
languages such as the Business Process Execution Language for Webs Services
(BPEL4WS) or Business Process Modeling Language (BPML) to support immediate
execution of modeled buiness processes.
NOTE: From the business systems analyst perspective, BPMN is a modeling notation
which provides the analyst with a rich graphical notation for modeling business
processes, sub-processes, and activities.
Many business analysts use BPMN diagrams instead of UML activity diagrams.
In addition, BPMN is a visual notation used by many of today's business process
modeling and management tools.
Name a few of the industry standards, methodologies, or best practices used by
business analysts and systems analysts?
-UML
-BPMN
-RUP
- Agile
- SDLC