Scrum lifecycle for Enterprise IT

ENTERPRISE AGILE LIFECYCLE
PRODUCT ROADMAP, RELEASE PLAN, ROLES AND RESPONSIBILITIES,
CAPABILITIES, FEATURES, STORIES, AND SUBTASKS
The core concepts of a Release Based development lifecycle for agile enterprise projects.
The lifecycle starts with the Product Roadmap, showing what Capabilities are provided in
what order, in what Capability, 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 a
Capability to deliver a needed Capability.

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/119

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/119

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 a Capability for the project
Feature‒by‒Feature for the next Release containing
those Capabilities.
4/119

Critical Components of Scrum
5/119

Three Roles of Scrum
§ Product Owner who prioritizes a list of user stories
§ Cross functional Scrum Team whose only objective is
to produce working software incrementally in time
boxed Sprints (usually 2 to 4 weeks)
§ Scrum Master who keeps the team focused on its
goal.
6/119

Three Key Ceremonies of Scrum
§ Sprint Planning ‒ where the team pulls user stories
to be completed in a Sprint from the top of the
prioritized list
§ Daily Standup ‒ to assess Sprint progress
§ Review and Retrospective ‒ at the end of each Sprint
to demonstrate the product, assess lessons learned,
and incorporate improvement in upcoming sprints.
7/119

Three Key Artifacts of Scrum
§ Product Backlog ‒ which contains a prioritized list of
user stories
§ Sprint Backlog which contains work to be completed
in the current Sprint
§ Burndown Chart which depicts the graphical
representation of remaining task hours in one Sprint
and can be used by teams for future capacity
planning.
8/119

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.
9/119

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
10/119

From Capabilities (Delivered in a Release) to Features, to
Stories, to Subtasks – decomposing Requirements into
Releases†
11/119
Capability
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 a 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 ‒ Capability to User Story and Story Mapping”

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

Example of Elaboration and
Decomposition†
13/119
Business Capabilities
Delivered in Capabilities
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 ‒ Capability to User Story and Story Mapping

Identifying Capabilities and Features for the
Enterprise Project†
§ Decompose the Business needs into Business
Capabilities that deliver High‒Level behaviors to
accomplish the Vision and Mission.
§ Capabilities 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.
14/119† “Agile Requirements Decomposition ‒ Capability to User Story and Story Mapping

10 Steps in the Enterprise Agile Lifecycle
15/119
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

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.
16/119

17/119
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

Roadmaps ‒ from Strategies to Tactics
18/119
Story
Feature
Capability
Mission
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?

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.
19/119

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
§ Capability
– A group of Features or Stories with a common strategic
aim.
– HIPPA Compliance
20/119

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.
21/119

Capabilities, Features, Stories, Subtasks
§ 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 a
Capability.
§ 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.
– Capabilities collect the high‒level view of the unifying objective.
22/119

23/119
Product Backlog Contains Features
and Stories Needed to Implement
the Desired Business Capabilities
Contained in the Product Roadmap

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.
24/119
The Product Owner is responsible for the contents,
maintenance, and prioritization of the Product
Roadmap

Product Roadmap in Jira’s Aha!
25/119

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.
26/119

A Notional Release Plan in Confluence (Jira)
27/119

Capability, Feature, Story
28/119
Capability
§ 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

Capability Versus Feature
§ A Capability
– 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.
29/119

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.
30/119

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>
31/119

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.
32/119

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
33/119

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
35/119

Structure of the Successful Enterprise Scrum Team
36/119
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.

Summary of the Roles and Responsibilities of a
Successful Scrum Team
37/119
The Development Team
are the designers and
problem-solvers. Task
allocation and distribution
is determine 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.

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
38/119

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.
39/119

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.
40/119

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.
41/119

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 Capabilities ‒ 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.
42/119

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.
43/119

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.
45/119† “User Stories Applied: For Agile Software Development,” XP Atlanta, 2004, Mike Cohn

User of Hotel Reservation System
46/119
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

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?
47/119

Details Added in Smaller Sub‒Stories
48/119
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.

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
49/119
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

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
50/119
The Business User can
manage the ads placed
on the Hotel booking
site for sightseeing
tours

Who is the User of the Hotel Site?
51/119
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

Model the User
52/119
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

Document the User’s Role
53/119
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

What Makes a Good User Story?
54/119
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.

Write Stories in Slices
55/119
User Interface
User Process Flow
Business Logic
Middleware
Database
Remember, Stories describe Outcomes that benefit the User

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
56/119
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

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
57/119

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
58/119

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
59/119
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.

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.
60/119

Suspended
Open
In Development
Done SIT Open
SIT In Progress
SIT Passed
UAT In Progress
UAT Open
UAT Not Passed
UAT Passed
SIT Not Passed
Development Scrum
System Integration Testing (SIT) Kanban
User Acceptance Testing (UAT) Kanban
61/119
❶
❷
❸
❹
❺
❻ ❼
❽
❾
❿
⓫
⓬
⓭

Step Action
❶
❷
❸
❹
❺
❻
❼
❽
❾
❿
⓫
⓬
⓭
V3: 4/11/18 62/119

Status Location Related Issues Owner
Open
Product Backlog,
Sprint Backlog, or
Active Sprint Board Capability, User Story,
Task, Bug, and
Sub‒Task
Product Owner
On Hold No Board Location
Suspended No Board Location
In Development Active Sprint Board User Story, Task, Bug,
and Sub Task
Development Team
Done Active Sprint Board
SIT Open SIT Board Backlog User Story and Bug Product Owner
SIT In Progress
SIT Board Backlog or
SIT Kanban Board
Test
SIT Test Team
SIT Failed Sit Kanban Board
SIT Passed SIT Kanban Board
UAT Open UAT Open Board
UAT Test Team
UAT In Progress
UAT Board Backlog or
UAT Kanban Board
UAT Failed UAT Kanban Board
UAT Passed UAT Kanban Board 63/119

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 Enterpris Solution
64/119

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
65/119
Story Mapping

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.
66/119
§ 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 project 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

Build a Map of the Big Picture
67/119
§ Focus on getting the whole story. Think
“mile wide, inch deep.” The activities and
high-level user Subtasks 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. Map the steps they take as user Subtasks
left to right.
§ Identify user activities – groups of Subtasks 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.
Story Mapping

Explore the Story Map
68/119
§ Fill the body of our story map by breaking down
larger user Subtasks into smaller sub 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.
Story Mapping

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.
69/119
§ 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.
Story Mapping

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.
70/119This material is derived from “Story Mapping Concepts,” Comakers, LLC
Story Mapping

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

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
73/119

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
74/119

Estimates, Targets, and Commitments
§ Estimates, Targets, and Commitments are
independent of each other
§ Base Targets and Commitments on Estimates
§ Estimates are not Commitments
§ Estimates have Accuracy and Precision
– These words are often wrongly used as synonyms
§ An estimates can be:
– Precise without being accurate
– Accurate without being precise
75/119

Estimating Software is Hard
§ Differences in individual productivity
§ Creative processes are difficult to plan
§ Software in intangible
§ Estimation errors happen because
– Omissions
– Uncertainty
– Change
76/119

When We Need Estimates
77/119
Estimating

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.
78/119
Estimating

Requirements Estimating Using the
Cone of Uncertainty
§ Capabilities 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
79/119
§ Subtasks created at the planning session before development
can be estimates in finer accuracy and procession
Capability
Feature
Story
Task
The Cone of Uncertainty
Estimating

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.
Estimating
80/119

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.
81/119
Agile + Engineering Practices: Experiences of Three Microsoft Teams, Laurie Williams, North Carolina University, Gabe Brown,
Adam Meltzer, Nachiappan Nagappan, Microsoft Corporation

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.
Estimating
82/119

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.
83/119
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

Increasing Fidelity of Estimates
Starting with Tee‒Shirt Sizes and Moving to Hours
84/119
Capability
Feature
Feature
User Story
User Story
User Story
Subtasks Subtasks
SubtasksSubtasks
Subtasks Subtasks
SubtasksSubtasks
Subtasks Subtasks
SubtasksSubtasks
Tee-Shirt Sizing Hours for Subtasks
Estimating

Estimating in Hours is the basis for measuring Physical
Percent Complete Starting with Tee Shirt Sizing
85/119
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 Capability, showing Physical Percent Complete from the Story to the Capability
Each work day is budgeted at 6 Hours
PO
Dev
Hour estimates
from Dev have
concurrence from
PO’s

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 Subtasks
necessary to complete each User Story.
86/119
Estimating

Subtasks Implement Stories
§ Subtasks 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.
87/119
Estimating

Rolling up Estimates from Stories to Capabilities assigned to
Releases, provides visibility to Stakeholder of Progress to Plan
88/119http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html
Estimating

89/119
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

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?
90/119
Estimating

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.
91/119
Estimating

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
† Scrum Alliance, Definition of Backlog Grooming
Estimating
92/119

Problems with Estimating on Agile Programs
and Their Solutions
Problem Solution
It’s hard to know exactly how long the work will
take, when there is uncertainty ‒ reducible and
irreducible.
All project work contains uncertainty. Probabilistic
models are starting point for credible estimates.
People are not very good at estimating, because
they are not trained, don’t have access to past
performance, or credible parametric models of the
work and the processes that deliver outcomes.
Standard techniques applied ‒ Wide Band Delphi is
standard Agile process. Reference class, and
parametrics.
Sometimes we get interrupted and it takes longer
than expected, because we can’t control the
demands on our resources that creates multitasking.
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, because
we have not thought through all the possible risk to
the project
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.
Work activities are interdependent.
Product Roadmap and Release Plan reveal
interdependencies needed to show delays.
Estimating
93/119

CALCULATING PHYSICAL PERCENT
COMPLETE FOR THE 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
94/119

The question asked of every parent and
every software development project is …
Are We There Yet?
95/119

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?
96/119

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
97/119

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.
98/119

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
99/119

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 Subtasks 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. 100/11

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

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.
102/119

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.
103/119

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)
104/119

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
105/119

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
Project
Performance
Reporting
Agile Team
Reporting
Summing Physical Percent Complete from Subtasks and
Stories to Features to Release.
106/119

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
107/119

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
108/119

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.
109/119

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 Capabilities. 110/119

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. 111/119

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
112/119

3 Simple Steps
§ Build the Product Roadmap and Release plans
showing when specific Capabilities will be ready for
release, so training of the Project 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 Capabilities.
113/119

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 Subtasks, 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
114/119

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.
Capability
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
115/119

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.
Glossary
116/119

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.
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 Capabilities 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.
Glossary
117/119

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.
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 Subtasks and provide estimates for those Subtasks 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.
Glossary
118/119

Task
A unit of work that, when performed, contributes to the fulfillment and completion of a scheduled user story within the
iteration. Subtasks 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.
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 (Original Estimate ‒ Remaining Estimate)
The amount of remaining effort required to complete a task, recorded in hours. This date is used to update the status of
Subtasks for each Story. The TO DO value and the Task Est(imate) are used to calculate Physical Percent Complete of the
Subtasks. 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
User Acceptance Test
Glossary
119/119

Scrum lifecycle for Enterprise IT

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Scrum lifecycle for Enterprise IT

Similar to Scrum lifecycle for Enterprise IT (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

Scrum lifecycle for Enterprise IT