Faraz Uddin

Agile Work Item Hierarchy

At both Bank of America and TIAA, work was broken down into Initiatives, Epics, Features, Stories, Tasks, and Deliverables.

Initiative

A high-level strategic objective that aligns with long-term business goals. Initiatives span quarters or years and help drive enterprise-wide transformation.

Timeframe: Quarterly / Annual

Epic

A large body of work that supports one or more initiatives. Epics are too big for a sprint and are typically broken down into features for implementation.

Timeframe: Multi-PI / Multi-sprint

Feature

A user-facing functionality or capability that delivers business value. Features are derived from epics and broken down into smaller user stories.

Timeframe: 1–2 Sprints

Story

The smallest unit of work that delivers user value. Typically written as: "As a [user], I want [goal] so that [reason]." Stories are sized to be completed in a sprint.

Timeframe: 1 Sprint

Task

The smallest executable unit of work used to fulfill a story. Tasks may include development, testing, documentation, or technical research (Spikes).

Timeframe: Hours to a Day

Deliverable

The tangible result of completed work — such as a working feature, report, or integration. Deliverables are produced after stories and tasks are completed.

Outcome: Released or Demoed

Prioritization and Quality Frameworks

At both Bank of America and TIAA, we used various frameworks to help plan and groom our epics and stories.

RICE Framework

The RICE framework is used for prioritizing features or initiatives based on four criteria:

Reach: How many people will this feature impact in a given timeframe?
Impact: How much will this feature impact the users, from a small to a massive effect?
Confidence: How confident are we that the feature will achieve the desired impact?
Effort: How much effort, in terms of person-hours, will it take to complete this feature?

These factors are used to calculate a score for each feature, helping teams make data-driven decisions about what to prioritize next.

Used for: Prioritizing Features and Initiatives

MoSCoW Framework

The MoSCoW method is used to prioritize requirements or features. It helps in categorizing them into four buckets:

Must have: Essential requirements that must be included in the current iteration.
Should have: Important features that should be included if possible but are not essential.
Could have: Nice-to-have features that could be included if time and resources permit.
Won't have: Features that will not be included in the current iteration but might be considered later.

MoSCoW helps teams focus on delivering the most critical features first, while also managing scope and expectations.

Used for: Prioritizing Features or Requirements

SMART Framework

The SMART framework helps in setting clear, actionable goals. It stands for:

Specific: The goal should be clearly defined and focused on a single outcome.
Measurable: There should be clear criteria to measure progress or success.
Achievable: The goal should be realistic and attainable, given the available resources.
Relevant: The goal must be aligned with broader objectives and meaningful to stakeholders.
Time-bound: The goal should have a clear deadline or timeframe to create a sense of urgency.

SMART ensures that goals are not only clear but also feasible and measurable for proper tracking.

Used for: Setting Clear, Actionable Goals

INVEST Framework

The INVEST framework is a checklist designed to ensure high-quality user stories. The elements are:

Independent: The user story should be self-contained, without dependencies on other stories.
Negotiable: The user story should allow for discussion and negotiation regarding the details.
Valuable: The story should deliver value to the customer or end-user.
Estimatable: The team should be able to estimate the effort required to complete the story.
Small: The story should be small enough to be completed within a single sprint.
Testable: There should be clear acceptance criteria so that the story can be tested upon completion.

INVEST helps in creating well-structured user stories that are clear, actionable, and valuable for the team and stakeholders.

Used for: Structuring High-Quality User Stories

TIAA Sample User Story & Acceptance Criteria: Investment Screener Tool - Filtering Funds by Morningstar Rating

Below is a sample user story with acceptance criteria (AC) presented in two distinct styles.

What Makes Good Acceptance Criteria?

Good acceptance criteria should possess specific qualities that ensure alignment, clarity, and verifiability across the team:

Clarity: Criteria should be straightforward and easy to understand for all team members, avoiding any confusion.
Conciseness: Communicate the necessary information without unnecessary detail.
Testability: Each criterion must be verifiable, allowing testers to clearly determine whether it has been met.
Result-oriented: Focus on delivering results that gratify the customer, emphasizing the end benefit or value.

User Story Example

As a TIAA Investment Screener Tool user, I want to filter funds by their Morningstar rating so that I can view funds with ratings from 1 to 5 stars, ensuring I have the flexibility to choose funds based on my desired level of performance.

Acceptance Criteria (Rules-Based)

Acceptance Criteria (Rules-Based) refers to a specific type of acceptance criteria used in Agile development to define clear, objective conditions that must be met for a user story or feature to be considered complete and acceptable.

Key Characteristics:

Objective and Binary: Rules-based criteria are factual and unambiguous — either the condition is met, or it isn't.

Testable: These criteria can be validated through automated or manual testing.

Example Acceptance Criteria (Rules-Based) Details:

The user should be able to select the "Morningstar Rating" filter from the list of available criteria.
The user should be able to choose a rating from 1-5 stars for filtering funds.
The tool should display only the funds that match the selected Morningstar rating after the filter is applied.
The filter should update the investment results in real-time as soon as the user selects a star rating 1-5.
If the user deselects the "Morningstar Rating" filter, the tool should reset the filter and display all available funds.
The tool should allow users to apply additional filters (e.g., risk level, asset class) alongside the "Morningstar Rating" filter.

Acceptance Criteria (Given-When-Then – Gherkin Method)

Gherkin Syntax is a structured, human-readable format used to define acceptance criteria in the form of scenarios. It follows the Given-When-Then pattern and is commonly used in Behavior-Driven Development (BDD) to clearly express expected system behavior.

Key Components:

Given: Describes the initial context or preconditions. It sets the stage for the action.
When: Specifies the event or action that triggers the behavior.
Then: States the expected outcome or result after the action occurs.

Purpose:

To provide a clear, shared language between business stakeholders, developers, and testers, enabling alignment on how a feature should behave through structured, testable scenarios.

Examples:

Given the user is on the Public, Microsite, or Legacy Investment Screener tool page,
When the user selects the "Morningstar Rating" filter and chooses 1-5 Stars,
Then the tool should display a list of funds that have a Morningstar rating of 1-5 stars based on the user's selection.
Given the user has applied the "Morningstar Rating" filter and selects 1-5 Stars,
When the user applies additional filters such as "Asset Class" or "Risk Level,"
Then the tool should display only funds that meet both the selected Morningstar Rating and the additional filter criteria.
Given the user has applied the "Morningstar Rating" filter with a selection of 1-5 Stars,
When the user clears the filter selection for "Morningstar Rating,"
Then the tool should reset the filter and display all available funds.

Testing Areas

The following testing areas should be covered:

Public Site: Ensure the filter works properly on the public-facing version of the Investment Screener tool.
Microsites (Personal & Institutional Sites): Verify that the filter operates as expected on the Microsite versions for both personal and institutional users.
Legacy Channels: Test that the "Morningstar Rating" filter is functioning correctly across all legacy platforms where the application is deployed.

Commonly Used Terms for Grooming

Term	Definition	Context in Agile
Epic	A large body of work that can be broken down into smaller Features or Stories.	Used to organize major deliverables across multiple sprints or Program Increments (PIs).
Feature	A service or functionality that delivers business value. Usually derived from epics and implemented through stories.	Often implemented over 1–2 sprints and decomposed into User Stories.
Story	A user-facing requirement, typically expressed as: "As a [user], I want [goal] so that [reason]."	Smallest unit of work committed to in a sprint.
Acceptance Criteria	A set of predefined requirements that a user story must meet to be accepted as complete.	Clarifies expectations and forms the basis for test cases.
Story Points	A relative measure of effort or complexity assigned to a story, typically using Fibonacci numbers (1, 2, 3, 5, 8...).	Used during sprint planning to estimate team capacity and velocity.
Backlog	An ordered list of all the work that might be needed, prioritized by value and readiness.	Continuously refined and owned by the Product Owner.
Backlog Grooming	The ongoing process of refining the product backlog by reviewing, clarifying, and prioritizing items for upcoming sprints.	Ensures stories are well-defined and ready for sprint planning.
Definition of Ready (DoR)	Checklist that ensures a backlog item is well-understood, sized, and actionable before sprint planning.	Ensures team confidence in committing to the work.
Definition of Done (DoD)	Agreed-upon checklist of criteria that must be met for a story or feature to be considered complete.	Aligns team expectations and maintains quality standards.
Dependency	A relationship where one work item is contingent on another being completed first.	Tracked to coordinate across teams and avoid blockers.
Velocity	A measure of how much work a team can complete in a sprint, often calculated using story points.	Used to predict future sprint capacity and plan releases.
2-Week Sprint	A fixed-length iteration (commonly 2 weeks) where teams deliver potentially shippable increments.	Enables consistent cadence and timely feedback loops.
Program Increment (PI)	A timeboxed cycle (typically 8–12 weeks) in which Agile teams deliver incremental value aligned to shared objectives.	Central to SAFe planning and synchronization across teams.
Increment	The sum of completed work at the end of a sprint that meets the Definition of Done.	Demonstrated during sprint review; may be released to production.
RICE	A prioritization framework using Reach, Impact, Confidence, and Effort to score and rank product ideas or features.	Used by Product Owners to make data-informed prioritization decisions.
INVEST	A checklist for high-quality user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.	Used to evaluate whether a story is well-formed and actionable.
Scrum	An Agile framework with roles (Product Owner, Scrum Master, Development Team), events (Sprint, Daily Standup, Retrospective), and artifacts (Product Backlog, Sprint Backlog).	Enables teams to deliver value iteratively and incrementally.
Sprint	A fixed-length timebox (1–4 weeks) in which a team works to deliver a potentially shippable product increment.	Includes planning, daily standups, review, and retrospective.