By Carrie Alsvary, CBAP
Below is a summary of BABOK section 10.31 and Agile Techniques 7.21 from the Agile extension to the BABOK guide version 2.
Technique 10.31 – Observation

Purpose – Observation is used to elicit information by viewing and understanding activities and their context. It is used as a basis for identifying needs and opportunities, understanding a business process, setting performance standards, evaluation solution performance, or supporting training and development.
Description – Observation of activities, also known as job shadowing, involves examining a work activity firsthand as it is performed. It can be conducted in either natural work environments or specially constructed laboratory conditions. The objectives of the observation dictate how it is planned for and methodically conducted.
There are two basic approaches for observation:

  • Active/Noticeable: while observing an activity the observer asks any questions as they arise. Despite this interruption to the work flow, the observer can more quickly understand the rationale and hidden processes underlying the activity, such as decision making. A variation of this method may involve even stronger intervention into actors’ activities by stimulating them to perform specific tasks. This kind of facilitated observation allows focus on the observer’s objectives in order to shorten the observation time or elicit specific information.
  • Passive/Unnoticeable: during the activity the observer does not interrupt the work. Any concerns are raised after the work is over. This allows observation of a natural flow of events without intervention by the observer, as well as measurement of the time and quality of work. A variation of this method is video recording the activity and then reviewing it with the person being observed so they may provide further clarification.

Inspection of a person’s work environment helps in discovering any tools and information assets involved in performing their activities. This supports understanding of the activities, especially with the purpose of identifying needs and opportunities. This kind of observation is an important part of the technique’s variation, and is known as Contextual Inquiry.
Elements –

  1. Observation Objectives

A clear and specific objective establishes a defined purpose of the observation session.
Objectives of an observation session may include:

  • Understanding the activity and its elements such as tasks, tools, events and interactions,
  • Identifying opportunities for improvement,
  • Establishing performance metrics, or
  • Assessing solutions and validating assumptions.


  1. Prepare for Observation

Preparing for an observation session involves planning the observation approach based on the objectives and deciding who should be viewed performing which activities at what times. While preparing for an observation session, business analysts consider the skill and experience levels of participants, the frequency of the activities being observed, and any existing documentation and analysis related to the work activity. Preparing for observation also includes creating a schedule of observations.
The plan for observation ensures that all stakeholders are aware of the purpose of the observation session, they agree on the expected outcomes, and that the session meets their expectations.

  1. Conduct the Observation Session

Before the observation session:

  • Explain why the observation is being conducted,
  • Reassure the participant that their personal performance is not being judged and that the results of this observation , among others, will be evaluated as a whole,
  • Inform the participant that they can stop the observation at any time, and
  • Recommend the sharing of any reasoning or concerns while performing the activity or soon afterwards.

During the observation session:

  • Attentively watch the person perform the activity and note typical and atypical tasks or steps, the manner in which any tools are used, and information content
  • Record what is seen, the time taken to perform the work, its quality, any process anomalies, and the observer’s own concerns or questions, and
  • Ask probing questions either while the work is being performed or soon after the observation session.


  1. Confirm and Present Observation Results

After the observation session, business analysts review the notes and data recorded from the observation and follow up with the participant to obtain answers to any remaining questions or to fill any gaps. Sharing these notes and data with participants may be helpful in obtaining answers to any questions or easing any concerns the participant may have.
The validated notes and data are collated with other related observations to identify similarities, differences and trends. Findings are aggregated, summarized, and analyzed against the objectives of the session. Needs and opportunities for improvement are communicated to stakeholders.
Usage Considerations –

  1. Strengths
  • Observers can gain realistic and practical insight about the activities and their tasks within an overall process.
  • Instances of informally performed tasks as well as any workarounds can be identified.
  • Productivity can be viewed firsthand and realistically compared against any established performance standards or metrics.
  • Recommendations for improvement are supported by objective and quantitative evidence.


  1. Limitations
  • May be disruptive to the performance of the participant and the overall organization.
  • Can be threatening and intrusive to the person being observed.
  • While being observed, a participant may alter their work practices.
  • Significant time is required to plan for and conduct observations.
  • Not suitable for evaluating knowledge-based activities since these are not directly observable.

Agile Extension 7.21 – User Stories
Purpose – User Stories are used to convey a customer requirement for the delivery team.
Description – User Stories are a representation of the customer need and are expressed as a small, concise statement of a feature needed to deliver value. User Stories facilitiate the interaction and collaboration of stakeholders.
The user story expresses a customer need and value desired. Typically, they are one or more sentences written by the customers, product owners, or business analysis practitioners which describe something of value to a stakeholder. User Stories provide a mechanism for the product owner to scope, coordinate, and prioritize the increments of user value for delivery. A user story is captured on the backlog.
User Stories represent stakeholder needs using short, simple documentation and invite exploration of the requirements through conversations, tests, and supplemental requirements representations as needed. They are concise and easy to change as a stakeholder needs are better understood or as those needs evolve.
A commonly used construct for ensuring quality in user stories is the INVEST criteria, which calls for user stories to be:

  • (I) Independent – represents a feature which can be delivered independent of other features.
  • (N) Negotiable – the team can negotiate how to deliver.
  • (V) Valuable – expresses the value to the customer
  • (E) Estimatable – team can estimate effort to deliver based on past experience.
  • (S) Sized Appropriately – for the team to complete in one iteration. In general, the smaller the better.
  • (T) Testable – can be validated objectively by the stakeholder.

Not all backlog items are to be written as user stories. However, user stories is a common technique used as they emphasize customer value.
User Stories follow the 3Cs:

  • Card,
  • Conversation, and
  • Confirmation

Title (Optional)
The title of the user story describes an activity that the user wants to carry out with the solution. Typically, it is an active-verb goal phrase, similar to the way use cases are titled.
There is no mandatory structure for user stories; however, the most popular format includes three components:

  • A role or persona (WHO),
  • A necessary action, behavior, or feature (WHAT), and
  • The benefit or business value received by the user when the story is implemented (WHY).

The intended purpose of User Stories is to communicate between stakeholders and the delivery team. The user story intentionally does not capture all there is to know about the customer need. A well-written user story invokes conversation among the team.
Business Analysis practitioners confirm the delivered item satisfies the need expressed in the user story. This is most often expressed as acceptance criteria. Acceptance criteria define the boundaries of a user story and help verify and validate the solution met the intended user need.
Acceptance criteria help the delivery team identify the minimum amount of function necessary. Acceptance criteria are primarily used by the product owner and stakeholders to verify and validate. They also serve as a basis for acceptance tests, regression tests, exploratory tests, and other tests to be developed in support of the product.
User Story Management
There are a variety of ways in which user stories are used throughout an agile initiative. The following techniques are all impacted by user stories:

  • Backlog Refinement
  • Product Roadmap
  • Story Decomposition
  • Story Elaboration, and
  • Visioning

Usage Considerations – Strengths

  • Tied to small, implementable, and testable slices of functionality facilitating rapid delivery and frequent customer feedback.
  • Easily understandable by stakeholders.
  • Can be developed through a variety of elicitation techniques, including but not limited to facilitated workshops, contextual inquiry, and other ethnographic elicitation techniques.
  • User Stories are simple enough that people can learn to write them in a few minutes, being careful about always delivering business value.
  • The process of collaborating on defining and exploring stories builds team commitment and shared understanding of the business domain.
  • User Stories invite conversation for further decomposition and exploration.
  • To facilitate estimating, planning, and delivery, many agile teams supplement User Stories with analysis models (such as a data model, business rules, user acceptance tests, screen mock-ups or prototypes, context diagram, and state diagram).

Usage Considerations – Limitations

  • This conversational approach can challenge the team, since they do not have all the answers and detailed specifications up front.
  • Too many stories can inflate the backlog.
  • User Stories spawn more User Stories through decomposition, so the information must be organized to ensure it is current and relevant.
  • The collection of User Stories needs to be regularly refined and prioritized.
  • Teams can get too focused on individual User Stories and lose sight of the vision and the roadmap.
  • This technique includes the desired feature. Teams can form habits overlooking the value statement (WHY) and instead focus on the feature (WHAT).