The core concepts of a Release Based development lifecycle for agile projects. The lifecycle starts with the Product Roadmap, showing what Capabilities are provided in what order, in what Epic, to deliver the needed business value, on the needed dates, for the needed cost, with the needed Features. The Features and Stories that implement these Capabilities are traceable to the Product Roadmap to show Physical Percent Complete from starting at the Story flowing to an Epic to deliver a needed Capability.

1. AGILE LIFECYCLE
PRODUCT ROADMAP, RELEASE PLAN, ROLES AND
RESPONSIBILITIES, EPICS, FEATURES, STORIES, AND TASKS
The core concepts of a Release Based development lifecycle for agile projects.
The lifecycle starts with the Product Roadmap, showing what Capabilities are provided in what order, in what Epic,
to deliver the needed business value, on the needed dates, for the needed cost, with the needed Features.
The Features and Stories that implement these Capabilities are traceable to the Product Roadmap to show Physical
Percent Complete from starting at the Story flowing to an Epic to deliver a needed Capability.

2. Contents
§ Framing Assumptions of Scrum
§ Roles and Responsibilities of the Team Members
§ Writing User Stories
§ Story Mapping
§ Estimating Work in Scrum Development
§ Measuring Physical Percent Complete
2/110
“Be stubborn on the vision, but flexible on the details” — Jeff Bezos

3. 1. What Does DONE Look
Like?
2. How Do We Get to DONE?
3. Is There Enough Time,
Resources, And Money To
Get to DONE?
4. What Impediments Will Be
Encountered Along The
Way to DONE?
5. What Are The Units Of
Measure For Assessing
Progress Toward Done for
each Deliverable?
Let’s start with the Immutable Principles of
Project Success with Five Easy Questions …
QUESTIONS
3/110

4. Incremental and Iterative Development is About Short
Intervals of Work (Sprints) Producing Usable Software
§ Waterfall means knowing all the requirements upfront
and baselining them for the duration of the project.
§ Agile (Scrum) means implementing the needed
Capabilities delivered in an Epic for the project
Feature‒by‒Feature for the next Release containing
those Capabilities.
4/110

5. THE FRAMING ASSUMPTIONS OF
SCRUM SOFTWARE
DEVELOPMENT
Scrum is a Process Framework that is a subset of Agile, that is
divided into the three categories ‒ Roles, Artifacts, and Time Boxes.
5/110

6. Scrum is a disciplined software development process that
produces business value to the customer every Sprint, with
assessment of progress to plan (Product Backlog), using physical
percent complete of working software on a daily basis.
2 week
6/110

7. From Epics (Delivered in a Release) to Features, to Stories,
to Tasks – decomposing Requirements into Releases†
7/110
Epic
Feature
A collection of Features that enables the Business to
accomplish a mission and fulfill a vision.
A Business Capability describes what the business does,
not how it does it.
Story
The functionality needed to implement an Capability,
typically 2 to 4 weeks in duration. Features are contained
within Release. Ideally Features contained within a single
team. Features are what the Product Owner cares about.
A small increment of delivered Value, typically less than a
week’s work. Use Stories contained within the Sprint.
These are outcomes the Development Teams cares about.
† “Agile Requirements Decomposition ‒ Epic to User Story and Story Mapping”

8. Elaboration and Decomposition is a Critical
Success Factor for Scrum Development†
8/110
High Level Medium
Level
Low Level Just in Time Details
Epic
Feature
Feature
Story
Story
Story
Business Rules
Acceptance Tests
UI Mockups
Activities
Tasks
† “Agile Requirements Decomposition ‒ Epic to User Story and Story Mapping,” Rick Austin, Duluth Georgia, Enterprise Agile Coach
Epic
Provides the ability to
accomplish a business
goal
Feature
An service
needed to deliver
the Epic
Story
A conversation
about a desired
functionality

9. Example of Elaboration and
Decomposition†
9/110
Business Capabilities
Delivered in Epics
Features
Delivered in Releases
Stories
Delivered in Sprints
Business Capabilities
spaced across multiple
releases
Features are delivered in a
single Release
Stories are delivered in a
single Sprint
Capture New User
Profile to start the
enrollment
Allow New User to
Create Profile
Allow New User to
Maintain Profile
As a New User I
want to enter my
Profile Information
to start an
application
I want to control my
privacy setting in my
profile
† “Agile Requirements Decomposition ‒ Epic to User Story and Story Mapping

10. Identifying Epics and Features for NES†
§ Decompose the Business needs into Business
Capabilities that deliver High‒Level behaviors to
accomplish the Vision and Mission.
§ Epics are the delivery vehicle to accomplish the
Mission and Vision.
§ Features are a specific services that fulfills a
stakeholder needs.
§ Features enable a Lean User Experience (LUX) which
implements functionality in minimal viable
increments that determine success by measuring
results against proposed benefits.
10/110† “Agile Requirements Decomposition ‒ Epic to User Story and Story Mapping

11. 10 Steps in the Agile Lifecycle
11/110
Closed Loop Feedback Control
for Agile at Scale
❶ Business
Strategy
❷ Product
Roadmap
❸ Release
Plan
❺ Groom
Backlog
❻ Sprint Backlog
Plan
❹ Features
in PBL
❼ Story and Task
Estimates During Sprint
❽ Remaining Estimate (REM
EST) Updates Produce
Physical Percent Complete
❿ Update Physical
Percent
Complete of
Project
❾ Update Feature with
Physical Percent
Complete, from
Story progress
Plan
Do
Check
Act
Continuous feedback at each step with
corrective actions for Root Cause of
Performance Variances

12. Starting with the Product Roadmap as the strategy to produce the
needed Business Capabilities from the project.
The Product Roadmap is a high-level visual summary showing the
increasing maturity of the project deliverables, over time, connected
to the Business Value from those deliverables.
12/110

13. 13/110
Without a Plan, you
may arrive at the
wrong destination
without knowing soon
enough to change
your course
The Product Roadmap and
Release Plan provide the
direction to our destination.
Features and their measures
of Physical Percent Complete
provide assessment of
progress to that plan

14. Roadmaps ‒ from Strategies to Tactics
14/110
Story
Feature
Epic
Theme
Why are we doing
this project?
What are the
measurable outcomes of
this work?
What product attributes
enable Capabilities?
What Short requests are
needed from the
perspective of an end user
to accomplish something of
value?

15. A Roadmap shows the intent of the Project
We want to start here follow this route, to arrive there
§ Product Roadmaps are aligned with
– Product Strategy
– Releases
– Features
§ Releases are containers for work
§ The Product Roadmap describes how to get from
strategy to tactics of developing the Product
Product Roadmaps allow Product Owners to communicate Direction
and Progress to the Stakeholders and the Scrum Team members.
15/110

16. Contents of the Product Roadmap (1)
§ Theme
– A high-level objective for the product
– Built on a related set of features or stories
– A theme as a broad strategic goal for your product
– Ensure the product complies with federal regulations
such as HIPAA
§ Epic
– A group of Features or Stories with a common strategic
aim.
– HIPPA Compliance
16/110

17. Contents of the Product Roadmap (2)
§ Feature
– Are a product’s traits or attributes.
– Include the application’s functionalities, capabilities, and
even its visual characteristics.
– Are any key trait of the product with value or benefit
delivers to the user.
§ Story
– A self-contained unit of development work designed to
accomplish a specific goal of the product.
17/110

18. Epics, Features, Stories, Tasks
§ Stories in agile are similar to stories in film or literature,
when stories are arranged in the right order, they convey
what is happening to the characters.
§ A story is a simple narrative.
§ A series of related and interdependent stories makes up
an Feature that enables a Capability, delivered in an Epic.
§ The same is true for software developemnt
– Completion of related stories that make up a Feature leads to
the completion of a Capability to accomplish a business goal.
– The stories tell the narrative arc of the work completed.
– Epics collect the high‒level view of the unifying objective.
18/110

19. Product Backlog Contains Features
and Stories Needed to Implement
the Desired Business Capabilities
Contained in the Product Roadmap
19/110

20. Why Do We Need A Product Roadmap?
§ The roadmap communicates the big picture of what
Done looks like to the organization.
§ It tells us what initiatives create customer value?
§ It stated what order is the Value needed to meet the
business goals.
20/110
The Product Owner is responsible for the contents,
maintenance, and prioritization of the Product
Roadmap

21. Product Roadmap in Jira’s Aha!
21/110

22. The Release Plan
Is an Event, NOT a Meeting
§ Conveys expectations about what is likely to be
developed and in what timeframe.
§ Helps the Product Owner and whole Team to
determine how much MUST be developed, and how
long that will take before they have a releasable
product.
§ Serves as a guidepost toward the project team’s
measure of progress.
22/110

23. A Notional Release Plan in Confluence (Jira)
23/110

24. Epic, Feature, Story
24/110
Epic
§ Large initiatives delivering Business Capabilities
to accomplish a business function.
§ Comprised of a collection of Features.
Features
§ Features the Product owner needs to accomplish
a business function
§ Provides value to Users
§ Realized by some number of Stories
Stories
§ Represents a User Need
§ A level at which Planning Items definitized
§ Basis of a conversation between the Product
Owner and the Development Team

25. Epic Versus Feature
§ A Epic
– Provides measurable business value to an external
Stakeholder.
– Something a software enables a user to do.
§ A Feature
– Normally visible to the user through the user interface.
– Are collected together to provide Business Capabilities to
achieve business goals of the system.
25/110

26. What is a Feature
§ A feature is a distinct element of functionality which
provides measurable capabilities to the business.
§ It generally takes several sprints to deliver a Feature.
§ A User Story is a part of the Feature.
§ By splitting a Feature in Stories, the User can quickly
provide early feedback to the developers on its
effectiveness in providing business value.
§ A feature is something that is in a product—a spell-
checker is in a word processor, is a Feature.
§ The benefit of the Features is something a user
gets from of a product.
§ By using a word processor, the user gets documents free
from spelling errors. The spell-checker is the feature,
mistake-free documents is the benefit.
26/110

27. What is a User Story
§ Detail can be added to the User Story by …
– Splitting a Story into multiple, smaller Stories
– By adding conditions of satisfaction
§ When a large story is split into smaller user stories,
detail has been added.
§ The conditions of satisfaction are high-level
acceptance test that will be true after the User story
is complete.
As a <type of user>, I want <some goal> so that
<some reason>
27/110

28. A User Story Example with added Detail
§ Detail could be added to that User Story by including the
following conditions of satisfaction:
– Make sure it works with major retail holidays: Christmas, Easter,
President’s Day, Mother’s Day, Father’s Day, Labor Day, New
Year’s Day.
– Support holidays that span two calendar years (none span
three).
– Holiday seasons can be set from one holiday to the next (such
as Thanksgiving to Christmas).
– Holiday seasons can be set to be a number of days prior to the
holiday.
As a vice president of marketing, I want to select a holiday season to be used
when reviewing the performance of past advertising campaigns so that I can
identify profitable ones.
28/110

29. Successful Scrum Processes
Success Factor Evidence Success Factor Being Applied
Delivery Strategy
§ Regular delivery business rhythm
§ Plan the delivery of important capabilities first
Agile Techniques § Well defined standards of production
Team Capability
§ Competence and expertise
§ Managers knowledgeable of agile
§ Adaptive management style
Project Management
§ Agile requirements analysis and project management
§ Process tracking
§ Face-to-face communication
§ Regular working schedule
Team Environment
§ Colocation of team members
§ Coherent, self-organized teams
§ Small teams working on weekly cycle of deliverables
§ No multiple independent teams, close coordination of work
Customer Involvement
§ Good customer relationships
§ Progress visible to customer on fine grained boundaries
29/110

30. 30/110

31. ROLES AND RESPONSIBILITIES OF
THE SCRUM TEAM MEMBERS
A team is a small group of qualified individuals who hold each other
mutually accountable for a shared outcome ‒ Jon Katzenbach
31/110

32. Structure of the Successful Scrum Team
32/110
Success stars with the Business and Development teams interconnected on a
daily basis, with Product Owner identifying What to build, with the Development
Team discovering How to build, test, and deploy it, and with the Operations
training and supporting the business result ‒ All facilitated by the Scrum Master,
All holding each other mutually accountable for a shared outcome.

33. Summary of the Roles and Responsibilities of a
Successful Scrum Team
33/110
The Development Team
are the designers and
problem-solvers. Task
allocation and distribution
is determined by the
Development Team
The Product Owner
ensures the Development
Team is working toward
the appropriate targets
from a business
perspective.
The Scrum Master is a
combination of coach,
facilitator, and remover of
impediments to progress
for the Development
Team.
The Scrum Master holds a
brief meeting everyday to
assess progress of the
Development Team and
provides the conditions to
reach the Sprint goal.
The Scrum Team consists
of the Development Team,
Product Owner, and
Scrum Master.
All members are
responsible for delivery
of a complete product.
Each team member plays a specific, well defined, role, at
the same time holding each other accountable for shared
outcomes of the project and its business value.

34. The Product Owner
§ The product owner is the cornerstone of project
success, responsible for defining the work that needs
to be completed and prioritizing that work.
§ The product owner reviews and reprioritizes
outstanding work based on shifting needs and
ongoing feedback.
§ The product owner is the hub of business value for
Scrum initiatives A product owner must be highly
self-disciplined to avoid trying to manage the
development team's activities. The PO is assisted in
that by the ScrumMaster
34/110

35. The Scrum Master
§ The acts as the protector of the team, making sure
that everyone on the project, especially the
development team members, can focus on their
work without any distractions.
§ The ScrumMaster protects the Scrum process itself.
The ScrumMaster is the expert on how Scrum works
and how it should be applied and ensures the
Product Owner and Development team stay within
the Scrum framework.
35/110

36. The Development Team
§ A team of five to nine people and includes the functional
roles required to complete the project.
§ The team acts collectively to determine how to achieve
their goals. The specific features they work on are
determined by the priority established by the Product
Owner. The way they work is guided by the Scrum
process, as monitored by the ScrumMaster.
§ Everything else is up to the team to manage, with the
ScrumMaster providing as much support as needed to
allow that to happen.
§ This level of autonomy is a cornerstone of Scrum
encouraging strong bonds between team members to
create a positive working environment.
36/110

37. Non‒Core Roles
§ Stakeholder ‒ includes customers, users, and
sponsors, frequently interface with the Scrum Core
Team, and influence the project throughout the
project’s development.
§ Scrum Guidance Body ‒ a set of documents and/or a
group of experts who are define objectives related to
quality, regulations, security, and other key
organizational parameters.
§ Chief Product Owner ‒ is responsible to coordinate
Scrum-related activities on C4H projects requiring
multiple Scrum Teams working in parallel.
37/110

38. Scrum Team Member Roles and
Responsibilities One More Time
Scrum Master …
§ Helps the team perform at their highest level, by removing any
impediments to progress, facilitating meetings, and working with
the product owner to assure the product backlog is ready for the
next sprint.
§ Enforces scrum ceremonies and processes.
§ Enables the commitment to goals and deadlines on behalf of the
team.
§ Can be considered a coach for the team.
§ Can also the process owner, creating a balance with the Product
Owner..
Product Owner …
§ Is responsible for conveying the vision ‒ in the form of needed
Capabilities, delivered in Epics ‒ of the stakeholders to the team.
§ Has the authority to alter the scope, budget, needed delivery
dates.
§ These alterations ae reflected in the Product Backlog, by
removing a Story that is no longer relevant or creating a new
Story for newly discovered needs, reassess the priority of a Story
§ Responsible for the return on investment (ROI) which is why
they occupy an authoritative position in the firm.
§ Conveys the vision of the stakeholders their role is to be The
Voice of the Stakeholders.
§ Communicates with the stakeholders about progress and
problems, as well as with the Scrum team.
Scrum Team …
§ Is responsible for all work activities leading towards the sprint
Goals.
§ Works with Scrum Master to prioritize the items from the
Product Backlog in the sprint planning for the current Sprint.
§ Once committed, is responsible to fulfil the commitment and
deliver the agreed results on time with needed quality.
§ Scrum Master is not responsible for keeping the team organized.
It is the duty of the Scrum Team to self-organize.
§ Has to be agile in the office and have to attend every standup
and other ceremonies.
§ Participates in all the meetings no matter their nature and must
to ensure that all the findings of the meetings are being
addressed in the project.
Stakeholder(s)…
§ Maintains a good relationship with the Product Owner to share
business details of the project.
§ Responsible for conveying the wishes and concerns to the
Product Owner or so the product owner will be responsible for
the project quality and time duration.
§ Provides regular input to queries from the Product Owner.
§ Prioritizing the work effectively with the Product Owner is also
the job of the Stakeholder ensure the project is delivering the
needed Business Value.
§ Maintains updates to the needed business capabilities and
communicating updates for any change in the plans.
38/110

39. Project Success using Scrum Starts With
Metrics
Minimum Viable Product (MVP)
The version of a product which allows a team to collect the maximum amount of validated learning from customers
with the least effort. It is the product with just enough Features to satisfy early customers, and to provide feedback for
future product development.
Some Candidate Development Metrics
1. Number of Green Builds per day/week: Discipline within the team, getting code checked in daily, with builds made
often.
2. Percentage of Green Builds: How many builds were good?
3. Unit Test Coverage: Unit Tests should comprise ~80% of all tests and an essential part of building in quality.
4. Code Coverage: Measuring code coverage is a technique for understanding exactly which application code is being
exercised.
5. Defects found per unit of Unit/Functional/Integration Test: While the number of defects slow us down in building.
Find a pattern or the magnitude, planning for releases means easy commitments live their date.
6. Number of defects per feature from Production/UAT/Customer: Understand the important features and making sure
they are built with quality allows developers and builders of the system to concentrate more on where it matters.
7. Physical Percent Complete: Measures as (Planned Progress – Actual Progress) / Planned Progress. The measures
used here can be Story Points or Hours.
8. Rework: Time spent on rework compared to development time.
39/110

40. 40/110

41. WRITING USER STORIES†
Stories are traditionally written on Note Card, annotated with sizing
estimates and comments.
Details behind the stories come out during the conversation with
the customer ‒ since we don’t have direct access the customer,
we’ll have to pretend we’re writing these as if we are the customer.
Acceptance test confirm the story produced the desired outcome.
Stories Describe Outcomes ‒ Not Things.
Stories are NOT Software Specifications.
41/110† “User Stories Applied: For Agile Software Development,” XP Atlanta, 2004, Mike Cohn

42. User of Hotel Reservation System
42/110
Users can restrict
searches so they only
see hotels with
available rooms
A user can make a
hotel reservation
A user can cancel a
reservation
Users can see photos
of the hotels
Writing User Stories

43. What are some Details for the Stories?
§ A User can make a hotel reservation
– Does she have to enter a credit card?
• If so, what cards are accepted?
• Is the charge applied immediately?
– How can the User search for a hotel?
• Can she search by city?
• By quality rating?
• By price range?
• By type of room?
– What information is shown for each room?
– Can users make special requests?
43/110
Writing User Stories

44. Details Added in Smaller Sub‒Stories
44/110
A user can make a
hotel reservation for the
selected room.
A user can make a
hotel reservation.
A user can view
detailed information
about a room.
A user can search for a
hotel, with fields
including city, price
range, and availability.
Writing User Stories

45. More Details are Added Through Test
(exit criteria)
§ Tests express the expectations of the Story from the
Users Point of View
§ These expectations are Outcomes that benefit the
User
45/110
A User can Make a Hotel Reservation with a Credit Card
§ Try it with a valid Visa card then a valid MasterCard
§ Enter card numbers that are missing a digit, have an extra
digit, and have two digits transposed.
§ Try it with a card with a valid number but that been canceled
§ Try it with a card that has a expiration date in the past
Writing User Stories

46. The User in the User Story
§ There are many Users
§ The stories are written from a named user
perspective
§ We’ll assume all the Users have the same goals
§ This approach reveals missing stories
46/110
The Business User can
manage the ads placed
on the Hotel booking
site for sightseeing
tours
Writing User Stories

47. Who is the User of the Hotel Site?
47/110
Mary
Frequent flier who never
knows where she’ll be
next week
Dominic
Hotel chain VP who wants
to monitor the
reservations
Howard
Mary’s assistant that
books her reservations
Laura
Wants to schedule her
family’s annual vacation at
the hotel
Jim
Frequent flier who travels
to the same location
Frequent Flier Infrequent Flier
Scheduler Insider
Repeat Traveler
Writing User Stories

48. Model the User
48/110
Identify attributes that distinguish
one user role from another
How often the
system will be
used
General level of
computer
proficiency
Level of
proficiency with
this software
General goals
of the system
Level of domain
expertise
Writing User Stories

49. Document the User’s Role
49/110
Infrequent Flier
§ Not particularly computer savvy, but adept at using the
web.
§ Will use the software infrequently but intensely
(perhaps 5 hours to research and plan a trip).
§ Values richness of experience (lots of content) over
speed.
§ But, system must be easy to learn and also easily
recalled months later
Writing User Stories

50. What Makes a Good User Story?
50/110
INVEST
Independent Avoid dependencies, which leads to difficult prioritizing
and planning.
Negotiable
Stories are not contracts. Too many details gives the
impression of false precision or completeness. Need
flexibility to adjust.
Valuable Stories must be of value to either Users or Providers for a
service or product.
Estimatable
Estimates are used for planning. Story Points are Ordinal
numbers used for relative sizing. Cardinal numbers
needed for performance measurement and management
Small Large stories (Features) are hard to estimate, hard to
plan, complex, and compound.
Testable Tests demonstrates a Story meets the user expectations
for the outcomes described in the Story.
Writing User Stories

51. Write Stories in Slices
51/110
User Interface
User Process Flow
Business Logic
Middleware
Database
Writing User Stories
Remember, Stories describe Outcomes that benefit the User

52. Write a Closing Story
§ A closed story is one that finishes with the
achievement of a meaningful goal
– The user has accomplished something
§ This story is never done
§ It is something the user does on a recurring basis
52/110
A frequent flier
can make a hotel
reservation
The frequent flier can
automatically use Points
The frequent flier can
reserve a room in the
same hotel with a click
Writing User Stories

53. Keep the User Interface out of the User
Stories as long as Possible
§ On a new project the User Interface doesn’t exist, so
leave it out of the stories as long as possible
§ Include UI detail is a story constrains the possible
solutions
§ Eventually, we’ll have UI‒Specific stories
– Add a page EXIT button in the lower right corner
– Prompt the user with the text Please enter you current
address, county, and state
53/110
Writing User Stories

54. Some Things Are Not User Stories
§ If we have a requirements that doesn’t fit in a User
Story, write something else:
– A Use Case
– Apply User Interface Guidelines
– Apply business rules
– Interface control documents for another system
§ Keep User Stories Light
54/110
Writing User Stories

55. Technical User Stories
§ Technical User Stories are focused on the non-
functional support of the system.
– Implementing backlog database tables
– Extending a service layer
– Performing technical analysis, design, prototyping, and
architectural work
55/110
We need to extend the Kiosk authentication code in our security services layer
to include new authentication mechanism for web-based application including
2-factor-authiruciation, passwords, and user‒centric questions.

56. Types of Technical Stories
§ Product Infrastructure – directly support requested functional stories. This
includes new and/or modified infrastructure. Can also identify refactoring
opportunities, driven from the functional need.
§ Team Infrastructure – support the team and their ability to deliver
software. Surround tooling, testing, metrics, design, and planning. Can
imply the team “creating” something or “buying and installing” something.
§ Refactoring – identify areas for refactoring candidates. Not only code
needs refactoring, but also it can often include designs, automation,
tooling, and any process documentation.
§ Bug Fixes – clusters or packages of bugs that increase repair time or reduce
aggregate of testing time. So this is more of an efficiency play.
§ Spikes – research that results in learning, architecture & design,
prototypes, and ultimately a set of stories and execution strategy that will
meet the functional goal of the spike. Spikes need to focus on prototype
code over documentation. Although we can’t “demo” every spike.
56/110

57. STORY MAPPING
Story maps create visual stories that tell the story about our
software
The story map evolves with the increased understanding of the
User’s needs and the Solution

58. Story Maps Tell the Story of what the System
Does for the Users, in the case …
… Silicon Valley’s Piped Piper’s Cloud Network Story Board
58/110
Story Mapping

59. Frame the Solution with What, Who, and
Why
§ Before mapping, create a short product or
feature brief to frame and constrain what you
map. Think of this as the big story.
§ What names the product, feature to add to a
product, or problem we’d like to solve.
59/110
§ Who names the different types of users who will use the
product, and the “chooser” or customers who will buy it. For
each user and chooser state the benefit they get from using
the product.
§ Why describes the benefit the firm gets by building the
product or feature. Say what users do and how their use leads
to increased revenue or reduced costs.
This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

60. Build a Map of the Big Picture
60/110
§ Focus on getting the whole story. Think
“mile wide, inch deep” The activities and
high-level user tasks that us the whole
story form the backbone of our story
map.
§ Start with the user type most critical to our success. Imagine a
typical day in a user’s life with NES. Map the steps they take as user
tasks left to right.
§ Identify user activities – groups of tasks that work together to
support a common goal. Activities often emerge after you see more
of the story.
§ Add in additional users. As you follow the typical use of our
product, we may find other types of users enter our story. Continue
modeling their story left to right.
This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

61. Explore the Story Map
61/110
§ Fill the body of our story map by breaking down
larger user tasks into smaller subtasks and user
interface details.
§ During this phase we’ll add Stories, split one Story
into two, rewrite Stories, and reorganize them.
§ We’ll use this phase to think “blue sky” about all the great possibilities. Use this time to
think of everything that could go wrong. Don’t worry if our ideas are “in or out of
scope.” We’ll deliberately move things out of scope later.
§ Play “wouldn’t it be cool if...” to help think of great product ideas.
§ Look for variations: What else might users of the system have done?
§ Look for exceptions: What could go wrong, and what would the user have to do to
recover?
§ Consider other users: What might other types of users do to reach their goals?
§ Add in other details like: Description of proposed UI; Business rules; Data elements
§ Involve others. Tell our story to others that understand users and use. They’ll find holes
in our story and help build it up. Tell our story to software developers. They’ll point out
risky or expensive areas, and add in great technology solutions.
This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

62. Slice Out a Viable Release
§ Slice our map into holistic
product releases that span the
users and use of the product.
These slices form an incremental
product release roadmap where
each release is a minimal viable
product release.
62/110
§ For each release name the target outcomes and Impact. Outcomes and
impact says how this release contributes to the overall goal in the “big
why” that motivates building the product, and how users will behave in a
way that helps us reach the goal.
§ For each release, identify product success metrics. Answer the question:
“what would we measure to determine if this product was successful?”
Ideally we’ll find specific changes in user’s behavior as they use the
product the way our story map imagines.
This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

63. Slice Out a Development Strategy
§ Slice the first release of our map into three or more
delivery phases that allow our team to learn fast and avoid
risk. Think of the opening, mid, and end-game phases of a
chess game. This development strategy will help you
release the best product possible in the time constraints
you have.
§ Opening Game builds a “functional walking skeleton” – the
simplest possible functional version of the product. As you
finish "Opening game" vet the product with users and other
stakeholders. Begin validating performance and scalability.
§ Mid Game complete all major functionality and makes
existing functionality richer and more complete. Continue
user testing and leverage feedback to adjust the product.
Continue testing performance and scalability.
§ End Game refines the product in preparation for release.
Continuously assess release readiness based on our release
level product goals. Count on unforeseen work to emerge
during this last stretch of development.
§ Plan the work necessary to refine stories. Workshop stories
with developers and testers to work through details and
agree on acceptance criteria. Plan development and
testing. Build and verify parts of working software.
63/110This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

64. 64/110

65. ESTIMATING WORK IN SCRUM
DEVELOPMENT
Agile development produces working software every Sprint.
Estimating when the Features and Capabilities in the Epics will be
delivered is still needed for any non‒trivial software development
projects
65/110

66. Estimating
Sassy says it a 5 Point Story
Maia says it a 15 Point Story
Bailey says it an 8 Point Story
Theo agrees with Sassy
66/110

67. 67/110
The primary purpose of software
project Planning and Estimating is
not to predict a project’s outcome.
It is to determine whether a project’s
targets are realistic enough for the
project to be controlled to meet
these outcomes as planned.†
‒ Steve McConnell
Estimating

68. When We Need Estimates
68/110
Estimating

69. Three Keys to Agile Estimating
§ Items are estimated relative to each other, rather
than absolutely.
§ Duration is derived rather than estimated directly.
§ Estimating is an ongoing activity, not an isolated task
at the beginning of the project.
69/110
Estimating

70. Requirements Estimating Using the
Cone of Uncertainty
§ Epics and their Capabilities and
Features they contain are big
ideas but there is usually
enough understanding to get
some Rough Order of
Magnitude estimate
§ User Stories can be created
and refined from the Features
with enough details for relative
sizing in chunks of hours
70/110
§ Tasks created at the planning session before development can
be estimates in finer accuracy and procession
Epic
Feature
Story
Task
The Cone of Uncertainty
Estimating

71. Let’s Pause for a Cardinal and Ordinal Interlude to
Address the Estimating Problem
§ When we use a measure of something
we need to know if it is Cardinal or
Ordinal.
§ Ordinal measures tell us the relative
difference between items.
– Uncle Scrooge is relatively rich compared to
Huey, Dewey, and Louie is an Ordinal measure.
§ Cardinal measures are numbers that say how many of something
there are, such as one, two, three, four, five.
– Uncle Scrooge has $1,250,000,000 in gold
§ In Project Performance Management we use Cardinal numbers,
measured in Dollars, Hours, Technical Performance compliance.
§ Story Points are NOT a unit of measure used in Project Performance
Management.
71/110
Estimating

72. Story Points are all the Rage, but …
§ Are measures of Relative work effort – not duration or
actual cost.
§ Story Points are NOT a measures of the cost of scope.
§ Story Points are Ordinal units of measure – relative
measures.
§ Hours are measures of effort as well.
§ Hours also are a measure of Scope:
– From the SOW, each deliverable is assigned a budget PV starting
at the proposal BOE’s.
– From the labor rate, that PV can be converted to Hours of effort
as well as material costs.
§ Performance is a Cardinal unit of measure – absolute
measures, uniformly applicable across the program –
Dead Presidents.
72/110
Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams, North Carolina University, Gabe Brown,
Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation

73. Arithmetic on Cardinal and Ordinal
Numbers
When hear about adding Story Points, caution is needed
– An Ordinal number ‒ a Story Points ‒ denote the position of an
element in an ordered sequence
– Ordinality involves sets and order relations on those sets.
– Cardinal numbers ‒ natural numbers ‒ measure the size or
Cardinality of sets. The possible collection of values describing an
entity – the cost, the duration, the performance or effective
measures
• There is a cardinal number for every possible cardinality.
• A cardinal number is a family consisting of all sets that can be put
into one-to-one correspondence with each other.
73/110
Estimating

74. The Category Error of Arithmetic with Story
Points from our Number Theory Class
§ It means adding or doing any kind of arithmetic on
Story Points (Ordinal Numbers) is a category error.
§ This error occurs when we ascribe properties to a
thing that can’t possibly have that property.
74/110
What this means in English
It means adding or doing any kind of arithmetic on Story Points (Ordinal
Numbers) is a category error.
This error occurs when we ascribe properties to a thing that can’t possibly
have that property.
Recalling from our Number Theory class in college, the definition α + β = sup { α + γ | γ < β } when β is a limit ordinal.
Means that:
1 + ω = sup { 1 + n | n < ω } = sup { n | n < ω } = ω
On the other hand, ω + 1=(ω + 0)ʹ = ω + 1 ≠ ω because α≠αʹ for all α.
This is because α ∈ αʹ therefore these sets are distinct.
Therefore the ordinals are not order isomorphic either (because every well-ordered set is isomorphic to a unique ordinal).
Estimating

75. Increasing Fidelity of Deliverables and Their Estimates
Starting with Tee‒Shirt Sizes and Moving to Hours
75/110
Epic
Feature
Feature
User Story
User Story
User Story
Tasks Tasks
TasksTasks
Tasks Tasks
TasksTasks
Tasks Tasks
TasksTasks
Tee-Shirt Sizing Hours for Stories and Tasks
Estimating

76. Estimating in Hours is the basis for measuring Physical
Percent Complete Starting with Tee Shirt Sizing
76/110
XS S M L XL
1 ‒ 4
Hours
XS
4 ‒ 12
Hours
12‒ 24
Hours
24 ‒ 48
Hours
48 ‒ 64
Hours
Estimating
Place these assessed and sized User Stories in the Product Backlog with the Time Estimate
for the Story. Everyday update that Time Estimate with the Time Spent on the story and the
Time Remaining for the story. The result will be a Story Burndown chart, rolled up to the
Feature, then to the Epic, showing Physical Percent Complete from the Story to the Epic
Each work day is budgeted at 6 Hours

77. Sprint Backlog Estimating
§ The Sprint
Backlog is a list of
Stories identified by
the Scrum team to
be completed
during the Sprint.
§ During the sprint planning meeting, the Scrum team
selects some number of Product Backlog Items, in
the form of User Stories, and identifies the Tasks
necessary to complete each User Story.
77/110
Estimating

78. Tasks Implement Stories
§ Tasks compose the team's internal plan on how they
will get Stories to Done from the items in the Sprint
Backlog.
§ A Task is a small, undivided, chunk of work to be
done or undertaken, usually by the Team, within a
single Sprint.
78/110
Estimating

79. Rolling up Estimates from Stories to Features to Epics,
provides visibility to Stakeholder of progress to plan
79/110http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html
Estimating

80. 80/110
In the Presence of Uncertainties found on all Software Projects,
without a Target to Steer toward, the Measures of progress
toward that Target, in Units meaningful to the decision makers,
and the Corrective Actions needed to stay on Target, there is
little hope of project Success before time and money runs out.
Making credible Estimates of Planned work adjusted for Risk and their
impacts on Cost, Schedule, and Technical performance is the Critical
Success Factor for our project work.
Estimating

81. Levels of Planning in Scrum
§ Two Levels of Planning
– Strategic Planning ‒ Product Roadmap, Release Plan
– Tactical Planning ‒ Product Backlog, Sprint Backlog
§ Requirements elicitation ‒ Needed Capabilities to fulfill
the Mission and Vision of the Project
§ Estimating processes ‒ for all resources, facilities, tools,
and other enabling processes.
§ Release Planning ‒ when will the Capabilities be available
for use to start delivering Value in exchange for the cost
to produce that Value?
§ Sprint Planning ‒ what Stories are needed to produce the
Features that enable the Capabilities to delivered as
needed to fulfill the Mission of the Project?
81/110
Estimating

82. Characteristics of a Credible Estimate
Characteristic Description
Identification of needed
business capabilities.
A description of needed capabilities, ground rules and assumptions, and
technical and performance characteristics.
Broad participation in
preparing estimates.
All stakeholders involved in confirming mission need, requirements,
system parameters, and other characteristics.
Availability of valid data.
Sources of suitable, relevant, and available data directly related to the
system’s performance characteristics.
Standardized structure for the
estimate.
Standard work decomposition ensures no portion of the estimate are
omitted ‒ all in work.
Provision for project
uncertainties.
Uncertainties identified and allowance developed to cover the cost.
Known costs included. Unknown costs allowed for.
Independent review of
estimates.
Independent review of an estimate crucial to establishing confidence in
the estimate.
Revision of estimates for
significant changes.
Estimates updated to reflect changes in a system’s requirements.
82/110
Estimating

83. Product Owners Role in Backlog Grooming†
§ Remove User Stories that no longer appear relevant
§ Create new User Stories in response to newly
discovered needs
§ Re‒assess the relative priority of User Stories
§ Assign estimates to User Stories which have yet to
receive one
§ Correct estimates in light of newly discovered
information
§ Split User Stories which are high priority but too
coarse grained to fit in an upcoming iteration
83/110† Scrum Alliance, Definition of Backlog Grooming
Estimating

84. Problems with Estimating on Agile Programs
Problem Solution
It’s hard to know exactly how long the work will
take.
All project work contains uncertainty. Probabilistic
models are starting point for credible estimates.
People are not very good at estimating.
Standard techniques applied ‒ Wide Band Delphi is
standard Agile process. Reference class, and
parametrics.
Sometimes we get interrupted and it takes longer
than expected.
Margin required for all project work.
This margin can be determined by keeping track of
actual hours worked and adjusting for the real
world
Sometimes we find unexpected problems.
Risk management is adults manage projects – Tim
Lister
Planning by the hour or day is the wrong incentive.
Plan for deliverables with capacity for work
estimates
Activities are interdependent.
Product Roadmap and Release Plan reveal
interdependencies needed to show delays.
Estimating
84/110

85. CALCULATING PHYSICAL PERCENT
COMPLETE FOR THE NES PROJECT
USING SCRUM PERFORMANCE
AND JIRA ESTIMATES
Developing software using Scrum still needs the ability to determine
the Estimate to Complete (ETC), the Estimate at Completion (EAC),
and the Estimated Completion Data (ECD) when there is a fixed
deliverable date, a fixed budget for that software, and a minimal set
of Features and Capabilities on that date for that budget
85/110

86. 86
The question asked of every parent and
every software development project is …
Are We There Yet?
86/110

87. Looking for Simple Solutions to Questions?
They’re Aren’t Any …
The $20M Question ‒ How can we seamlessly integrate Scrum Development with
Project Performance Management measured in Dollars and Hours?

88. 1. What Does DONE Look
Like?
2. How Do We Get to DONE?
3. Is There Enough Time,
Resources, And Money To
Get to DONE?
4. What Impediments Will Be
Encountered Along The
Way to DONE?
5. What Are The Units Of
Measure For Assessing
Progress Toward Done for
each Deliverable?
Let’s start with Immutable Principles
of Project Success with Five Easy
Questions …
Performance-Based Project Management®, Copyright © Glen B. Alleman, 2017, All Rights Reserved
QUESTIONS
88/110

89. We are successfully applying the Five Immutable Principals of Project
Success to Agile Programs if we …
1
… have a defined Mission, Vision, Capabilities, and High Level Technical and
Operational Requirements ‒ by which to create …
2
… a Product Roadmap for delivering these Capabilities and connecting the
Requirements and Release Plan for producing the needed outcomes to meet
this Roadmap ‒ and have …
3
… allocated enough Time, Money, and Resources to increase the probability of
the project’s success ‒ and we …
4
… know what Risks are in front of us and their plans for retirement or handling ‒
and we can …
5
… confirm progress to plan with measures of Physical Percent Complete for each
Deliverable in the Release Plan with confidence of “on or before the planned
time and “at or below” the planned cost.
89/110

90. 10 Steps to an Integrated Agile and Performance
Management System Using Physical Percent
Complete
Capabilities Defined
in Product Roadmap
Release Plan Defines Work
assigned to Sprints
Release Contains Features
in Sprint
Measure Physical
Percent Complete for
Each Feature
Perform Work IAW
Roadmap and Backlog
Physical Percent
Complete Defines
Progress
Adjust P&C for Technical
Performance
Measure
Use Past Performance to
Forecast Future
Performance
1
2
3
5
6 7
8
9
10
Work Sequence of
Features Defined in
Roadmap
4
9
Assess the capabilities being provided through the delivered Features
Fulfill the requirements through effort held in the Product Backlog
Produce deliverables from
Product Backlog
Planned Budget
Physical % Complete
WP’s produce deliverables
that fulfill requirements
Capabilities
topology defines
requirements flow
down
WP flow must describe the
increasing maturity of the
product or service
Producing the deliverables in the planned
sequence maintains the value stream to
the customer
90/110

91. 10 Steps to Integrating Agile Development and Performance
Management System Using Physical Percent Complete
Principles to Integrate Agile with Project Performance Management in Order of Increasing Maturity
1 Capabilities drive system Features. All Features must be traceable to a capability.
Features and their Stories and Tasks identify technical and process deliverables.
Sprints contain the work activities used to produce the deliverables.
Product Roadmap arranges the Capabilities and their Features – risk adjusted – into activity
flow, from which Stories can be developed as the Basis of Estimate for the Sprint teams.
Work progress is measured as Physical Percent Complete against the planned progress at
time of the performance assessment.
Work Authorization (Backlog Grooming and Sprint Backlog) assures the sequence of Work
produce progress at the planned rate for the planned cost, with the planned product maturity at
each assessment point in the IMS.
Performance Measures describes the current performance and provides information about
future performance.
Conformance with Technical Performance Measures (TPM) adjusts Program Performance for
rework, quality, or delayed features, using Units of Measure meaningful to the decision makers.
Performance feedback from each Sprint and resulting Stories and Features, sequences the
Product Roadmap to reestablish an on–time, on–budget master schedule.
Future performance is based on the To Complete Performance Index (TCPI), Independent
Estimate At Complete (IEAC), and the adjusted work sequence. 91/110

92. Forecasting Future Performance needed to
successfully manage the project Starts with …
What Stories and Tasks did we plan to produce?
Where are we now? (Physical Percent Complete)
What Stories and Tasks have been completed now?
Produced = Planned × Physical Percent Complete
Determining where we are now.
Is determined with a simple calculation
92/110

93. A Popular Bumper Sticker
in Boulder, Colorado (my
home town), says
Measures of Physical Percent
Complete are required to assess
progress to plan in presence of
uncertainty.
Trouble is, it’s not true.
— J. R. R. Tolkien
We need a target to steer
toward, and we need
measures of progress toward
that target.
That target is a statistically
random number, so estimates
of the target and progress to
the target are needed.
Those estimates must be in
units meaningful to the
decision makers.
93/110

94. Measuring Physical Percent Complete …
§ Product Effectiveness ‒ a measure of success that
are closely related to the achievements of the
operational objectives evaluated in the operational
environment, under a specific set of conditions. †
§ Product Performance ‒ a physical or functional
attribute relating to the system operation, measured
or estimated under specific conditions. †
Means Compliance With Planned Attributes Of Each
Deliverable Defined as Exit Criteria in the User Story
Physical Percent Complete requires measures meaningful to the decision makers.
Effectiveness and Performance are the starting point.
94/110

95. Measuring Physical Percent Complete …
§ Key Performance Parameters ‒ a capability and
characteristic so significant that failure to meet them
can be cause for reevaluation, reassessing, or
replanning of the project.
§ Technical Performance Measures ‒ an attribute that
determine how well a system or system element is
satisfying or expected to satisfy a technical
requirement or goal.
Means Compliance With Planned Attributes Of Each
Deliverable (Exit Criteria)
95/110

96. Performance Measures Start at the Task Level
for each Story in the Sprint
§ For work Started, what is TO DO
compared to Planned?
§ Physical Percent Complete at the Task Level
o (Planned Estimate ‒ TO DO) / Planned Estimate
§ For Story S70 ‒ Purchase Your Items
o (26 hrs ‒ 16 hrs) / 26 hrs = 38%
o Task S70 has 2 Story Points assigned to it for 26 hours
Task S73 has 3 Story Points and 8 hours
o Story Points can be used to prioritize but not measure
96/110

97. Project Performance Measures at the
Release Level
Capability
Feature (1-6)
18%
Feature (7-9)
18%
Feature (10-12)
28%
Feature (13-22)
36%
Release 1 Release 2 Release 3
The Bright Line
Physical Percent Complete (P%C) for the Capability
assessed at the end of each Release.
Release 1 = Capability 18% Complete
Release 2 = Capability 64% Complete
Release 3 = Capability 100% Complete
Project
Performance
Reporting
Agile Team
Reporting
Summing Physical Percent Complete from Tasks and Stories
to Features to Release.
97/110

98. Physical Percent Complete …
§ The Project Performance completion criteria must be based on technical
performance, the quality of work must be verified, and criteria must be
defined clearly and unambiguously.
§ The PO/PM ensures that this process measures quality and technical
maturity of technical work products instead of the quantity of work
performed.
§ In Agile Physical Percent Complete means Working Software at the end of
every Sprint.
§ The challenge in Agile is to account for deferred capabilities ‒ moved to
the next Sprint or Release ‒ and moving Budget to follow them.
§ But in Agile, Budget is flat spread connected with the labor assigned to
each Sprint that implements the Features.
… means compliance with planned Technical
Performance of Deliverable
98/110

99. Story Points are NOT a Meaningful
Measure of Physical Percent Complete
https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
In Agile,
Story Point-based
measures are
about the Relative
effort the work will
take, not the actual
effort or duration
99/110

100. Let’s Pause for an Interlude to Address the
Cardinal and Ordinal Estimating Problem
§ When we use a measure of something we
need to know if it is Cardinal or Ordinal.
§ Ordinal measures tell us the relative
difference between items.
– Uncle Scrooge is relatively rich
compared to Huey, Dewey, and Louie
is an Ordinal measure.
§ Cardinal measures are numbers that say how many of something there are,
they are counting numbers ‒ one, two, three, four, five.
§ Uncle Scrooge has $1,250,000,000 dollars of Gold
§ In Project Performance Management we use Cardinal numbers, measured in
Dollars, Hours, Technical Performance compliance.
§ Story Points are NOT a unit of measure used in Project Performance
Management.
Ordinal versus Cardinal is a critical understanding for success of Physical Percent Complete.
100/110

101. A Caution for using Story Points to Measure Progress
Beyond a Single Feature from a Single Team
Ordinal
numbers ONLY
have meaning
for their current
use ‒ unless
calibrated to a
reference that
does not
change over
time
Without Calibrated values, the numbers have no meaning when collected at higher levels of the
program ‒ Features and Epics. 101/110

102. Ordinal Story Points cannot be the basis of Value higher
than a single Feature developed by a single team
Feature 1
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Team 1’s
Uncalibrated
Ordinal SP
estimates
Feature n
Team 2’s
Uncalibrated
Ordinal SP
estimates
∑ F1(SP) ∑ Fn(SP)
Release 1 ∑ of SP’s
• • •
§ At the Story level,
relative effort defines
individual estimates.
§ At the Feature level,
lower level SP’s don’t
have the same unit of
measure in the way
Dollars do.
§ When Features
summed to the
Release, relative
measures do not
provide basis of
Physical Percent
Complete.
These are Not the same units of measure
between Features – Uncalibrated SP’s
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6• • •
Using Ordinal (uncalibrated values) outside the domain of agreement prevents comparison of
progress to plan. My Story Points aren’t Your Story Points. 102/110

103. 103/110
What are some simple steps we can take to move forward?
I Feel like we may
be overthinking this,
so back to 3 basic
principles

104. 3 Simple Steps
§ Build the Product Roadmap and Release plans
showing when specific Capabilities will be ready for
release, so training of the NES staff can start
§ Install a Physical Percent Complete process that can
be looked at every single day to assure progress is
being made toward releasing those Capabilities as
needed.
§ Work every day on clarify what Done looks like at the
Story level so the developemnt team has the
confidence they are working toward a goal that
supports the delivery of the needed NES Capabilities.
104/110

105. Agile Team
The Agile Team is a cross-functional group of five to nine individuals who have the ability and authority to define, build, and
test solution value—all in a short-iteration timebox. The team includes the individuals necessary to successfully deliver this
value, supported by specialists where applicable.
Acceptance Criteria (Exit Criteria)
The criteria which defines the functionality, behavior, and performance required by the feature for it to be accepted by the
product owner or customer. This acceptance criteria can also be applied to Tasks, Stories, and Features.
Backlog (Product and Sprint)
A collection of prioritized requests for work to be done.
Backlog Grooming (Product and Sprint)
An ongoing process whereby the Product Owner or customer manages the Product Backlog based on information gathered
in the feedback cycles inherent to agile practices. The activities of backlog grooming can include: adjusting rank; breaking
down stories that are going to be worked on in the next few iterations; creating new stories; updating existing stories;
deleting obsolete stories; elaborating acceptance criteria.
Bug
Business Capability
A Capability provides value to an external Stakeholder. A Capability is a higher-level solution behavior that typically spans
multiple Releases. Capabilities are made up of collections for Features that provide the higher-level behaviors.
Customer (End User, Stakeholder)
A person or organization, internal or external to the producing organization, who takes financial responsibility for the
system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and
its work items. See also stakeholder.
Glossary
105/110

106. Capacity
Amount of work a team can complete in a given time period.
Capacity Planning
Matches business demand with available supply, so you can optimize your agile teams’ capacity towards the highest
business value within their capacity.
Daily Standup
A brief meeting held between the Delivery Team, Product Owner, and Scrum Master. Each team member reports on what
work they did yesterday, what they plan to do today, and alerts the scrum master of any issues that may be blocking them.
The Scrum Master uses this information to update and reporting materials (Burn Down Charts, Physical Percent Complete).
This meeting is held in front of the Task Boards (Structures in Jira) and the Scrum team speaks to the content there
Definition Of Done (DOD)
A living definition created and managed by the delivery team, defining their current standards for technical excellence. The
definition typically includes the requirements the team has to meet in order to declare any work item worked on in an
iteration done. These differ from acceptance criteria in that they are typically technical in nature and generalized to be valid
for most work items (such as unit tests complete, online help updated), as opposed to value-driven criteria specific to a
feature (such as website users should only be able to create one account per email address).
Dependency
A relationship between two element work items, in which a change to one work item will affect the other work item.
Epic
A time based container of Business Capabilities implemented by Features resulting from Stories developed in Sprints
Feature
A service provided by the system that fulfills a stakeholder need. Features are maintained in the Product backlog, sized to fit
in a Project Release so that each release. Each feature includes a statement of benefits and defined acceptance criteria.
Features are structured as <Action><Result><Object>
The Feature is placed on the Product Backlog with its estimated development in an Engineering Estimating processes (ROM)
An example of a Feature statement is ‒ Display the name and address of a student on a transcript.
Glossary
106/110

107. Integration Test
Information Radiator
Large oriented displays which a team places in highly visible locations, so all team members as well as passers‒by can see
the latest information at a glance.
Product Owner (PO)
The Product Owner is the team member responsible for defining Features and Stories and prioritizing the team
backlog. The Product Owner is also a member of the extended Product Manager/Product Owner
team, understanding and contributing to the program backlog, vision, and roadmap.
Product Owner (PO)
The Product Owner is the team member responsible for defining Features and Stories and prioritizing the team
backlog. The Product Owner is also a member of the extended Product Manager/Product Owner
team, understanding and contributing to the program backlog, vision, and roadmap.
Story Planning Estimate
The amount of effort estimated to complete a single User Story. Planned estimates are represented by points, t-shirt sizes,
hours or other measures. Cardinal numbers are preferred.
Product Backlog (PBL)
A prioritized list of functional and non-functional requirements for a system or product. A product backlog may be created
and prioritized on the Backlog page, under the Plan menu in Jira. The Product Backlog holds the Features that stared in the
Rough Order of Magnitude estimate to the customer. Stories that were returned from Sprints can also be in the Product
Backlog.
Product Backlog Item (PBI)
Can be user Stories, Features, Defects or any other item that will require the time of the delivery team to deliver the
feature. They are typically estimated at the gross or plan level.
Product Owner (PO)
A role on an agile delivery team that is responsible for collecting and ranking business requirements on the product backlog.
A product owner does not manage a delivery team but communicates what must be built in the next release or iteration. In
exchange for the team's commitment to finish the top-most ranked work in an iteration, the product owner agrees to
protect the team from any changes in requirements during the iteration.
Glossary
107/110

108. Product Roadmap (PRM)
A high-level or long-range estimation of work to be completed by an organization. Roadmaps may be created for internal
planning or external communication to stakeholders. In agile organizations, roadmaps are subject to change with evolving
business priorities or needs. Jira Structures provides Epics for planning Feature roadmaps with development cadences of
usually XX‒YY weeks.
Release
The goal of Agile is frequent delivery of valuable, working, and fully tested solution increments. This is accomplished via a
stream of releases, each of which has been validated and approved for final efficacy of use and is accompanied by the
documentation necessary to ensure successful application.
Release Planning
A commitment to a plan for delivering an increment of product value. It is a collaborative effort involving scrum masters,
product owners, delivery teams, and stakeholders.
Release Engineer
The Release Engineer (RE) facilitates Agile Release processes and execution. The RE
escalates impediments, helps manage risk, helps ensure value delivery, and drives continuous improvement.
Product Roadmap
The Product Roadmap communicates planned Agile Release Train and value stream deliverables and
milestones over a time line. The roadmap includes committed deliverables and visibility into the forecasted deliverables of
the next few PIs. It is developed and updated by solution and product management as the vision and delivery strategy
evolve.
Rough Order of Magnitude Estimate (ROM)
The ROM is an definition of the Features needed by the customer and the estimate of the hours of work needed to
implement each Feature. The Features are assigned to Sprints to assess the staffing needs to implement the Feature. The
period of performance for each Feature spans Sprints in Jira. The total number of Sprints are reflected in the Feature Period
of Performance in the IMS Work Package contained one or more Features.
Glossary
108/110

109. Scrum Master
The Scrum Master is a servant leader and coach for the Agile team. Primary responsibilities
include ensuring that the process is being followed; educating the team in Scrum;
eliminating impediments; and fostering the environment for high-performing team dynamics,
continuous flow, and relentless improvement.
Sprint
A Sprint is typically of 1-4 weeks in length. The Sprint is where the development work (code, test, review, …) occurs. The
Stories selected for the Sprint are well-formed, with Entry and Exit Criteria, any conditions for the development, any
supporting documentation (process flows, UI mockups, rules) needed to size and develop the story.
Sprint Backlog (SBL)
The Sprint Backlog holds the Stories for the current Sprint. Sprint Planning Meeting
In this meeting the Scrum Team and Product Owner selects the stories the team believes it can commit to in a sprint. These
Stories are broken down into tasks and provide estimates for those tasks if that will further define the work and outcomes
of the Story
Sprit Retrospective
The Sprint Team reviews what went well and what went poorly. The retrospection is used to find potential for
improvement. One or two areas will be selected to focus on for improvement.
Stories
Stories are the primary artifact used to define system behavior in Agile development. Stories are not requirements; they are
short, simple descriptions of a small piece of desired functionality, usually told from the user’s perspective and written in
the user’s language. Each story is intended to support implementation of a small, vertical slice of system functionality,
supporting highly incremental development.
Task
A unit of work that, when performed, contributes to the fulfillment and completion of a scheduled user story within the
iteration. Tasks allow decomposition of stories into manageable units of work. Team members can take responsibility and
ownership for each task, providing estimates and work left to do for completion.
Glossary
109/110

110. Task Estimate
The amount of effort estimated to complete a single task, recorded in hours, but does not directly correlate to user story
estimates.
To Do (Remaining Estimate)
The amount of remaining effort required to complete a task, recorded in hours. This date is used to update the status of
Tasks for each Story. The TO DO value and the Task Est(imate) are used to calculate Physical Percent Complete of the Tasks.
This data is rolled up to the Story and then to the Feature level. From there Physical Percent Complete is calculated
User Story
A listing of acceptance criteria needed to deliver a new feature or piece of work written from the perspective of a user of
the system. A commonly used format is: As a X, I want to Y, so that Z.
Unit Testing
Glossary
110/110