Agile Roles For User Stories - With.halo.2015-10-07

Agile – Roles and User Stories
Jim Porter, Roman Osatinski – Members, Agile COC for AT&T Account
jcporter@us.ibm.com, rosatin@us.ibm.com,
© 2011 AT&T Intellectual Property. All rights reserved. AT&T, the AT&T logo and all other AT&T
marks contained herein are trademarks of AT&T Intellectual Property and/or AT&T affiliated
1
companies. All other marks contained herein are the property of their respective owners.
Agenda
Who are the roles involved
A side note on terms and tooling
When do they get involved
What do they do
Examples of Epics and Stories
Back up materials on writing good epics and stories
Who is involved in writing stories
The Product Owner

The Requirements Integration Lead (formerly, T1)
The Requirements Engineer (formerly, T2)
The Application Engineer (formerly, T3)
And…
The Test Architect / Planner

The E2E SE and/or Agile Scrum-of-Scrums Master
The Solution Definition author
Business SMEs, stakeholders, and other interested parties
Agenda
What do they do
Back up materials
Features, Portfolios, and Tools
 In generic Agile, we have Epics (big stories) and Stories (smaller stories)
 On the AT&T account, we have this…

 Projects (PIDs) have impacts on many application teams
 Application teams are impacted by many projects
 We need to be able to manage the work from both views.
 To manage this, in Rally, we now have Portfolio and Delivery areas – see next
slide.
 In the Portfolio area, what we used to call “Business-level epics” are now
called “Features”.
 A Feature is a business function that (usually) impacts several applications.
 A Feature will break down into multiple Application-level Epics, one per
application team
 In the Delivery area, an Application-level Epic is a child of a Feature, and
covers the impact of the Feature on a single application.
 The Application-level Epics will break down into User Stories small enough to
fit into a sprint.
 When we move to RTC (TDP-LM), a similar structure will be in place.
What does Mapping look
PMATT
like? WHAT are you trying to deliver?
Theme
Group work into (New Product Offer)
Agile Releases Sub-Projects in PMATT OR
WHAT & WHY &HOW Initiative Initiative Value Stream Portfolio Structure
Portfolio
are you going to deliver (Ph2 Automate (Ph1 New offer - WHAT & WHY are you trying to
the Business Value? (just Billing) manual billing) deliver this work (product
enough “how” for delivery specific or business value driven)
teams to write US”
Feature Feature
(CTN eligible) (offer types)
Portfolio
User Stories Epic Epic Epic Epic Epic Delivery

(spans multiple iterations) Team based Team based Team based Team based Team based
User Stories
(single iteration)
Story Story Story Story Story Delivery Team
Tasks
1 day or less
Task Task Task Task Task Task Task Task
Task Task Task Task Task Task Task Task Task Task
© 2015 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual
AT&T Proprietary
© Property.
2011 AT&T (Internal
Intellectual Use Only).
Property. Notreserved.
All rights for use orAT&T,
disclosure outside
the AT&T logothe
andAT&T companies
all other AT&T except under written
agreement.
New Rally Hierarchy – on HALO now, others soon
Element How implemented in Rally Owner
HALO Feature (Rally Initiative) – Initiative; child of Theme whose Entered and owned by
Decomposition of an initiative into separate name starts with “Feature” business; refined by Guide
Features, each of which can be delivered in Group
an Agile release
Minimum Marketable Feature (Rally Feature whose name starts with Identified by Guide Group;
Feature) – the smallest cohesive slice of “MMF”; child of Initiative owned by business
functionality that makes up the Feature.
Ideally sized for 1-2 iterations.
Epic – Decomposition of an MMF into the User Story whose name starts Entered and owned by App SE;
impacts of that Feature on a single Agile with “Epic”; child of MMF refined by scrum team
team
User Story – Decomposition of an Epic into User Story whose name does Entered and owned by App SE;
pieces that can be delivered in a single not start with “Epic”; child of refined by scrum team
iteration Epic
– Everything above Epic is business focused. Epics and User stories are implementation focused. But all of them are
focused on the what, not the how, and are a vertical slice of functionality (NOT divvied up by architectural
component).
– This is a modification of the standard Portfolio Management structure advocated by the Agile COE to include MMF.
7 © 2015 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual
© Property.
2011 AT&T Intellectual Property. All rights reserved. AT&T, the AT&T logo and all other AT&T
AT&T Proprietary (Internal

Agenda
What do they do
Back up materials
When stories get written
Software Capitalization
Starts
TCP1 TCP2
Software Capitalization
Ends
Create Create Business
Create IWR Phase 1 Phase 2 Case Approval
PMT PMT Evidence
Vision and Funding
Solution
Epic Level Project
Definition for
User Stories
Estimation
Plan Agile Release Planning and Management
Epic
User Stories
Iteration and Deployment Management
Epic
User Stories
Solution SDG Closure
Definition for
Project Arch
PO, BPE, Int. Lead, PO, Int. Lead, Req Req Eng, App
etc, create initial Eng, Test Arch, Arch, Test Arch,
Features SOSM, etc, create SOSM, create
(business-level app-level Epics app-level stories
Epics)
9 marks contained herein are trademarks of AT&T Intellectual Property and/or AT&T affiliated
During Vision and Funding (before sprinting)
Product Owner reviewsVEpics

with Requirement engineers
Scrum Of Scrum / ETE
SE collaborate with
authors on quality and
traceability
Requirement Engineers Create

Application Epics/User Stories
from Epics Above
Scrum Teams self organize and

break down user stories further to
smaller user stories deliverable in
sprints
HALO Process Flow
Create Features & Create Epics & USs
MMFs; refine Weekly Semi-Weekly from MMFs; Four Weeks
MMFs to meet Once Every 8Weeks Refine USs to
Definition of meet Definition of
Ready Ready
Refine Big Room Backlog Iteration Planning
MMFs Planning Grooming & Implementation
Epics & User
HALO Story Backlog
Feature
Definition ● US 1
MMF Backlog Ready User
Product ● - Not Ready
Ready Prioritized ● US 2 Stories Sized
Idea ● - Ready MMFs
● MMF1 MMFs Sized ● US 3 for Iteration
for Release
● MMF1 ● MMF2 ● US 4 ● US 2
● MMF4 ● MMF7 ● US 5 ● US 4
● MMF2
● MMF7 ● MMF1 ● US 6 ● US 7
● MMF3
● MMF8 ● MMF4 ● US 7 ● US 8
● MMF4
MMFs, Epics, and ● US 8
● MMF5
User Stories flow
● MMF6 ● US 9 Demo
through this process
● MMF7 ● US 10 completed
independent of
● MMF8 ● US 12 MMFs across
other items in the
● US 13 all Apps
same or different ● MMF9
PIDs. Guide ● US 14
Group + ● US 15
PODs + PODs & ● US 16
Delivery Delivery
Guide Group Teams Teams Delivery Team
11 © 2015 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual
© Property.
2011 AT&T Intellectual Property. All rights reserved. AT&T, the AT&T logo and all other AT&T
Agenda
What do they do
Product Owner/Delegate Responsibilities
1 Vision and Funding

Interface with customer
2 Release Planning and Management

Interface with customer
If the Product Owner is unable to provide
Own and prioritize the backlog
full participation with the Scrum Team, a
Communicate vision, timeline, Delegate is identified to partner with the
goals Scrum Team.
Create and maintain User Stories
Iteration and Deployment Management
3 Interface with customer
Own and prioritize the backlog
Communicate vision, timeline, goals
Close collaboration with delivery team
Create and maintain User Stories
Accept completed User Stories
Closure
4 Interface with
customer
13 companies. All other marks contained herein are the property of their respective owners.
Requirements Integration Lead – Recommended
Role
The Integration Lead assembles the initial set of Features /

Epics from the PO and other business stakeholders.
These Features / Epics become the initial backlog, from which

the Solution Definition and Business Scenarios are derived.
The Integration Lead ensures the Features / Epics are in good

form, and have good content, do not conflict with each other,
are concise, etc.,
This effort replaces the Business Requirements Spec from

Waterfall.
(SE&A Team has ETE SE’s capable of doing this)

During Vision and Funding (before sprinting)
With integration lead
V
Product Owner reviews Epics
with Requirement engineers
Scrum Of Scrum / ETE Integration lead/SOS/ETE SE

SE collaborate with coordinates the Scrum Teams
authors on quality and
traceability
Requirement Engineers Create

Application Epics/User Stories
from Epics Above
Scrum Teams self organize and

break down user stories further to
smaller user stories deliverable in
sprints
Requirements Engineer
The Requirements Engineer represents (one of) the impacted

applications on a given project.
The RE guides the Integration Lead in breaking down the

Features / Business-level epics to application-level epics (and to
application-level user stories, if possible)
Focus is kept on the USER, not the system. What does the
USER expect of the application.
Likewise, the acceptance criteria focus on how the USER will

know the story is complete.
Application Architect
The Application Architect provides the technical insight and
deep design knowledge of an impacted application. If an
application does not have a Requirements Engineer, the App
Arch will serve that function also.
The App Arch guides the Requirements Engineer in breaking

down the application-level epics into user stories small enough
for execution during a sprint.
Focus still is kept on the USER, not the system. What does the
USER expect of the application, from these smaller user stories.
By this point, we recognize that the “user” may be another

system. Still – we focus on the user, not on THIS application.
We are writing user stories, not system requirements.
The App Arch also leads the application team in sizing the low-
level stories.
Other roles…
The Test Architect / Planner – ensures all stories (from Epics

to low-level user stories) have Acceptance Criteria that are
feasibly testable.
The E2E SE and/or Agile Scrum-of-Scrums Master –

watches for form and content issues, consistency between
stories, dependencies, gaps, and traceability as the stories
evolve.
The Solution Definition author (and/or Business Scenario

author) – Checks the initial epics for alignment with the solution
definition and business scenarios. Reviews the emerging lower-
level epics and stories for continued alignment.
Business SMEs, stakeholders, and other interested parties –

ensures the business-level epics are complete and accurate.
Provides input on priorities. As stories evolve, provide input on
details and design elements.
A Feature or Business-level Epic
Identifies the desired business function

Written from the USER view (and identifies the user type)
Need not reference specific applications (that’s solutions!)
These need not be sized, except for very gross estimates
Always includes acceptance criteria
Example:
As an Ethernet client, I want to upgrade my existing service to

support 100Gb speeds to a specific street address, so that I can
replace my slower speed and gain improved response time.
Acceptance criteria
I am able to identify the address where I currently have service.
I am able to request the upgraded speed
I am able to see the additional one-time and monthly charges
I am able to track the status of my order once it is placed.
An Application-level Epic
Applies the desired function of a business Epic to an impacted

application
STILL written from the USER view (and identifies the user type)
These can be sized, but for high-level planning purposes only
Sizing helps to start the estimation process,
Sizing identifies epics that are “large” and need
decomposition into smaller stories.
Application technical team must be involved in sizing.
Always includes acceptance criteria.
Example on the next slide.
An Application-level Epic - sample
The business epic:

As an Ethernet client, I want to upgrade my existing service
to support 100Gb speeds to a specific street address, so
that I can replace my slower speed and gain improved
response time.
Application Epic:
As an Ethernet client ordering upgraded service through
<app name>, I want to select an existing address that has
lower-grade service, so that its information and
characteristics are identified as the target for the upgrade
within the order I am placing.
An Application-level User story
 Decomposes application Epics into User Stories small enough to

complete in a single sprint.
 Provides a useful function (however small)
 Is NOT just “design”, or “code” or “test”, spread across multiple sprints.
 STILL written from the USER view (and identifies the user type)
 These are sized for detailed planning purposes.
 As they approach moving into a sprint, the App Arch and others will
provide design details for the individual stories.
 HLDs are NOT required – especially one document that covers the
entire set of stories for the project.
 Instead, create just enough design for the needs of the team to
understand the story. Do this before the sprint, or just at the start.
 Do NOT “One person does all the HLD” be a bottleneck
 AIDs are still required, and should be worked in advance of the
sprint.
 Always includes acceptance criteria.
 Example on the next slide.

An Application-level User story - sample
Application Epic:
As an Ethernet client ordering upgraded service through
<app name>, I want to select an existing address that has
lower-grade service, so that its information and
characteristics are identified as the target for the upgrade
within the order I am placing.
Application Stories
 As an Ethernet client, I want to see my existing addresses
displayed on the <panel name>, with the option to select one or
more for upgrade, so that it can be made part of the order.
 As an Ethernet client, after I have selected addresses to upgrade, I
want to be notified whether there will be additional build-out
installation charges, so that I can plan my budget accordingly.
 As <app name processing an end user query>, I want to submit
addresses to the <downstream app> for eligibility check, so I can
provide information on charges to the Ethernet client.
Business Requirements vs Features / Epics
BRs in Waterfall become Features / Epics in Agile
Business Requirement Epic
When there are multiple VDNA sites As a network operator supporting Edgemarc
devices,
with Edgemarcs on a client managed
router campus, we want correlation of
I want alarms sent from failing Edgemarc to be
Edgemarc alarms. For example, if more correlated into a single, if multiple Edgemarcs on
than one EM on a campus goes down a client's campus go down together,
alarms would be correlated onto one
ticket with event messages for each So that I can work the problem with a single
Edgemarc on the campus that has consolidated ticket, instead of being flooded
gone down with redundant alarms about the campus.
Requirements vs Stories – 1 of 3
System Requirements become Stories
System Requirement User Story
When NC3 sees that a AVPN Circuit ID As NC3, the system managing Edgemarc
configuration,
has been sent from GIOM, NC3 will
create a Generic Router to associate to
I want to create a generic router for a given
the EdgeMarc. AVPN Ckt ID, and associate that router to an
Edgemarc device
So that a hierarchical spanning tree can be built

from the parent/child relationship thus stored,
for use in alarm correlation.
Requirements vs Stories – 2 of 3
A new interface will be created As GFP-CPE, charged with capturing alarms and
turning them into tickets,
between the GFP-CPE OVO and the
ACS.
I want to correlate alarms sent from failing
The interface will be used to forward Edgemarcs, based on the hierarchical spanning
the alarm message associated with a tree,
HST to ACS Server
So that I pass onto AOTS one ticket per campus
when there are multiple failures.
Note: This should be implemented as a new

component. Not ALL alarms will be correlated –
only when multiple alarms from the same
campus are seen.
Requirements vs Stories - 3 of 3
GCP-GRDB must use the parent-child As GCP-GRDB, responsible for creating the ANT
file describing equipment configuration,
relationship created in NC3 and send
this relationship down to the ANT
I want to capture the Edgemarc parent/child
feed. relationship with the generic router of its
campus, from NC3's stored configuration of the
Edgemarc devices,
So that I can provide that relationship in the

ANT file, feeding the hierarchical spanning tree
used for alarm correlation of the Edgemarc
devices.
Backup material – good stories
What makes a good story
Breaking epics into useful user stories
User Stories
From Business-level EPICS down to application-level User Stories, they follow the same format.
A User Story takes the form of:

As a <Role>, I want to <Goal> so I can <Business value>.
Examples
As a DBA at Wal*Mart, I want to be able to reduce
DBA at storage consumption so that I manage fewer
Wal*Mart storage devices.
Note: DBA at Wal*Mart is administering DB2
As an administrator, I want to prove that only

Administrator approved clients are allowed to use specific services
so that I can control data security/costs/etc.
User Stories
Making a Great User Story
Independent – a user story in an iteration should not have to wait for another user
story to be completed before it can be worked
Negotiable – small stories are straight forward and well defined, large stories have
more flexibility to change
Valuable – each story adds some piece of functionality
Estimatable – stories contain enough information to gauge effort
Small – stories should be accepted iteratively, they should be broken down as small as
possible to drive iterative delivery
Testable – acceptance criteria must be clearly defined
What should be a story
A User Story is a description of a desired function that will support a

business need. It can include…
New / changed web panel, report, web service, data repository,

algorithm, etc… anything that gives function to the user.
New / changed operations support procedures, tools, documents
New / changed documentation, training materials, support data
New / changed environments – hardware, system software, firewalls,

configuration data, at any level from development to production.
Prep work for audits, legal reviews, compliance checks, etc.
ANY work the team needs to do to support the business need.

What goes into a good story
Story statement
Conversation
Acceptance criteria
Assumptions
Estimating
elements
Story statement
As <a user type> I want to <Goal> so that <Business value>

 As a user of lotus connection wiki I want to be able to export top level wiki pages and
their children to create a PDF document.
 Why? What is the purpose of this action?
 As a user of lotus connection wiki I want to be able to export top level wiki pages and
their children to create a PDF document so that I can hand the document off line to
customers
 Is the user role clear? Is the purpose clear?
 As an architect using the lotus connection wiki to create product documentation I want
to be able to export top level wiki pages and their children to create a PDF document so
that I can pass the documentation (incl. best practices) to customers outside of IBM.
 Good so far. Now, work with your users and technical team to refine the details and
build the acceptance criteria.
 For more details, see "Crafting User Stories that Work"
Conversation – or the design notes
The conversation – or conversations, plural – is how you fill in

the details. As the story moves up the backlog and nears the
time when it will enter a sprint, the technical team and PO must
get the details for the story in place, so it can be implemented.
The conversations will include:

 Users and other stakeholders
 Subject matter experts
 Business consultants
 Operations and support staff
 Technical team input, from architects, designers, testers…
 The conversations cover:

 Design details – suggested layouts, approaches, techniques
 Use cases, including alternate paths and error handling
 Non-functional needs – performance, security, accessibility
 Testing expectations.
Acceptance criteria
The acceptance criteria identify how the PO will confirm the

story has been implemented correctly
The tests should be binary – success or not.
Wording should identify specific quantities or thresholds, and

NOT use qualitative words like “faster” or “better”
Tests are from the user’s perspective, not “insider” checks or

unit tests. What does the user see? How does the user know it
succeeded?
These tests are IN ADDITION TO the “done done done” criteria

the team establishes for all stories.
Assumptions (and dependencies)
What do you believe is true in this story’s context?
How do those assumptions influence your sizing or design?
What happens if those assumptions are false?
Write them down. Better yet, if possible – create an

“Assumption” record in your backlog tool, and link it to this
story, and review those assumptions periodically (such as
during the backlog grooming for each sprint).
Estimating elements
What will help the technical team arrive at a good estimate?
Find ways to quantify the impact of the story. For example…
Number of panels that will be new or updated
Number of reports, interfaces, data tables, user types, etc…
Length of business processes involved in testing…
Write them down as part of the story.
Epics break down into Stories
Epics are either…

 Business-level requirements that need refinement before implementation
 BIG stories – too big to fit into a singe sprint.
 Break down Epics using one of several techniques…

 By use case: Basics in one or more stories, then alternatives and error
handling in other stories.
 By user group: Basic user, advanced user, special case user
 By data grouping – basic, additional chunks, final set.
 By functional area: data, then panel, then business logic (downside – doesn’t
really deliver to the user until they are ALL done).
 By process: one step at a time…
 Identify Epics early on, so that the team has time to break them down
properly.
 Generally, don’t spend much time sizing Epics, other than to know they
are “large enough”. Spend estimation time on the stories.
Epics break down – by Use case
Epic: As a user of a travel site, I want to cancel my

reservations.
Story: As a user that has only booked hotel, I want to cancel

my reservations up to the midnight before arrival, so that I’m
not charged.
Story: As a user that has booked a full package (including air), I

want to cancel all arrangements, and pay any cancellation fees,
so that I’m charged the least for my trip.
Story: As a user who purchased travel insurance, I want to

cancel all arrangements, with no time constraints, so that I am
charged no fees.
Epics break down – by User group
Epic: As a user of the work management application, I

need appropriate access to its functions, so that I can
complete my assigned tasks.
Story: As a reviewer, I need read-only access to summary

reports, so that I can observe progress on the work flows.
Story: As a task worker, I need update access to my tasks, so

that I may work on them and update their status.
Story: As an administrator, I need full access to all work lists,

so that I may adjust work assignments to balance loads.
Epics break down – by Data grouping
Epics: As a customer, I want to supply all information for

a purchase, so that my order can be processed.
Story: As a customer making a purchase, I want to supply my

shipping information, so that my order can be sent to me
Story: As a customer making a purchase, I want to identify the

items I wish to purchase, and in what quantity, so that my
shopping cart is correct.
Story: As a customer making a purchase, I want to provide

billing information, including coupons and discounts, so that I
am charged correctly for my purchase.
 This story might be broken down further, into one that just took the
basic billing info, and one that dealt with coupons and discounts.
INVEST vs SMARTT
Waterfall projects use Business and System Requirements
Presentations on BRs and SRs introduced the acronym SMARTT,

to describe a “good” requirement. Meanwhile, INVEST is used
for Stories.
Specific Independent
Measurable Negotiable
Achievable Valuable
Repeatable Estimable
Testable Sized appropriately
Traceable Testable
Can we make use of both lists? Does SMARTT apply to User

Stories?
 The presentation was made by Kim Iungerman in December 2013, and is available
in the SEA Team Room.
INVEST vs SMARTT - Specific
The requirement should be specific.
It should identify a single item, and be independent from other

requirements. It should completely describe the need, in
quantitative and business terms.
YES, use this for User Stories.
A user story should cover a single item. The “I” in INVEST is for
“Independent”. The conversations in a story cover all the
details. And stories should use quantitative terms, not
qualitative.
INVEST vs SMARTT - Measurable
The requirement should be measurable.
It should identify specific values, measures, logic, tests, etc.,

that are used to verify the requirement is met.
These quantitative details feed into the acceptance criteria used

in Testing
INVEST vs SMARTT – Achievable
The requirement should be achievable.
It should be possible within the budget, legal, and will

contribute to the business value of the solution (and have a
positive return-on-investment).
User Stories should be Sized appropriately and Valuable.
INVEST vs SMARTT – Repeatable
The requirement should be repeatable.
It should be described in precise terms, that removes all

ambiguity. All conditions and cases, positive and negative,
should be identified, so that all readers are clear on expected
results.
YES, use this for User Stories. BUT, not right away.
User Stories should be Negotiable. This means that the story

is not, at first, so detailed as to constrain the technical team
and prohibit creative solutions.
However, User Stories are also Testable, and to be tested,

they must be clarified and specific. This detail grows as the
conversations about the story take place, and the details are
accumulated and agreed upon by all stakeholders.
INVEST vs SMARTT – Traceable
The requirement should be traceable.
A traceability tree should grow

 Customer wants and needs
 Business requirements
 System requirements
 Design elements
 Test plans and test cases
 Delivered components
Not directly part of INVEST, but the stories should grow from
Stakeholder needs – they must be Valuable. To ensure this,
and to ensure nothing sneaks in, trace from
 Vision statement
 Feature
 Epic
 User story and acceptance criteria
 Completed components
INVEST vs SMARTT – Testable
The requirement should be testable.
It should be SMARTT, and have acceptance criteria. From the

information in the requirement, test cases can be created that
will prove the requirement was met.
YES, use this for User Stories. (Is this even a question?)
User Stories must be Testable.
Questions????
49 © 2011 AT&T Intellectual Property. All rights reserved. AT&T, the AT&T logo and all other AT&T

Agile Roles For User Stories - With.halo.2015-10-07

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Roles For User Stories - With.halo.2015-10-07

Uploaded by

Copyright:

Available Formats

Agile – Roles and User Stories

Who are the roles involved

A side note on terms and tooling

When do they get involved

Examples of Epics and Stories

Back up materials on writing good epics and stories

The Product Owner

The Test Architect / Planner

Who are the roles involved

A side note on terms and tooling

When do they get involved

Examples of Epics and Stories

 On the AT&T account, we have this…

 When we move to RTC (TDP-LM), a similar structure will be in place.

User Stories Epic Epic Epic Epic Epic Delivery

Task Task Task Task Task Task Task Task

Task Task Task Task Task Task Task Task

AT&T Proprietary (Internal

Who are the roles involved

A side note on terms and tooling

When do they get involved

Examples of Epics and Stories

Vision and Funding

Product Owner reviewsVEpics

Requirement Engineers Create

Scrum Teams self organize and

Who are the roles involved

When do they get involved

Examples of Epics and Stories

1 Vision and Funding

2 Release Planning and Management

The Integration Lead assembles the initial set of Features /

These Features / Epics become the initial backlog, from which

The Integration Lead ensures the Features / Epics are in good

This effort replaces the Business Requirements Spec from

(SE&A Team has ETE SE’s capable of doing this)

Scrum Of Scrum / ETE Integration lead/SOS/ETE SE

Requirement Engineers Create

Scrum Teams self organize and

The Requirements Engineer represents (one of) the impacted

The RE guides the Integration Lead in breaking down the

Likewise, the acceptance criteria focus on how the USER will

The App Arch guides the Requirements Engineer in breaking

By this point, we recognize that the “user” may be another

The Test Architect / Planner – ensures all stories (from Epics

The E2E SE and/or Agile Scrum-of-Scrums Master –

The Solution Definition author (and/or Business Scenario

Business SMEs, stakeholders, and other interested parties –

Identifies the desired business function

As an Ethernet client, I want to upgrade my existing service to

Applies the desired function of a business Epic to an impacted

Always includes acceptance criteria.

Example on the next slide.

The business epic:

 Decomposes application Epics into User Stories small enough to

 Always includes acceptance criteria.

 Example on the next slide.

Business Requirement Epic

System Requirement User Story

So that a hierarchical spanning tree can be built

System Requirement User Story

Note: This should be implemented as a new

System Requirement User Story