Identify Added Business Value Paper 3-20-2016

1
Copyright ©2016 Shirley J. Sartin All Rights Reserved
Identify Added Business Value
Shirley J. Sartin
Updated 3/20/2016
Shirley J. Sartin, CBAP, PMP, PBA, CSM, BSAC has a career filled with IT and IS experiences with which she
leverages in helping customers and end users realize their needs.
Problem
Having worked as an analyst for many years I have had the great fortune to learn and use various types
of analysis and documentation methods. This knowledge has provided a basis from which to pull when
conducting analysis and while documenting the results. In the past few years it has become evident that
an improvement in analysis is needed in how we may identify a solution’s added value for the business.
Recently, while working on a scrum team this was confirmed since the team was invested in developing
a successful solution that was needed by the business and they wanted to understand the customer’s
value for the functionality they developed.
What I Knew
My practice is to abstract Business Strategy (or Vision) through Goals/Objectives, Features and Functions
all the way down to an implemented solution. A Business Use Case (BUC) is the result of a facilitated
discussion and functional requirements are elicited directly from the BUC. However, the added business
value is not readily understood for an implemented solution based on those functional requirements.
Additionally added value is not identified at each level along the abstracted hierarchy. e.g., the business
added value is unknown when identifying Strategy (Vision), Goals, Objectives, Features, or Functions.
Thus I need to ensure business functional requirements are traced through the hierarchy’s added value.
Further, at some point after a solution has been implemented a measurement should occur to ensure
actual business value is realized. Without the appropriate value identified how can any realized
business value be determined?
What I Learned
In 2015 I was introduced to Scaled Agile Framework for the Enterprise (SAFe) where I took on the role of
Product Owner (PO) and met with the Product Manager (PM) to discuss business need(s). I created user
stories to identify needed functionality based upon the identified needs. While learning the technique
for writing SAFe User Stories I realized the format of the user story could be used in providing a better
BUC description by identifying actor(s) (who) with a need for an activity (what is needed) and the value
of the suggested improvement (why). Thus I thought that in leveraging what I knew of different
methodologies it is possible to combine techniques to ensure a solution implementation is delivering
added value to my customers and thus, the business. However, once the user stories were consumed by
the scrum team I realized the stated added value was not appropriate. Value had not been properly
identified and I had to reconsider my approach.

2
After the sprints were completed I read Kevin Albrecht’s article about how he has successfully used
Impact Mapping to get away from solution first development, e.g. creating software before you have an
understanding of the needs. Kevin explained that the impact mapping process includes identifying
impact statements when discussing how an actor’s behavior changes to achieve a goal or how an actor
can prevent a goal. Further, he noted that the added value is identified as the impacts in the impact
map break down. The impact statement could be used as the added value when writing the user story
where the impact would appear after the words so that.
In reviewing Impact Mapping I found the following rules:
 Single Goal -> Measurable business goal that says why this is being done.
 Actor(s) -> One or more people or groups that affect or are affected by the goal and indicates for
whom this is being done or who could prevent this from being done.
 Impact(s) -> One or more impacts per Actor that indicates how that actor’s behavior will change
or how an actor could prevent the goal
 Deliverable(s) -> Zero or more deliverables per Impact that indicates what we could do to
accomplish or mitigate the impact.
Using the impact mapping rules above and the steps below I worked with the PM and identified impact
maps for my project.
1. Why are we doing this
2. Who/whom is affected
3. How behavior will change
4. What to do to accomplish or mitigate impact
An example of an impact map using the rules and steps is below.
The Finance Office determined the following
 Goal: Improve productivity of Information Systems Assets
 Actor: Finance Office
 Impact: Taxes will not have to be manually determined
 Deliverable: Update Payroll System with new Federal and State Tax Laws
Figure 1. Example Impact Map
This example impact map can be transitioned into a user story by following the format:
As an <Actor> I want/need <Deliverable> so that <Impact>.

3
Thus the user story would read:
As the Finance Office I need the Payroll System updated with new Federal and State
Tax Laws so that taxes will not have to be manually determined.
The value add of this user story is after so that. e.g., taxes will not have to be manually determined.
Note that the impact map and user story does not indicate how a solution would be designed. It simply
states what is needed by the business and the value add for implementing a solution. Is this a
measureable value add? Yes if we identify the cost of manual determination versus automated to
include the cost of reducing/eliminating risk, etc.
I tried impact mapping with my Product Manager when it was time to create the next set of user stories.
We found the impact mapping process to be very simple and quick since he knew the impacts for each
goal. Afterwards I created user stories based on the impact maps and that effort was also very simple
and resulted in valid user stories using impact map information.
What I Know Now
I have since incorporated impact mapping into my analysis process. This simple yet powerful technique
quickly and easily identifies value adds for my Product Manager and I can use it at all levels of either a
Requirements Hierarchy or a SAFe Hierarchy. I feel this technique would be of benefit to all analysts
looking to appropriately identify and trace/track business added value. For a further understanding of
Requirements Hierarchy, SAFe Hierarchy, or Impact Mapping please refer to those sections at the end of
this paper.
Applying Impact Mapping to Hierarchies
Having successfully used Impact Mapping I am confident in proposing the following methods for
identifying added value to all levels of both the Requirements Hierarchy and SAFe Hierarchy so relevant
added value is identified at all levels.
Requirements Hierarchy to Value Add
 Vision -> Goal(s) -> Objective(s) -> Feature(s) -> Function(s) -> Value Add(s)
o Create an impact map where the Vision is an Impact Map Goal and each deliverable is a
Business Goal
o Create impact maps where each Business Goal is an Impact Map Goal and each
deliverable is an Objective
o Create impact maps where each Objective is an Impact Map Goal and each deliverable
is a Feature
o Create impact maps where each Feature is an Impact Map Goal and each deliverable is
a Function
o Create impact maps where each Function is an Impact Map Goal and each deliverable is
one or more BUCs

4
Each level of abstraction, e.g., Vision to Business Goal, Business Goal to Objective, Objective to Feature,
Feature to Function, Function to BUC would have a value add identified in the impact statement (how
behavior will be changed). Thus these value adds could be measured at each level.
Value Add(s) are described in BUC summary. However, Value Add(s) may be further described in BUC
steps as the business process is described. For each BUC step realized solution the value adds can be
measured and also verified. BUC steps provide context from which business requirements are derived.
Should additional and/or specific Value Add(s) be identified in BUC steps then additional tracking/tracing
would be needed for value of a requirement. Note that not all steps in a use case are delivered as a
software solution.
SAFe Hierarchy to Value Add
 Theme -> Epic(s) -> Feature(s) -> Story(ies)
o Create an impact map where the Theme is an Impact Map Goal and each Deliverable is
an Epic
o Create an impact map where each Epic is an Impact Map Goal and each Deliverable is a
Feature
o Create an impact map where each Feature is an Impact Map Goal and each Deliverable
is a Story (Parent)
o Create an impact maps where each Story (Parent) is an Impact Map Goal and each
Deliverable is the Child Story
Each level of abstraction, e.g., Theme to Epic, Epic to Feature, Feature to Story would have a value add
identified in the impact statement (how behavior will be changed). Thus these value adds could be
measured at each level.
Additionally, after writing the user story the words after so that in each story is the Value Add(s).
However, Acceptance Criteria in a story could be abstracts of the Value Add(s) and thus can be a
measured value for each criteria. For each acceptance criteria realized in a user story the value add can
be measured and also verified.
Transition between Requirements Hierarchy and SAFe Hierarchy
There are times when an analyst must transition between completed BUCs and user stories. I am
proposing the following when transitioning between the two hierarchies as outlined, below may retain
the identified value add.
 Each Theme could be a Goal identified by the business and used to group SAFe Epics.
 Each SAFe Epic could be an Objective identified by the business and used to group SAFe
Features.
 Each SAFe Feature could be a Feature identified by the business and used to group SAFe
Stories.
 Each SAFe Story could be a Function identified by the business and used to group child SAFe
Stories

5
Note that BUCs used in Requirements Hierarchy are not used in SAFe
Hierarchy. SAFe Hierarchy ends with intent – not requirements.
Table 1. Hierarchy Transitions
SAFe
Hierarchy
Equivalent Requirements
Hierarchy
Theme Goal
Epic Objective
Feature Feature
Story Function
Hierarchies Defined
Requirements Hierarchy
 Organizational Strategy
o Set of Goals and Objectives guiding a company’s operations and providing a Vision for a
future state. (BABOK p.108)
o Vision
 Strategic or Tactical Importance (Business Need)
 Vision statements for the Information Systems (IS) Directorate that
serve to assist the Directorate in achieving/realizing XYZ Company’s
Mission. Note that these strategies may change annually as per the
company’s focus changing.
o Structure IS Department to support XYZ Company’s long-term
revenue target of $3 million
o Provide business with services that support revenue growth and
reduce operating costs across the company
o Deliver services that are predictable, reliable and repeatable
o Increase productivity of IS assets
o Improve IS responsiveness and agility in reacting to demands of
the business
o Goals
 Longer term, ongoing and qualitative statements of an organization’s state or
condition (BABOK p.113)
 BABOK p. 99 “most effective way to apply the capabilities of an enterprise in
order to reach a desired set of goals and objectives”…”collaborate with
stakeholders in order to identify a need of strategic or tactical importance (the
business need), enable the enterprise to address that need, and align the
resulting strategy for the change with higher and lower-level strategies.”
 Problems or opportunities to meet the Vision strategies. High level technology
goals for the IS Directorate include the following that enable strategies to be

6
created and services to be delivered with minimal risk of failure. These are
related to the Vision’s strategy statements and may also change annually.
 XYZ Company’s Goals
o Track all historical order changes as well as help planning efforts
for future order(s) completion
o Track and manage relationships between orders and dependent
data including transition between order receipt and order
shipment
o Objectives
 Goals that have been abstracted and are more descriptive and specific (BABOK
p.113)
 Objectives describe how to resolve/achieve goals and may be tested using
SMART (BABO p.113)
 Specific: describing something that has an observable outcome,
 Measurable: tracking and measuring the outcome,
 Achievable: testing the feasibility of the effort,
 Relevant: aligning with the enterprise’s vision, mission, and goals, and
 Time-bounded: defining a time frame that is consistent with the need.
 An example of the XYZ Company Objective
 Allow the user to create any number of orders, manage those orders
and navigate through the orders in the course of their job
 Capability
o Features or Functions of an enterprise or a solution (BABOK p.138)
 Features
o Capability(ies) are identified and are considered scope of effort in delivering on an
objective.
 Create, Manage and Navigate Orders
 Display and Manage Order Problems
 Display a Timeline of a Selected Order
 Record Order Activity
 Search, Alerting and Reporting on Orders
 Functions
o Functions are the result of Features that have been abstracted into specific functionality
and may be delivered in a solution.
o Example Functions of the Create, Manage and Navigate Orders Feature
 Assign tasks to an Order
 Create a generic Order
 Manually Assign Order Dependencies
 Designate a Task as Completed
o High level activities are then described as a process in the BUC format for each Function.
 Steps in the BUC become identifiable as high level business requirements.

7
o BUC steps described in detail are considered detailed level business requirements and
may contain additional information such as
 Business Rules
 Constraints, Assumptions, Risks, Dependencies (CARDs)
 Information about objects that are described in the process steps
 And more…
SAFe Hierarchy
SAFe has a three tier hierarchy of Epics, Features, and User Stories (Stories) to describe functional
system behavior. While SAFe Epics and Features provide a larger contextual view1
, SAFe Stories are
intended to represent independent behavior that is implemented incrementally. Stories can also be
abstracted, or elaborated into dependent child stories. Regardless the level of abstraction such as
parent vs. child vs. grandchild, Stories are formatted with the expression as indicated below to assist in
providing an understanding of who is using the system, what they are doing with it and finally why they
are doing it.
As a <type of> User I need the ability to <fill in the blank> so that <how will this story help the user>.
Acceptance criteria are then identified for each of the Stories. These criteria help to ensure boundaries
for the Story, assist with system quality, and also serve to indicate that a Story is completed.
Acceptance criteria also represent the needs to confirm when a story is completed and working as
intended. <ref. http://www.boost.co.nz/blog/2010/09/acceptance-criteria/>
The SAFe hierarchy is described below in the order in which they are to be abstracted.
 Theme
o Although not identified by Scaled Agile Framework, a Theme is used in Rally (Rally
Software Development Corporation) to group Epics.
 Epic
o Enterprise initiatives that are substantial and may be cross-cutting with multiple
organizations affected. Reference http://scaledagileframework.com/glossary/#E
 Feature
o Services provided by system to fulfill stakeholder needs. Features are prioritized and
sequenced so as to deliver in a program increment. Reference
http://scaledagileframework.com/glossary/#F Features are grouped together under an
Epic(s).
 Story
o Agile replacement for traditional forms of requirement specifications and are small,
independent behaviors to be implemented incrementally. Each story provides value to
the business. Reference http://scaledagileframework.com/glossary/#S. Story is the
intent while acceptance criteria indicate the capability that is expected to be delivered.
This is not indicating how to build a solution but what should be expected upon
1
Although Epic Value Statements (reference Epic Abstract) use a Forward-Looking Position Statement that serves
to “…capture, organize and communicate key information about an epic” this paper proposes another method to
initiate a meaningful discussion for epics and also features and user stories.

8
implementation of the story. While this is a simplified explanation of Stories it is
intended to provide enough information to understand what can be leveraged. 2
 Task
o Single or multiple tasks are efforts by the Scrum team to deliver a Story.
Impact Mapping Explained
Thanks to Kevin Albrecht for sharing his Impact Mapping article Escaping Solution-First Development
through Impact Mapping. Not only did I learn about issues with solution-first development where
solutions are created before there is an understanding of the problem but Kevin also provided a list of
sure signs a software solution is being built before understanding the business need. These signs
include:
 Software that is released but not used
 Features are built but thrown away
 Development team is reactive with tasks
 Backlog contains a detailed feature level list of tasks
 Backlog is technical with no user-focused stories.
Kevin identified only a few steps to build an impact map. These include defining a goal and holding an
impact mapping session. There are a few sub-steps but the end result is a map that has a single,
measureable goal with actors and impacts and deliverables. These serve to identify why, who, how and
what and also assists in planning the work. As Kevin noted, “the process itself is a powerful facilitation
tool…” And it is!
Once all impact maps have been created then prioritization could be achieved as Kevin indicated by
asking the following questions:
 Which Impact has the greatest effect achieving the goal?
o Of that Impact which Deliverable would achieve the Impact the fastest?
o Work that Deliverable and when completed -> Stop -> Consider if the Goal has been
achieved
o If the Goal has not been achieved then identify the next Impact and repeat the process.
If the Goal has been met then you have completed your Goal. Move to the next Goal.
2
For additional information regarding SAFe Stories please refer to http://scaledagileframework.com/stories/.

9
References
Albrecht, Kevin. “Escaping Solution-First Development through Impact Mapping” retrieved from
https://medium.com/kevin-on-code/escaping-solution-first-development-through-impact-
mapping-663b2c6d0ea8#.jj40mvtty
BABOK v3 retrieved from http://www.iiba.org/BABOK-Guide.aspx
Courtney. User stories: a beginner’s guide to acceptance criteria retrieved from
http://www.boost.co.nz/blog/2010/09/acceptance-criteria/
Epic Abstract retrieved from http://www.scaledagileframework.com/epics/
Functional Decomposition p. 283 IIBA’s A Guide to the Business Analysis Body of Knowledge (BABOK®),
version 3.0
Stories Abstract retrieved from http://scaledagileframework.com/stories/

Identify Added Business Value Paper 3-20-2016

More Related Content

Viewers also liked

Similar to Identify Added Business Value Paper 3-20-2016

More from Shirley Sartin, PBA, BSAC, CBAP, PMP, CSM

Identify Added Business Value Paper 3-20-2016