SCRUM

28/11/18
AGILE EXTENSION TO THE BABOK GUIDE
As the Agile Extension highlights, any member of an agile team may
engage in the process of business analysis.
In the Agile Extension, we have called particular attention to the
mind‐set a business analysis practitioner must have in order to
effectively contribute to delivery of ongoing value to stakeholders.
Business analysts should always work to ensure that requirements
are aligned with organizational goals and objectives and that all
stakeholders have a shared understanding of those goals,
objectives, and requirements.
They must also work to manage risks and validate that the
requirements, if delivered, will create real value for stakeholders.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
 Individuals and interactions over processes and tools.
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
 Principles Behind the Agile Manifesto
We follow these principles:
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to
a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals . Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying
information to and within a development team is face‐to‐face
conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity‐‐the art of maximizing the amount of work not done‐
‐is essential.
 11. The best architectures, requirements, and designs emerge from
self‐organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
The skills that developers
require to do this include business analysis, technical design,
programming in various languages and tools, testing, UI design,
technical writing, architecture, and whatever else is needed to
produce working software
Much like other approaches, business analysis is central to the
success
of agile projects
Not all agile projects
have the defined role of business analyst, but all agile projects do
practice business analysis. Business analysis may be done by one or
more members of an agile team.
In the agile world, software requirements are developed through
continual exploration of the business need
Requirements are elicited
and refined through an iterative process of planning, defining
acceptance criteria, prioritizing, developing, and reviewing the
results.
Throughout the iterative planning and analysis of requirements,
business analysis practitioners must constantly ensure that the
features requested by the users align with the product's business
goals, especially as the business goals evolve and change over time.
Agile business analysis is primarily about
increasing the delivery of business value to the sponsors and
customers of the project/product being developed
Agile business analysis is about ensuring the right information is
available to the development team in the right level of detail, at the
right time, so they can build the right product.
Artifacts such as personas, data models, use cases, story maps,
and business rules continue to be employed, but are kept as light
weight
as possible
Artifacts that are more quickly developed such as
diagrams, maps, and lists tend to provide more value to an agile
project than highly detailed specifications that slow down the
development of working software
Lower-fidelity artifacts are
developed for the sole purpose of building the software for a
specific
iteration and only need to be intelligible to the team during the
course
of the iteration
Long-lived artifacts, on the other hand, are intended to
be utilized beyond the scope of development. Long-lived artifacts
may
include the business case, charter, and documentation that is used
to
communicate what the software does and why it does it.
Whenever possible, in agile projects, high risk items are addressed
in
early iterations.
Facilitating risk discovery and assisting the team in
remaining focused on effective risk mitigation is central to the
analyst's role on an agile team.
By providing just
in-
time requirements, there is less rework of requirements because
only the requirements required for the current release are defined
in
detail and developed
As agile projects grow in size and
Breadth
Business analysis skills are needed to elicit and analyze
the needs and wishes of diverse stakeholders and for arriving at a
single, agreed upon product vision.
In some projects a dedicated business analyst role is unnecessary.
This
is not to say that business analysis is not conducted during the
course
of the project, only that it may be done by any member, or
members, of
the overall development team.
There are a variety of ways a business analyst can be engaged on an
agile project:
The analyst might be the facilitator in more complex environments,
bringing divergent business stakeholders together and helping
them speak with a single voice so the project team is not confused
by contradictory and conflicting perspectives.
•
The analyst might act as the product owner/customer
representative where they are empowered by the business to make
decisions on product features and priority.
•
The analyst could act as a surrogate product owner, in situations
where the business product owner is not available.
•
The analyst might act as the second in command to a business
product owner with limited availability.
•
The analyst could take the role of coach in an environment where
the business product owner is competent and committed, but has
limited IT project experience and the rest of the development team
are lacking in domain knowledge.
•
The analyst can play a central role in defining and communicating
the acceptance criteria prior to development work commencing.
•
The analyst can be involved in creating and executing acceptance
tests.
•
The analyst can ensure that the team remains focus on the business
value of the project.
•
The analyst can play a role in identifying important requirements
that might not have been actively represented by stakeholders
Irrespective of job titles, business analysis is about ensuring the
project is able to deliver the maximum value for customers and
adapting to the evolving business needs
business analysts
continue to utilize many of the tools
and techniques defined in A Guide to the Business Analysis Body of
Knowledge® (BABOK® Guide).
®
K® What has changed is the timing and the
usage of these techniques.
In an agile
environment, the success of the business analyst relies increasingly
on
such interpersonal skills as communication, facilitation, coaching
and
negotiation.
due to the inter-connectedness
of agile teams, if these skills are not being effectively utilized, the
number of requests that can be adequately understood and
prioritized
decreases.
This results in fewer items making it into the solution
implementation for a given release.
Analysts are required to approach requirements from a 360 degree
perspective. They are required to work with the business sponsor
on a
strategic level, and define how the proposed product or feature
aligns
with the organization's portfolio and strategy. They must then work
with the business and project team to break this vision down into
requirements that support effective and accurate estimation
The
analyst delivers just-in-time, detailed requirements to the
development team so they can build only what is required for a
specific iteration.
Business analysts play a key role in facilitating a shared
understanding
of the business need for the project with all stakeholders
Understanding and
presenting multiple view points, alongside the ability to hold
successful conversations, trump the need for formal, detailed, long
term artifacts such as requirement documents.
One of the key elements for a business analyst working in an agile
environment is the ability to use feedback to drive change.
It is
incumbent on the analyst to constantly review requirements with
the
business stakeholders and ensure that any shifts in business needs
are
accurately reflected in future releases of the product
The very nature of agile approaches requires all team members to
be
operating at a very high level of competency, skill, and
effectiveness
On successful agile teams,
business analysts are an integral component of the delivery team.
They
are active participants, if not the actual facilitators of planning,
analyzing, testing, and demonstrating activities.
The business analyst plays a central role in ensuring that the
product
road map clearly defines the product's strategic alignment to the
business need
The analyst holds shared responsibility in defining the
strategic criteria for completion of the project.
They require the ability to listen to and
understand feedback from all stakeholders and use this feedback to
drive the changes required to the requirements and priorities of the
project.
It is important to note that though
most agile approaches are iterative, not all iterative approaches are
agile.
Common traits amongst agile approaches include frequent product
releases,
high levels of real-time collaboration within the project team and
with
customers, reduced time intensive documentation, and regular,
recurring
assessments of value and risk to allow for change.
When working in an agile environment business analysts work to
transform business need
into business value.
The Agile
Extension to the BABOK
®
Guide does
not recommend one approach over another, nor does it
take a position on the benefits of applying agile approaches. Due
diligence and research is required when selecting an approach
In the Scrum framework work on a project is performed in a
series of iterations, called sprints, which generally last from 2 to 4
weeks. At the end of each sprint, the team must produce working
software of a high enough quality that it could potentially be
shipped
or otherwise delivered to a customer.
Within the Scrum framework there are four formal meetings,
known
as ceremonies:
•
sprint planning,
•
the daily scrum (or stand-up),
•
sprint reviews, and
•
sprint retrospectives
a product backlog lists the requirements for
an iteration prioritized by highest customer value. The backlog is a
collection of user stories that include the expected business value.
The
user stories are refined as the acceptance criteria is developed. As
the
team collaborates with the customer for the project, the product
backlog is updated with each request.
The product backlog is constantly prioritized, such that at any given
time it can be used to identify high priority requests for the solution
being developed. At the beginning of each sprint, in the sprint
planning
ceremony, the team reviews the prioritized product backlog and
identifies the customer's highest-priority user stories that can be
completed within the sprint period. The selected stories are then
placed on a smaller sprint backlog.

2.1.2Sprint Planning and Execution

During the sprint the team refines their understanding of the
selected
user stories and works to ensure that they are completed within
the
defined time limit of the sprint.
identify any
impediments that may prevent them from completing their work
The sprint is then
completed with a customer review and a retrospective. During the
customer review, the software is demonstrated and the customer
provides feedback. During the retrospective, the team meets and
collaborates to find ways to improve both the product and their
processes used to deliver the product. Both the customer review
and
the retrospective may identify additional items that feed into the
product backlog. These items are then used to re-prioritize the
product backlog for the next sprint planning session.
2.1.3 Roles and Responsibilities
In Scrum, there are three roles

Product Owner. The product owner provides the overall vision

and direction of the product. They are responsible for defining the
product backlog and perform backlog prioritization according to
customer value.

Scrum Master: The scrum master ensures the team's Scrum

processes are followed and the team functions well through
collaboration and facilitation. They manage any impediments that
may prevent the team from accomplishing work and shield the
team from external interferences.
The Team: The team is responsible for developing and delivering
the product. They collaborate with the product owner to determine
what user stories will be delivered in a sprint and commit to
delivery of the user stories.

2.1.4Business Analysis in Scrum

While Scrum focuses on value driven development it does not address business analysis
activities in detail and many of these activities occur as implicit steps in the scrum framework.
The following illustration shows the typical scrum life cycle with business analysis techniques
superimposed.

The product backlog is built through a combination of enterprise

analysis work (identifying gaps and new capabilities required to
accomplish organizational goals and defining their value to the
organization) and solution assessment and validation (identifying
ways in which the existing solution can be enhanced to better
deliver
business value). Within a sprint, business analysis activities focus on
eliciting the requirements for the sprint backlog items being
worked
and the acceptance criteria for those items. This approach is
frequently referred to as just-in-time requirements elicitation;
developing only what is required for the current sprint and only
done
to the level of detail required to enable the team to build the
product
and acceptance criteria.
Techniques
Backlog Management: Backlog management is the primary
method of handling both requirements prioritization and change
management in most agile approaches.
Retrospectives: Retrospectives are a common practice used by
agile teams seeking to improve their ways of working. Business
analysts should look for feedback on the requirements they provide
to the team and how and when those requirements are provided in
order to find ways to improve their processes.
MoSCoW Prioritization: MoSCoW Prioritization is used to
prioritize stories (or other elements). MoSCoW provides a way to
reach a common understanding on relative importance of
delivering a story or other piece of business value in the product.
2.2Extreme Programming (XP)
Extreme Programing (XP) began being used by development teams
in the mid-1990s.
XP's primary
focus is on the engineering aspects of agile software development
and
is based on 12 practices in four categories.

2.2.1User Stories

Each user story is normally accompanied

by a list of acceptance criteria which identify specific details about
the
story.
Stories are used to:
•
prioritize work into iterations,
•
identify risk associated with a request,
•
estimate the effort required to deliver the request, and
•
establish a conversation between the team and the product owner
around the subject of the real business need, in order to confirm a
common understanding of what has to be done.

2.2.4Business Analysis in XP
When XP is applied at a larger scale, or with customers who do not
have a clear vision of the incremental value of features, a business
analyst adds significant value in facilitating and negotiating with
stakeholders to reach a shared understanding of what the most
valuable deliverables will be. A business analyst can also contribute
by
facilitating story mapping.
In traditional XP, the user stories are created and managed directly
by
the customer. This can lead to unfiltered requirements.
Business analysis skills can be
used to ensure underlying problems are being addressed in a way
that
works for most, if not all, of the stakeholders on the project, as well
as
ensure thorough acceptance criteria have been collected for each
user
story. On projects where there is a dedicated business analyst they
often perform story decomposition and elaboration activities.
Story Mapping: Story maps show relationships between user
stories and larger activities that the user must be able to
accomplish.
Story Decomposition: Epics, features, or minimally marketable
features (MMF) tie groups of user stories together into larger
packages that can be discussed with stakeholders.
Story Elaboration: Defines the detailed design and acceptance
criteria for a user story on a just-in-time / just-enough basis.

Kanban
With roots in the Theory of Constraints
and Lean product development, Kanban has five key principles:
•
visualize the work,
•
limit work in process,
•
focus on flow,
•
make process policies explicit, and
•
continually improve.
Unlike the other agile frameworks that we have discussed, Kanban
development does not require fixed iterations. Work moves
through
the development process as a continuous flow of activity. A key
feature
of Kanban is to limit the amount of work underway at any one time
(referred to as the Work in Progress Limit or WIP). In this approach
the team works only on a fixed number of items at any one time
and
work may begin on a new item only when it is required to maintain
flow downstream and after the previous item has been completed.

Queues
Kanban relies on the use of work queues to manage the flow of
activities that must take place to deliver a working product.
Kanban approach is often combined with approaches such as Scrum
where the backlog is used as the
implementation for the queue. When a new feature request is
received,
it is assessed for relative priority and urgency and then placed into
the
queue in its relative position, maintaining the order by priority.
Analogous to the Scrum technique of managing the product
backlog,
the team evaluates the features waiting in the input queue to see if
they are too large or out of scope for the upcoming release. For
items
that are too large to be completed before a planned release date,
the
project team will break the item down (decompose it) into smaller
chunks of work, deciding which will be included in the release and
which will not. The team then reassesses the priority of the items in
the queue and reorders them as needed to maintain a continuous,
prioritized flow of work.

2.3.2Roles and Responsibilities

Kanban does not include defined, mandated roles or business
analysis
Practices. The Kanban approach also attempts to bring the project
team together by increasing communication and collaboration,
enabling the team to work together as a collective and cohesive
unit.

2.3.3Business Analysis in Kanban

Business analysis, like all activities in the Kanban approach, occurs
in a
constant and continuous flow through the life of a project. business
analysis techniques are
used to elicit new product features. Requirements analysis
practices
are then used to prioritize the requirements based on business
value,
while also continuously using business analysis techniques for
scoping
the product and managing the queue of requirements.
When planning and managing tasks in the Kanban approach,
Service
Level Agreements (SLAs) are used to maintain the estimates for
how
long a feature or chunk of work will take to be completed.
This approach forces a
business analyst to focus on planning and monitoring activities,
enabling constant revision and refinement of estimates as each
new
request enters the analysis portion of the cycle. In a Kanban project
the business analyst only begins to define requirements for a new
work item when the queue steps forward.

2.4Levels of Planning in Agile Approaches

Just-in-time and just enough

requirements that are consistently validated by the business are
central to the analyst's role in agile approaches.
When undergoing planning exercises in the agile world, it is helpful
to
consider how the analyst's role differs from plan-driven
development
approaches. In agile the role of the analyst is central to the value of
the
project. The analyst holds a key role in maximizing value by
facilitating
the interactions with all the project stakeholders. Exceptionally high
communication, facilitation, and negotiation skills are an important
set
of tools for analysts in the agile environment
Successful agile projects follow a consistent planning cadence of
•
strategy,
•
release,
•
iteration,
•
daily, and
•
continuous.
Through this cadence, the requirements for the project are
progressively elaborated to an appropriate level of detail. One of
the key tenets of agile is to perform
a sufficient level of analysis at each planning level. Too much
analysis up front can result in the creation of documents that are
subject to
change, require the business user to explain their needs multiple
times, and may not be necessary to achieve the goals of the
project.
Too little analysis up front can result in irresponsible commitments,
rework, and a lack of focus on customer value. Most agile teams
focus
on daily work, iteration, and release planning.
Strategy Planning
Projects and product development efforts start with a vision of the
business direction or need. The vision includes the what, why, and
success criteria for the effort. The vision is often associated with a
roadmap. The roadmap includes the high-level scope and may
include
an initial architecture. In addition to activities such as establishing a
vision, scope, and roadmap, the strategy work on an agile project
includes the initial creation of a feature request list.
At a strategic level, the person who owns the product or is leading
the
initiative helps the delivery team to
•
identify the desired business value,
•
define the business context,
•
define the context of the solution needed,
•
identify and outlines the steps to realize the vision with the
delivery team,
•
identify the principles which should be used when prioritizing
work, and
•
define the product roadmap.
Strong enterprise business analysis skills are required to effectively
plan a strategy for an agile project.
without direction based on business value and a clearly
defined scope and audience, agile projects are at risk for delivering
incremental features that never come together to create end-to-
end
value for any one customer group. Without a roadmap and success
criteria for the product, agile projects could conceivably go on
forever,
wasting time, money, and other resources in the process.

2.4.2Release Planning
Release planning is the activity in which the person who owns the
product groups activities and allocates them to teams.
2.4.3Iteration Planning
Many agile teams work in fixed time windows called sprints or
Iterations.
Prior to that iteration planning meeting, the
items in the feature request list that are being considered for the
iteration need to be sufficiently understood, thus enabling the
team to
responsibly make a commitment. In Scrum this is known as
grooming
the backlog.
This work is comprised of
requirement communication and analysis, with additional
elicitation
and documentation as needed.
In iteration planning the work that will be performed in the sprint is
identified, estimated, reviewed, and committed to be completed.
At the end of iteration planning, the delivery team
commits to delivering an increment of working, tested, and
deployable
code.
After an iteration has been completed an iteration review or
product
demonstration is held. The results of the product demonstration
feed
into the next cycle of iteration planning. The product
demonstration
meeting is similar to light-weight user acceptance testing and is
generally limited to a maximum of 4 hours.
During the product demonstration
•
the delivery team demonstrates how the code that was developed
meets the acceptance criteria,
the owner of the product and delivery team review the state of the
business, the market, and the technology, and re-prioritize the
feature request list for the next iteration.
While a
working product is the expected output of each iteration, many
agile
teams will wait to release a product until several iterations worth of
work have been completed. The team must determine the
appropriate
trade-off point between the cost to deliver the latest product and
the amount of new or improved functionality that will be delivered
to the
customer base. Iterations proceed until enough features have been
done to complete or release a product.
2.4.4Daily Work Planning
The daily meeting is usually a fifteen minute meeting designed to
clarify the state of the work
During the daily meeting the team
•
gets a global snapshot of the project,
•
discovers any new dependencies,
•
addresses any personal needs of committed individuals, and
•
adjusts the work plan to meet the needs of the day and ensure the
team can deliver on the iteration commitment.
Frequently the dialogue held during this meeting uncovers items
that
lack clarity or require further analysis. The team then identifies a
plan
for dealing with these impediments to the project. This often
entails
assigning someone to do further business analysis work for
elicitation
and analysis on the impacted requirements
2.4.5Continuous Activity Planning
Here are some guiding principles that those conducting business
analysis may find helpful:
•
Start with value and keep the team true to value. It is vital that the
individual holding the business analysis role is paying close
attention to the project's business value.
•
Low-fidelity artifacts serve as an enabler of business value by
creating context and generating shared understanding. However,
they do not replace, or even take precedence over effective
collaboration and conversation.
•
Business analysis is about facilitating discussion and
understanding. Business analysts may not possess the depth of
Levels of Planning in Agile Approaches
Business Analysis in Agile Approaches
understanding about the business as does the business sponsor, or
as much about technology as the technology team
®
24
Agile Extension to the BABOK® Guide
Complimentary Member Copy. Not for Redistribution or Resale.
Operate in the best interest of the business over time. Responsibly
balance value and capacity to deliver.
•
Identify and communicate competing concerns and gaps in
understanding between the business and technology. Ensure that
common understanding is reached.
•
Resources are limited and valuable. Always assist in maximizing
value over time.
•
Assist the team to take action. Effectively communicate what is
required when taking the next steps. Ensure that feedback is clearly
understood and acted on by the team.
•
Deliver incrementally and iteratively. Do the smallest, simplest
thing that could possibly work. Iterate to reach minimal value.
Progressively elaborate in small pieces while testing assumptions
and articulating clear acceptance criteria.
•
Produce the smallest amount of documentation that meets the
needs of the team and deliver it just in time.
Mapping Agile Techniques to the
K®
BABOK® Guide
Chapter THREE
3.1Business Analysis Planning and Monitoring
3.1.1Plan Business Analysis Approach (2.1)
Some business analysis work will generally
be performed up front to define a vision for the project and how
the problem
or opportunity will be addressed, but detailed analysis will be
performed as needed. If the problems the software is supposed to
solve are unclear,
or several stakeholder groups have conflicting interests, it may be
necessary to do business analysis work prior to the beginning of a
project. That up-front analysis will provide a better understanding
of
underlying problems, their drivers, and the goals of the
stakeholders
in order to reach agreement on the vision for the product.
.1Agile Techniques
Backlog Management: Backlog management is the primary
method of handling requirements planning, prioritization, and
change management in most agile approaches. Because the
backlog
often describes the breakdown of requirements in the relative
order in which the features should be implemented, it can serve as
a description for the order in which business analysis activities will
take place. Some backlogs also include business analysis activities
as tasks to be completed in a development cycle.
Planning Workshop: Business analysts participate in planning
workshops to determine the business analysis effort and activities
to support a team objective.
Real Options: Real option analysis may help determine when
business analysis needs to be conducted to investigate a particular
business issue.
Retrospectives: The feedback from prior retrospectives should be
considered when selecting the approach.
3.1.2Conduct Stakeholder Analysis (2.2)
In agile development, business
analysts need to consider the impact of the agile cadence on the
stakeholder and how things like progress elaboration will affect
expectations. Business analysts need ask questions such as, can the
stakeholder participate in updating the processes, interactions, and
product specifications during the course of the project?.
Prototyping
and frequent feedback from stakeholders can help to refine what is
known about the needs of a stakeholder or stakeholder group.
.1Agile Techniques
Collaborative Games: Many collaborative games can be used to
understand the perspectives of various stakeholder groups.
Personas: Personas can help the analyst or development team by
enabling them to better describe and visualize the needs of a group
or archetype of stakeholders, understanding how the archetype
will derive value from a solution, potential risks for the archetype,
and other information that will help the team to better understand
the needs of the stakeholder groups involved with the project.
3.1.3Plan Business Analysis Activities (2.3)
Business analysis activities are planned as needed, usually at the
start
of the project and refined with each iteration or when a new work
item
is ready for analysis. The business analyst should always be aware
of
and prepared to address the next iteration of work, keeping the
vision
for the product and evolution of incremental value in mind
progressive elaboration of documentation
much of the elaboration is
replaced by interactions and ceremony so these outcomes need to
be
accomplished with activities addressed in the communication plan
.1Agile Techniques
Planning Workshop: Decisions regarding business analysis
activities will usually be made during a planning workshop.
3.1.4Plan Business Analysis Communication (2.4)
During development, formal communication of requirements is
generally replaced with ad-hoc informal discussions and modeling.
Some deliverables are replaced by specific interactions or
ceremonies.
By definition, these interactions and ceremonies require real-time
participation by the business analyst. Formal documentation may
be
developed following development of the software to ensure
knowledge retention by the organization or to meet regulatory
requirements.
.1Agile Techniques
Personas: These may prove useful in assessing the needs and
availability of the stakeholder groups for the necessary
communication in an agile approach and how you will organize this
agile communication.
Planning workshop
3.1.5Plan Requirements Management Process
In agile approaches, requirements management is focused on
ensuring
that the intake of new work by the team matches the priorities of
the
stakeholders and/or sponsor, and delivers value to the business.
Agile
approaches stress the importance of welcoming changing
requirements. This means that the ordering of work items that are
ready for development may be changed at any time.
.1Agile Techniques
.2Backlog Management
3.1.6Manage Business Analysis Performance (2.6)
This activity will be performed on an ongoing basis as the business
analyst learns to work effectively with stakeholders and the
development team. As everyone involved better understands how
to
work together to deliver value, the business analysis process,
methods,
or techniques in use may need to change. Effective business
analysis
performance will result in limited rework of the requirements
documentation, effective prioritization and scoping of
requirements,
and clear communication of need to the development team.
.1Agile Techniques
Retrospectives
Value Stream Mapping: Value stream mapping can be useful in
assessing how business analysis activities are contributing to the
delivery of value to the customer and identifying activities that may
not be adding value.
3.2Elicitation
Effective elicitation ensures that the stakeholders' actual
underlying needs are understood, rather than stated or superficial
desires. Elicitation is ongoing throughout the project and
performed in
conjunction with analysis activities (as compared to traditional
approaches, where it is possible to perform elicitation as a distinct
activity or phase).
On agile projects, the most common pattern is an initial elicitation
activity which looks at the high level needs, goals, and scope of the
solution. In every iteration, there is more detailed elicitation for the
user stories which constitute the backlog items for that iteration.
3.2.1Prepare for Elicitation (3.1)
Preparing for elicitation changes during the life of the project. Early
on,
it is done by the business analyst to coordinate supporting
materials
and schedule resources to define the high-level requirements.
During
this phase of the project, elicitation activities will generally be
structured as more exploratory sessions to understand underlying
needs, build out the initial list of feature requests, and determine
what
is most valuable to work on. As the project progresses, work is
coordinated by prioritization of the backlog. This will often result in
more structured and directed elicitation sessions designed to
understand low-level details of a particular feature or requirement.
Stakeholders may work directly with the developers to elaborate
requirements. In that situation, the developer is performing
business
analysis activities for the project and should be trained in good
business analysis practices.
Where this is not possible, the business
analyst will often act as a proxy.
In preparation for elicitation activities, it is recommended that the
business analyst perform customer research and a stakeholder
analysis to understand the needs, wants, and preferences of the
stakeholders they will be working with. By tailoring elicitation
discussions to the stakeholder, business analysts can maximize the
efficiency and value of the elicitation session.
.1Agile Techniques
Personas: Personas may provide insight into the particular needs
of a stakeholder or the techniques that will be most effective in
understanding those needs.
•
User Story: A user story will identify the role for whom the story
provides value (and therefore identify the stakeholders who can
elaborate on that value).
•
Story Mapping: Developing a user story map with users and other
stakeholders will ensure the stories implemented in the solution
will come together as a cohesive product in the end.
3.2.2Conduct Elicitation Activity (3.2) Elicitation activities are
conducted on a frequent basis throughout the
project, possibly even daily. Early on, elicitation is performed to
define
high-level requirements or a vision for the product. As the project
progresses, stakeholders interact with the development team
directly
during iteration planning and development.
These elicitation activities often occur in
workshops with product users and other stakeholders
.1Agile Techniques
•
Behaviour Driven Development (BDD): Stakeholders may find it
easier to articulate their needs by providing examples rather than
through abstract models.
Collaborative Games: Collaborative games encourage participants
in an elicitation activity to collaborate in building a joint
understanding of a problem or a solution.
3.2.3Document Elicitation Results (3.3)
A major value of documentation is that it can be used for long-term
knowledge retention. Agile approaches aim to minimize the time
between the development of requirements and their
implementation
in software, reducing the overall value of that documentation to
the
team. Records of elicitation activities should be kept to ensure that
key
decisions can be understood at a later date, or to ensure that
regulatory or governance requirements are met. It is important to
note
that documentation should not be limited to purely textual artifacts
to
represent requirements and context for requirements. Visualizing
requirements through models, mock-ups, and prototypes an be a
quick
mechanism for conveying a large amount of information about a
solution. However, care should also be taken when using
visualizations
that mimic the solution, as it is important to define requirements
without unnecessarily limiting the solution options.
.1Agile Techniques
•
Lightweight Documentation: See this section for guidelines on
developing documentation. In most cases, there will not be
separate documentation of the elicitation and analysis work.
3.2.4Confirm Elicitation Results (3.4)
3.3Requirements Management and
Communication
Requirements Management and Communication (Chapter 4 of the
BABOK® Guide) describes how business analysts manage conflicts,
®
issues, and changes in order to ensure that stakeholders and the
project team remain in agreement on the solution scope, how
requirements are communicated to stakeholders, and how
knowledge
gained by the business analyst is maintained for future use. This is
not
a one-time activity, but is performed continuously throughout the
life
of the project.
3.3.1Manage Solution Scope and Requirements
As agile projects unfold, the scope is defined with increasing
specificity. Depending on the agile approach being used, the
specific
details of the scope can be found in the product backlog or a similar
document.
Based on the level of elaboration the product backlog itself
may vary in its own level of detail.
Backlog Management: Most agile teams use the product backlog
to manage both solution scope and requirements.
Story Decomposition: Story Decomposition enables planning at
the appropriate level of granularity and supports the just-in-time
nature of agile approaches.
3.3.2Manage Requirements Traceability (4.2)
On agile projects, everything is connected back to the strategic
themes,
epics, and stories that are used to define the project. This is
maintained
by the product owner or the business analyst.
3.3.5Communicate Requirements (4.5)
In agile projects requirements are communicated to developers on
an
on-going basis. Requirements communication most often happens
in
release planning meetings where themes and stories are reviewed
and
selected for release. They are also discussed in more detail in
iteration
planning meetings where the models and specifications are
selected
and discussed among the team and the product owner. In these
iteration planning meetings, risks are also reviewed and discussed.
Additionally, daily team meetings are often used as an opportunity
for
developers to get clarification or identify ambiguous requirements,
where the business analyst communicates the details of the
requirements or clarifies ambiguity. Models and visualizations for
requirements can be a quick way to communicate detailed
requirements and facilitate understanding of the problem the
solution
needs to solve.
3.4Enterprise Analysis
This knowledge area describes problem
definition and analysis, business case development, feasibility
studies,
and the definition of solution scope.
Enterprise analysis is about
identifying the business need, opportunity or problem to be solved
and deciding on the appropriate approach to addressing the need.
3.4.1Define Business Need (5.1)
Define Business Need, as described in BABOK® Guide, extends to
agile
®
approaches.
.1Agile Techniques
•
Business Capability Analysis: A business need will usually
correspond to the development of a new capability or the
enhancement of an existing capability.
•
Collaborative Games: Some collaborative games can be useful in
exposing un-met business needs.
3.4.2Assess Capability Gaps (5.2)
3.4.3Determine Solution Approach (5.3)
Agile is a solution approach. It may be selected in order to provide a
faster delivery of value than traditional approaches, or because the
problem area needs to be explored. It also supports incremental
delivery so the solution approach can be evolved over the course of
the
project. This approach provides flexibility in determining the best
solution to a problem or opportunity being explored. A solution
may
begin as a custom developed evolutionary prototype, then
transition
to a customized COTS solution or become an integrated part of
another
product, for example. As As such, on agile projects the solution
approach
can sometimes change during the course of development.
Purpose Alignment Model: The purpose alignment model can
provide guidance regarding the best solution approach to take for a
given business need.

Agile Techniques
4.1A Context for Agile Business Analysis
This chapter of the Agile Extension to the BABOK® Guide provides
analysts
K®
with techniques and tools that will assist them in excelling in the
agile world.
In order for the techniques and skills presented in this section to be
applied
successfully, there are some foundational principles that need to be
understood. These principles are supported by a number of
practical
techniques that can be used by practitioners when they undertake
business
analysis on agile projects.
The principles that guide successful business analysis can be
categorized into
two distinct frameworks:
•
the Discovery Framework and
•
the Delivery Framework.
The Discovery Framework deals with the whats and the whys of the
product.
Effective discovery is supported by three underlying principles:
•
See The Whole,
•
Think as a Customer, and
•
Analyze to Determine What is Valuable.
The Delivery Framework deals with the hows and the whens of the
product.
Effective delivery is supported by four underlying principles:
•
Get Real Using Examples,
•
Understand What is Doable,
•
Stimulate Collaboration and Continuous Improvement, and
•
Avoid Waste.
The following table shows the Agile Extension techniques that
support
each principle

Agile approaches tend to focus on continuous improvement in their

methods and technique. The techniques in the Agile Extension to
the
BABOK® Guide will be required to reviewed and updated on a
regular
K®
basis.
4.3BA Techniques Mapped to Agile
Guidelines
The following table maps techniques as described in the BABOK®
Guide
®
to the principles for agile business analysis presented in this
document.
4.4Guidelines for Agile Business Analysis
The following 7 guidelines for practicing business analysis inside an
agile context, are based on the values and principles of the Agile
Manifesto. Together these guidelines embody the discipline of agile
business analysis.
These guidelines provide valuable context when applying the
various
techniques described in this chapter:
In an agile context, business analysis views the entire system of
people, process, and technology to find where true value lies and to
help organizations maximize the likelihood of delivering a valuable
and valued solution.
•
Agile analysis pays special attention to the voice of the customer to
understand their values and expectations.
•
To confirm what is valuable, it is common to use concrete examples
to both elicit and validate product needs.
•
Technology stakeholders are empowered by effectively analyzed
needs. It helps them determine how much work they can deliver at
any given point in time, identify product requirements options, and
provide recommendations to business partners on solutions.
•
Facilitative techniques enable efficient and effective collaboration
and accelerate a team's ability to define and deliver products.
•
Trust and safety are integral to healthy teams and allows them to
transparently identify improvement opportunities. Improving both
product and process is imperative; therefore agile teams
continually strive to get better.
•
Always be on the lookout for, and avoid, anything wasteful.
4.5The Discovery Framework
The Discovery Framework deals with the whats and the whys of the
product. Effective discovery is supported by three underlying
principles:
•
See The Whole,
•
Think as a Customer, and
•
Analyze to Determine What is Valuable.
4.5.1See The Whole
It describes
not just what a system is but how it will be used.
.1Business Capability Analysis
Purpose
Provide a framework for product scoping and release planning by
•
generating a shared understanding of the outcomes of a business
or
product,
•
identifying alignment with a strategy and specific performance
gaps, and
•
providing a scope and prioritization filter that is stable and has low
friction to maintain over time.
Description
Business capability analysis is the analysis of the performance and
risk
associated with a set of business capabilities to identify specific
performance gaps and to prioritize these based on business value
and
risk. Business capabilities describe the ability of a business to act on
or
transform something that helps achieve a business goal or
objective.
Many product development efforts are an attempt to improve the
performance of a business capability or to deliver a new business
capability.
Agile approaches create a framework that facilitates frequent re
assessment
of business needs and value. The direction of the business
and the gaps required for the business to meet its objectives must
be
revisited for each iteration planning session, which generally occurs
every 2-4 weeks in most agile life-cycles.
This means that an agile
project team must maintain a constant view of the business
capabilities that are required for the business to be successful,
particularly those that are in scope for the product being delivered.
Elements
Capabilities
Capabilities are the abilities in a business to perform or transform
something. Capabilities should describe the purpose or outcome of
the
performance or transformation, not how the performance or
transformation is performed. It describes the what, as opposed to
the how. For example, sending a fax is not a capability; notifying
the
customer is the capability.
Using Capabilities
Capabilities impact business value through increasing or protecting
revenue, reducing or preventing cost, improving service, achieving
compliance, or positioning the company for the future in alignment
with the business strategy. Not all capabilities have the same level
of
value.
Performance Expectations
Since capabilities identify the abilities required to perform or
transform something, capabilities can be assessed to identify
explicit
performance expectations. When a capability is targeted for
improvement, a specific performance gap can be identified. The
performance gap is the difference between the current
performance
and the desired performance given the business strategy.
Risk Model
Risks in the performance of the capability fall into the following
categories:
•
business risk,
•
technology risk,
•
organizational risk, and
•
market risk.
Strategic Planning
Business capabilities for the current state and future state of an
organization can be used to determine where that organization
needs
to go in order to accomplish their business strategy and
imperatives.
As a result of performing a business capability assessment there is
generally a set of recommendations or proposals for solutions that
need to be put in place. This information forms the basis of a
product
road map and serves as a guide for release planning.
Capability Maps
Frequently organizations use capability maps to provide a graphic
view of elements involved in business capability analysis. The
following illustration demonstrates one element of a capability map
that would be part of a larger capabilities grid.
Usage Considerations
Capability analysis is useful when an organization changes its
business
focus or strategy, or there is more demand for change than there is
capacity to deliver. When the demand outweighs the capacity to
deliver, a large undifferentiated backlog of changes or
improvement
requests can result. Capability analysis helps to identify those
improvement requests that will advance the strategic goals of the
business. Upon completion of a project effort, the capability
analysis
can be updated to reflect improvements in performance and to
identify
the next most important capability performance gap to focus on.
The outcomes of a capability analysis serve as long-lived artifacts
that
represent a common view of the business. This can be used to
generate
shared understanding and align efforts. When the business strategy
changes or customer desires evolve, this model can be used to
rapidly
re-prioritize the list of wants for a solution (for example, re
prioritizing
the backlog).
Advantages
•
The advantages of capability analysis are that they result in a
shared articulation of outcomes, strategy, and performance. These
help create very focused and aligned initiatives. The model works
well with agile teams but it also helps identify opportunities that
are not technology based, including process, talent, and data
improvements.
•
The capability analysis helps align business initiatives across
multiple aspects of the organization.
Disadvantages
•
This model requires an organization to agree to collaborate on this
model.
•
When this model is created unilaterally or in a vacuum it fails to
deliver on the goals of alignment and shared understanding.
•
The model also requires a broad, cross-functional collaboration in
defining the capability model and the value framework.
.2Personas
Purpose
User centered design practices often use personas as a powerful
and
simple tool to help design software that users will enjoy and benefit
from.
Description
Personas are fictional characters or archetypes that exemplify the
way
that typical users interact with a product.
Usage Considerations
Use personas when you want to get a deeper understanding of key
stakeholders than one generally gets from a traditional role or actor
description. Personas help drive products that are fit for purpose
and
highly usable, because they are patterned after the subtle qualities
of
real people that will interact with the systems and how they do
their
job.
Disadvantages
•
Personas are fictional so there is often a tendency to create
personas that embody traits that are common to most users, but in
doing so creating a generic user that is not distinct or realistic. This
can lead to software that is trying to be everything to everyone.
•
Personas may not be a good substitute for a real user, if they are
available. Personas can distance a team from a user community.
.3Value Stream Mapping
Purpose
Value stream mapping (also known as material and information
flow
mapping) provides a complete, fact-based, time-series
representation
of the stream of activities required to deliver a product or service to
the customer (internal or external). It is used to identify areas of
potential improvement in an end-to-end process.
Description
A value stream represents the flow of material and information
required to bring a product and/or service from raw material to the
customer. A Value Stream Map (VSM) is a graphical representation
that captures a snapshot of the value stream.
There are two main types of value stream maps that are widely
used:
•
Current State Value Stream Map: Depicts a value stream as it is
applied by those who are responsible for executing it. It is usually
used as a starting point for analysis of an existing process to
identify improvement opportunities.
•
Future State Value Stream Map: Derived from the current state
and it shows what the value stream will look like after the
implementation of the improvements.
In an agile environment, this diagram is usually simple and drawn
on a
whiteboard. It can be used to help re-engineer business processes
to optimize use of software. It can also be used to re-engineer and
tune
the software development process itself, for example, to reduce
lead
time from product discovery to release.
Elements
The following is a broad description for one approach to building a
value stream map.
Prepare
1. Gather a cross-functional team. In the agile world this should
include people with business domain knowledge and technical
team members (such as developers, testers, and architects). Often
someone acting as the business analyst will facilitate the session.
2. Assign a value stream map owner. Ideally this is someone who
has
a deep understanding of the current process.
3. Select a product, a product family, or a service, and define the
scope of the value stream map.
4. Identify the customer value received so it can be traced back
Create Current State
The current value stream map can be captured following these
steps:
1. Observe or simulate value stream. Follow a product (or product
family) path by starting at the end closest to the customer and
record the process working your way backwards to the beginning.
2. Draw the value stream map.
3. Capture the information flow. The information that is vital for the
value stream to function. Information flow includes (but not
limited to) things such as orders, schedules, inventory time,
changeover time, cycle time, and number of operators involved.
4. Build a model that shows each step in the flow with hand-offs
and
sequence. To assist in the analysis needed to identify opportunities
for improvement in the process, ensure that you include time/cost
values onto the steps in the process. These time values may be
estimated, if needed. The more details available, the easier it is to
identify improvement opportunities.
5. Validate the value stream map. The initial draft of the current
value stream map must be validated before proceeding to the
improvement phase.
Analyze Current State
The current value stream map can be analyzed as described in Root
Cause Analysis of the BABOK® Guide version 2.0 (9.25 Root Cause
K®
Analysis) to identify value added steps (such as transformation
processes) from those that are non-value added (such as excessive
inventories).
The non-value added steps can be analyzed further to determine
which ones are necessary (such as meeting regulatory
requirements)
and which ones are unnecessary (such as excessive paperwork).
Create Future State
 Identify improvement areas.
 Capture the future state value stream map.
Once the future state is captured it can be used as the target
state of
the improvement initiative.
Implement Process Improvement
•
Identify supporting material required for implementing the
improvement such as information technology systems, training,
and changeover.
•
Implement the improvement.
In an agile project, value stream mapping will be most utilized
when
implementing process improvement. Often the changes to be
made in
the business process will require changes to or implementation
of
supporting software products.
Usage Considerations
Advantages
•
More comprehensive than a process flow diagram.
•
Provides a blueprint for implementing improvement.
•
Establishes a shared understanding of process wastes and
bottlenecks.
•
Provides a common visual language for diverse stakeholders.
Disadvantages
•
Not easy to construct in comparison with other visual modeling
techniques.
•
Can look daunting because of all the information captured.
•
Mapping paralysis. It is easy to get caught making the current
state
value stream map complete and perfect instead of proceeding to
the improvement stage.
•
Doesn't work well in knowledge based or non-linear work.
•
Leads to disruptive or “re-engineering” approach. Doesn't work
well with ongoing improvement efforts.
4.5.2Think as a Customer
Thinking like a customer is a key component of agile business
analysis.
The customer is the person who gets value from the product we
are
building. We start with a high level view of customer goals and
progressively decompose these into a more and more detailed
understanding of the specific needs that the product must meet
Agile analysis slices the delivery into the smallest practical
increments
that deliver business value over the life of the project.
It is important that agile analysis start with a holistic perspective,
in
order to help the team understand the overall product that
needs to be
delivered. The team collaborates with the customer to consider
the
user experience expected.
Backlog items represent work to be done and convey customer
thinking, and can be represented through prototypes, user
stories, use
cases, minimal marketable features, features, epics, or work
items.
The following sections describe commonly used techniques for
this
principle.
The techniques listed below are based on user stories:
•
Story Decomposition,
•
Story Elaboration,
•
Story Mapping, and
•
User Story.
A technique for prototyping a user interface and using that to
define
detailed requirements is:
•
Storyboarding
Description
The most common agile approach to story decomposition can be
described as “breadth-before-depth”:
•
start with a very high level picture of what business goals need
to
be achieved,
•
decompose those into smaller components that provide
increments
of valuable functionality (sometimes called minimally
marketable
feature sets or MMFs. Minimal viable products or MVPs are the
aggregation of multiple MMFs), and
•
split the components into user stories, and eventually elaborate
the
user stories with acceptance criteria, see “Story Elaboration” on
page 68.
A story that is too large or insufficiently understood to elaborate,
estimate, or deliver as a story is sometimes called an epic. Epics,
when
used, are later decomposed into smaller stories.
Epic = Epopeya
Different teams apply this technique in different ways. For
example,
some teams follow the model linearly, as shown in the above
diagram,
while other teams utilize techniques that work best in their
environment. For example, once a team has developed the MMF
(sometimes referred to as feature groups), they may employ use
cases instead of stories. The analyst's role here is to focus on
dynamic collaboration, facilitation, and communication in
getting acceptance for just what is required to develop and
deliver the product.

Usage Considerations
Story Decomposition is undertaken progressively. One of the
most
significant differences between agile projects and plan-driven
projects
is in the definition of detailed requirements. In agile projects the
initial
analysis activities will identify the goals, MMFs, and most of the
epics.
The initial set of user stories (probably for the first release of the
product) will be done in the project initiation activities. There is a
clear
understanding that these stories are likely to change and that
the
teams' understanding of the requirements will evolve over time.
Therefore, decomposing to the lowest level of detail is likely to
be a
wasteful activity early in the project.
Advantages
•
This decomposition technique helps avoid the common problem
of
getting lost in the detail of the user stories and losing the big-
picture context.
•
It is important that team members keep the project's goals and
objectives in mind, and while using the decomposition approach
they are able to trace implemented or requested functionality
back
to the driving business objectives.
•
Breaking the product into MMFs and epics helps with release-
level
planning, provides visibility into the development project, and
helps coordinate external program activities such as
organizational
change management and user training.
Disadvantages
•
A common anti-pattern is the temptation to treat story
decomposition as a way of reverting to detailed requirements
up-
front. Ensuring the continued emphasis on just-enough and just-
in-
time, means knowing when to stop decomposing.
.2Story Elaboration
Purpose
Story elaboration is a technique used to define the detailed
design and
acceptance criteria for a user story on a just-in-time/just-enough
basis. Story elaboration is an ongoing activity that is part of the
development process.
Description
Story elaboration is the lowest level of story decomposition and
the
process by which the story sentence is into broken down into
pieces of
work. This is often done by someone on the team who has
strong
business analysis skills, particularly with facilitation and
communication. Story elaboration is the technique through
which
detailed requirements are elicited and communicated to the
project
team.
During each iteration, the team that works on a story schedules
time to
expand on the story to understand the detail. Often (but not
always)
this is completed in a short workshop with the programmers
who will
work on the story, the business SME or customer who needs the
story,
the person who will test the story, and someone acting as a
business
analyst to facilitate and challenge the story. Typically, story
elaboration is undertaken a few days ahead of the development
of the
story.
Story elaboration should be done on an as-needed, just-in-time
basis
for stories that have been determined to be in scope for the
upcoming
iteration
Story elaboration is a communication technique that helps
ensure the
correct product is built. In an agile project, the detailed
requirements
are produced by story elaboration. However, as opposed to plan
driven
approaches, and consistent with the just-in-time philosophy of
agile, the detailed requirements defined during story elaboration
contain only the requirement details for the piece of work that is
to be
completed in the coming release.
Elements
The result of story elaboration is a shared understanding among
the
participants of what the story means and what should be
delivered to
achieve the “Done” state for this story. The role of the business
analyst
in developing and communicating dynamic requirements
necessitates
a high degree of skill in both facilitation and communication.
Some teams uses tasks as a way to communicate their analysis of
the
user story. The outputs of effective story elaboration describe
and/or
document tasks that enable the team to successful deliver the
upcoming iteration. These outputs may include
•
task definitions and breakdowns,
•
examples and scenarios that explain the customer's intent for
the
story,
•
low-fidelity models that clarify the technical or process design
(for
example, data models, and data flow diagrams),
•
screen or report mock-ups,
•
acceptance criteria (test design specifications) to clarify how the
story will be tested, often in the <given><when><then> format
of
behavior driven development,
•
input/output data tables, and
•
other artifacts that will be useful in the development and testing
of
this story.
Usage Considerations
Advantages
•
The major advantage of story elaboration is that it decreases
elicitation time, and potentially documentation, by focusing on
current features. By elaborating on requirements only as they
are
needed, the team avoids the work of eliciting requirements for
features that may never be built or that will need to be changed
by
the time they are ready for implementation.
Disadvantages
•
For those who are relatively new to agile approaches, it can be
difficult to determine the best timing for conducting a story
elaboration. If conducted too early, the information may no
longer
be correct for the given release and will need to be re-elicited.
However, when collected too late, it can delay project team
progression to development.
•
Another challenge to implementing story elaboration is the
ability
to elicit the appropriate level of detail such that the
requirements
can be developed, tested, and compared to acceptance criteria.
.3Story Mapping
Purpose
Story mapping provides a visual and physical view of the
sequence of
activities to be supported by a solution. It uses a two-
dimensional grid
structure to show sequence and groupings of key aspects of the
product on the horizontal dimension, with detail and priority of
stories
on the vertical dimension.
Description
A story map is a tool to assist in creating understanding of
product
functionality, the flow of usage, and to assist with prioritizing
product
delivery (such as release planning).
A story map is designed to be an information radiator, used to
visualize a product's requests in the context of usage and
priority. The
story map is often placed on display for the project team during
release planning sessions. By analyzing the story map, the team
can
more readily identify dependencies generated as a result of the
intended flow through the user stories. The map can also be
used for
risk assessment and management by examining how the stories
will
need to work together in the context of delivering business
value.
Elements
The story map has a central backbone of elements that will make
up
the product. Above this backbone are the large feature sets
(activities)
that need to be delivered over the life of the project. The
backbone is a
sequential set of tasks that need to be enabled by the software.
Below
the backbone are the detailed stories that implement the
specific
pieces of functionality to enable the tasks to be accomplished.
Usage Considerations
Advantages
•
When the larger context of a product is not accounted for, agile
projects can be subject to getting mired in the details with an
inability to effectively string components together to create end-
to-
end business value. Story mapping helps avoid the common
problem of getting lost in the detail of the user stories and the
risk
of losing the big-picture context.
Disadvantages
•
Story mapping can become cumbersome where the product is
very
large and may require building a number of story maps that
cover a
large program of work. While story maps illustrate a flow, they
do
not analyze or illustrate dependencies between requirements
(though they can be used to help facilitate that analysis).
•
Environments that are not process oriented will find story maps
less useful.
.4User Story
User Stories are described in detail in the BABOK® Guide version
2.0
®
(9.33 User Stories). This information found here reflects and
expands
on that information in the context of agile development
approaches.
Purpose
A user story represents a small, concise statement of
functionality
needed to deliver value to a specific stakeholder.
User stories can be used
•
to capture and prioritize user needs,
•
as a basis of estimating and planning product delivery,
•
as a basis for generating user acceptance tests,
•
as a way to monitor progress in delivering of value,
•
as a unit for tracing related requirements,
•
as a basis for additional analysis, and
•
as a unit of project management and reporting.
Description
User stories provide a mechanism
for the product owner to scope, coordinate, and prioritize the
increments of user value for development. A story should be
short
enough to be written on a small paper note card, usually a 3×5
inch
index card or sticky note. Stories may also be recorded in an
electronic
system.
User stories capture 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 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 call for user stories to be
•
Independent,
•
Negotiable,
•
Valuable,
•
Estimable,
•
Small, and
•
Testable.
Elements
Title (optional)
The title of the story describes an activity that the user wants to
carry
out with the system. Typically, it is an active-verb goal phrase,
similar
to the way use cases are titled.
Description
There is no mandatory structure for user stories; however, the
most
popular format includes three components:
•
a user role or persona [WHO],
•
a necessary action, behaviour, or feature [WHAT], and
•
the benefit or business value received by the user when the
story is
implemented [WHY].
Usage example:
"As a < role>, I need to < behavior > so that < business value >."
An alternative format is: "In order to < business value >, as a <
role >, I
need to < behavior >."
This canonical format can also be used for stories used to
identify
quality attributes. For example:
"As a Security Officer, I need to only allow authorized users to
access
the xyz functionality so I can ensure we enforce abc security
directive".

Conversation
User stories serve as a reminder that the team needs to explore
and
understand the feature described in the story and the value that
it will
deliver to the customer. The story itself doesn't capture
everything
there is to know about the customer need, and the information
implied by the story can be supplemented by analysis models to
promote
shared understanding.
Acceptance Criteria
When a user story is well defined and understood, it is
accompanied by
acceptance criteria. Acceptance criteria define the boundaries of
a user
story and help product owners, customers, or business analysts
to
answer what they need to provide value with the product.
Acceptance criteria help developers identify when to stop adding
more
functionality and to derive tests for verification and validation
purposes. They can also be developed as a story becomes well
understood to enable the development team to verify that the
solution
will meet the user's needs.
Advantages
•
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.
•
Stories invite conversation for further decomposition and
exploration.
•
To facilitate estimating, planning, and delivery, many agile teams
supplement stories with analysis models (such as a data model,
business rules, user acceptance tests, screen mock-ups or
prototypes, context diagram, and state diagram).
Disadvantages
•
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.
•
Large, chunky stories (epics) can be vague and difficult to use
without breaking them down into small stories.
•
Stories spawn more stories via decomposition so the information
must be organized to ensure it is current and relevant (called
pruning or grooming).
•
The collection of stories needs to be managed (for example, with
backlog management).
•
Stories require context. If the team doesn't trace stories back
(through validation) or supplement them with higher-level
analysis
and vision artifacts, then the team can lose sight of the big
picture.
•
Some practitioners can be confused about the difference
between
use cases, user stories, and story techniques.
.5Storyboarding
Purpose
Storyboarding is used in conjunction with other techniques such
as
use cases, user stories, and prototyping to detail visually and
textually
the sequence of activities summing up different user interactions
with
the system or business.
Storyboarding serves
•
to elicit, elaborate, organize, and validate the requirements,
•
to communicate to developers what needs to be built,
•
to assisting in user interface design,
•
to show different variations of the proposed solution,
•
to align stakeholders with the vision of the proposed solution,
and
•
as an input to tests.
Description
Storyboards (also known as dialogue map, dialog hierarchy, or
navigation flow) use representative images and text to describe
a task,
a scenario, or a story. It can also be used with prototyping to
represent
parts of the system that are well understood or expensive and
unnecessary to produce via formal prototypes.
When used to describe the interaction with the system, the
storyboard
shows how screens will look and how they will flow from one to
another. When used to describe business organization, the
storyboard
shows the interaction with a business process such as back
office.
Storyboards can be developed using white-boards and sticky
notes or
using software.
Elements
Storyboards can be created in a workshop environment with
relevant
Stakeholders
Preparation
1. Identify main scenarios within the scope of the project. This
can be
derived from use cases or user stories or can be identified in a
customer visit or an information-gathering session with experts.
2. Select the scenarios that need to have a storyboard
developed.
While some scenarios need to be detailed in a storyboard, others
are obvious and can be omitted such as alternate scenarios and
exceptions.
3. Identify participants and schedule the session.
4. Arrange room and equipment such as flip charts, markers,
glue,
scissors, rulers, printers, and access to the internet.
Session
1. Have attendees create illustrations for the storyboards of the
selected scenarios.
2. Enhance storyboard illustrations with textual information such
as
optional interactions, unavailable interactions, further
stakeholder
requests not associated with the primary scenario, and general
notes associated with a specific step.
3. Make sure each storyboard stands on its own by adding
required
explanations as text.
Wrap up
At the end of the session, the business analyst reaches
consensus on
the high level flow of the developed storyboards.
After the workshop, the company templates may be used to
formally
document the outcome of the session, adding additional
elements to
the storyboards such as storyboard identification, description,
user,
trigger, input, output, and issues.
Usage Considerations
Advantages
•
Storyboarding can significantly reduce abstractness caused by
other techniques such as use cases and user stories.
•
Storyboards can be produced quickly and at a very low cost
compared to other techniques such as prototypes.
•
The intuitive nature of the storyboard encourages stakeholder
participation.
Disadvantages
•
Different look and feel than the final product.
•
Easy to get bogged down on how, rather than why.
4.5.3Analyze to Determine What is Valuable
The agile approach continuously assesses and prioritizes
business
value to ensure that the most valuable work is delivered at any
point in
time, always using the end customer perspective. It is also
imperative
to question the purpose behind requirements, challenging those
requirements that do not support the business goals. Agile
approaches
enable the art of maximizing the amount of work not done,
something
essential to deliver valuable software early and continuously.
The
techniques outlined in this section facilitate the valuation of
product
needs on an on-going basis.
The following sections describe commonly used techniques for
this
principle:
•
Backlog Management,
•
Business Value Definition,
•
Kano Analysis,
•
MoSCoW Prioritization, and
•
Purpose Alignment Model.
There are other techniques within the Agile Extension to the
BABO
K®
Guide, the
BABOK® Guide, and other ad hoc techniques that can be
K®
utilized here as well.
.1Backlog Management
Purpose
The backlog is a wish list of requests for features to be included
in a
product, and is the main mechanism for managing requirements
on an
agile project.
Description
The product backlog is established at the beginning of a project.
The
backlog is a fluid collection of stories that evolves over the
course of
the project as more is learned about the product and its
customers.
The product owner is responsible for ordering the items on the
backlog based on business value, feature importance, or other
relevant
criteria. When managing a backlog, items should be ordered
such that
the most important items occur at the top of the list and are
ordered
based on descending priority.
Elements
Items in the Backlog
The backlog can contain user stories, use cases, features,
functional requirements, and quality attribute stories as well as
items that have been added by the team to support
development of the requirements such as technical
infrastructure. To aid in ordering the backlog, items should be
expressed in such a way that the business value of the items
is clear. Product risk mitigation items may also get added to the
backlog as stories or pieces of work to be done.
Appropriate level of detail
Items with high order in the backlog will be developed in near-
term
releases, so they need to be detailed enough to allow the
development
team to estimate them with accuracy and be able to decompose
them
into the tasks needed to develop them, if needed. Items with
lower
priority can remain high-level and less precise until they rise in
the
order and need to be specified in more detail.
Estimation Accuracy
Items with high order in the backlog need to be estimated with
enough
accuracy to use them for planning releases. Items in lower order
also
need to be estimated, but with less accuracy since they are often
less
detailed. Estimates for time to complete items is often
maintained
within the backlog itself.
Prioritization
Items in the backlog are ordered relative to each other. Ordering
can
be established using numbering, value points, high/medium/low,
or
any other prioritization technique. The order of items on the
backlog is
likely to change over the course of the project, especially as the
product evolves and the team receives feedback from the
stakeholders
and customers. It is important to note that ordering near term
items is
valuable, but putting a lot of effort into ordering the backlog far
into
the future can be a wasteful activity because the farther out
backlog
items are subject to change.
Managing Changes to the Backlog
The backlog is the main mechanism for both managing change to
the
requirements on an agile project and for controlling scope.
When new
or changed requirements are identified, they are added to the
backlog
and ordered relative to the other items. The backlog is also used
to
track and manage reported defects or bugs.
Rigorous ordering of the backlog
allows the team to control the scope of the project and releases.
The product owner role is
responsible for managing the backlog, adding and ordering new
or
changed items, removing completed items, and revising the
order on
an ongoing basis. This process is sometimes referred to as
pruning or
grooming the backlog.
.2Business Value Definition
In order for a project to deliver value, the project team must first
be
able to identify whether a request is actually valuable to the
organization. Without a clear understanding of business value, it
is
possible for the project to deliver something that sounds
valuable but
is actually not.
A project creates business value when it delivers anything that
contributes to an organization's stated primary goals, for
example
•
increasing or protecting revenue,
•
reducing or avoiding costs,
•
improving service,
•
meeting regulatory or social obligations,
•
implementing a marketing strategy, and
•
developing staff.
Business value should be expressed as a range or set of benefits.
The
evolution of clarity about business value will develop
understanding of
why the project is needed. The most important aspect of
expressing
business value is the conversation that generates the shared
understanding.
Examples of good business value statement are:
•
This project will generate an additional $20 million in profit. The
model is based on the following assumptions:* We maintain 25%
of
the sales of existing product XYZ ($150 million a year).
•
The total cost of designing, producing, and marketing the
product is
$7.5 million.
•
Our product is first to market.
•
We are able to release the product in the spring.
.3Kano Analysis
Purpose
Kano analysis helps an agile team understand which product
characteristics or qualities will prove to be a significant
differentiator
in the marketplace and help to drive customer satisfaction.
Description
Kano analysis assists in identifying features that will have the
greatest
impact on customer satisfaction, either because they are
exceptionally
important or because their absence will cause intense
dissatisfaction.
This helps the team determine which features are most
important to
implement before releasing a product to market.
.4MoSCoW Prioritization
Purpose
To identify the most critical set of features or stories that will
deliver
business value and produced a sequenced, prioritized list.
Description
MoSCoW is a method to prioritize stories (or other elements) in
incremental and iterative approaches. MoSCoW provides a way
to
reach a common understanding on relative importance of
delivering a
story or other piece of business value in the product.
All stories in the backlog are valuable, but often not all of them
can be
delivered at the same time. MoSCoW provides a mechanism for
prioritizing stories in a backlog across multiple releases.
Prioritization
is important for any software development approach, but agile
approaches cannot succeed without constant and frequent
prioritization of work.
MoSCoW gets its name from an acronym formed by the
following
classifications of priority: Must have, Should have, Could have,
and
Won't have. The letter o is added to make the acronym
pronounceable.
The classifications are as follows:
•
Must: The
user stories that add significant value and constituent
the Minimal Marketable Feature set.
•
Should: The user stories that add distinct value, but are not
required features.
•
Could: The user stories that add some value, but have minimal
impact on features.
•
Won't: The user stories that add little to no value, and will not be
included as features.
There is an expectation that priorities can change over the life of
a
project, and priorities are reassessed on a regular basis.