Sprint & Project
Methodology
How we structure work into iterative sprints — from discovery, through delivery, into continuous improvement — with transparency at every step.
Project Methodology
We combine the Double Diamond framework for discovery with an Agile approach for development — ensuring iterative progress, continuous delivery, and alignment with business outcomes.
Double Diamond
Diverge to explore the problem space, converge to define the right challenge — then diverge again on solutions before converging on what to build.
Agile Delivery
- › Continuous delivery cadence
- › Product roadmap & prioritization
- › Release planning
- › Design, develop, test
- › Working product each iteration
Human-Centered & First Principles Design
Our journey revolves around five stages — research, definition, solutioning, execution, and continuous refinement — grounded in first-principles thinking: question every assumption, then build from the ground up.
Engage stakeholders through surveys, research, and interviews to understand existing processes, challenges, and pain points.
Identify the issues most relevant to the organization through further engagement and validation sessions.
Apply divergent thinking to identify creative solutions and develop a blueprint to optimize business processes.
Team-wide execution following a learn-and-adapt framework.
Verify that measures have yielded positive change and assess whether another iteration is required.
“Question every assumption, create new solutions from scratch, and delete requirements to avoid over-engineering.”
Defining the Components
We organize delivery work into a clear hierarchy. Stories follow the INVEST model — Independent, Negotiable, Valuable, Estimable, Small, Testable.
Epic
A large, overarching initiative that defines a key project goal and spans multiple features or deliverables.
Feature
A specific deliverable or capability that contributes to completing an epic. Each feature usually spans multiple stories.
User Story
A short, simple description of a need from the perspective of an end user or stakeholder.
Bug
A flaw, error, or unintended behavior in a system that causes it to function incorrectly or not as intended.
Pointing System — A Rough Guide
| POINTS | EFFORT / PERSON | NOTES |
|---|---|---|
| 1 | 0.5 – 1 day | Trivial fix or minor configuration change. |
| 2 | 1 – 2 days | Small task; straightforward with little unknown risk. |
| 3 | 2 – 3 days | Moderately sized task; some uncertainty to clarify. |
| 5 | 3 – 5 days | Larger feature or significant configuration; multiple steps. |
| 8 | 5 – 8 days | Complex, multi-step effort; likely needs cross-team input. |
| 13 | 8 – 10 days | Very large item; possible multi-sprint scope if not split up. |
| 20 | 10+ days | Epic-level — break it down further whenever possible. |
A highly experienced team may complete 5-point stories more quickly than a newer team.
Multiple team members work in parallel, so total effort doesn’t add linearly.
A 5-point story can grow to 8 or 13 if hidden complexities are discovered.
If velocity is 20 points per two-week sprint, that's the team's combined output — not one person's.
Issue Path to Resolution
Every enhancement and bug carries a status throughout build and test — giving us a clear view of throughput, health, and mean time to closure.
Logged with title, description, steps to reproduce, expected/actual behavior, and severity.
Reviewed for accuracy. Reproducibility, scope alignment, priority, and acceptance criteria confirmed.
Assigned and underway. Dependencies in place; updates posted to the item.
Implementation done, unit-tested, and published to the development environment.
Assigned to a tester with evidence of unit testing attached.
Test cases — including edge cases — executed. New bugs are logged and linked.
All QA tests pass; build is available and stakeholders are engaged for sign-off.
Formal sign-off received; documentation finalized; Product Owner accepts the item.
Final approvals complete; deployment instructions validated; downstream systems notified.
Deployed and validated in production. Metrics monitored, stakeholders notified.
Environments Path
From ingestion to production: data flows through processing into a Studio for build, review, and QA. After UAT acceptance, our delivery team transfers the code, performs smoke testing, and — following CAB approval — publishes to the production environment.
- —DEV
- —PROD
- —Extraction
- —Processing Pools
- —Data Jobs
- —Development
- —Review
- —QA
- —Client Review
- —Acceptance
- —Smoke Test
- —CAB Approval
- —Apps Environment
Severity Levels
Defects, enhancements, and releases are tracked centrally. We maintain a detailed history of updates and share ticket reports and dashboards on a weekly cadence.
Critical
System is inoperable, or a problem has no workaround and extreme impact on multiple users.
High
Important business functionality within a production system is degraded.
Medium / Low
Moderate-to-low impact on business functionality.
Low
Very low impact on business functionality.
Improvement
A change or improvement to design; tracked as a Story rather than a defect.
Comment
A question to stakeholders — not a defect or enhancement.
Reporting Bugs
When logging a bug, it is critical to trace the steps, include screenshots, and clearly capture how to reproduce the issue — especially for scenario-based problems.
- ›Statuse.g. Test Failed
- ›Actor / ProfileWhich profile ran the test? Analyst, Admin, etc.
- ›Severity LevelSeverity assigned to the ticket.
- ›Steps to ReproduceSequence of steps that produced the issue.
- ›Expected ResultsWhat the test was expected to produce.
- ›Actual ResultsWhat actually happened.
- Log in as a manager-level user.
- Navigate to the reporting view.
- Open the standard summary report.
The report should include the category field.
The category field is missing from the report output.
Definitions
We segment between bugs and new work to ensure proper alignment on scope — then categorize by severity and priority to keep delivery focused on what matters to the business.
| SEVERITY | PRIORITY |
|---|---|
| Severity 1 | P1 |
| Severity 2 | P2 |
| Severity 3 | P3 |
| Severity 4 | P4 |
Team Retrospective
As we begin sprint-based delivery, we introduce retrospectives so the team can reflect on what went well, what didn't, and what we learned — then vote on improvements for the next sprint.
What went well
Wins, smooth workflows, things to keep doing.
What didn't go well
Pain points, blockers, friction, surprises.
What we learned
Insights to carry forward and experiments to try.
Sprint Demo Guidance
Showcase completed work that meets the Definition of Done.
- ›Identify stories or features to demo (DONE status).
- ›Prep data, test users, and a clean environment.
- ›Rehearse flow and talking points (3–5 minutes per story).
- ›Have a backup — screenshots or a screen recording.
- ›Plain English — avoid deep jargon unless asked.
- ›Stay within 5 minutes per story.
- ›Have a fallback plan for demo failures.
- ›Only show DONE work — never in-progress.
- ›Lead with the user's perspective.
- 01Intro · 30s
“Hi, I'm [Name], demoing [Feature], which enables users to [short goal].”
- 02Context · 60s
“This solves [problem] by allowing [solution] based on [story / feedback].”
- 03Walkthrough · 2–3m
Show the user flow, API response, logs, or UI — keep it simple and clear.
- 04Tech Highlights · 1m
Modules touched, new endpoints, middleware, or test coverage added.
- 05Feedback · 1m
“Any questions or thoughts?”
The Sprint Rhythm
A representative two-sprint cycle across four weeks. Stand-ups and dev & testing run continuously; key ceremonies and the deploy window are highlighted in gold.
Meeting & Task Definitions
Quality Assurance Approach
A layered set of validations ensures that what reaches production reflects reality — accurate at the source, consistent through transformation, and meaningful at the metric layer.
Source-to-Target Validation
Ensure raw data extracted from source systems matches what's loaded into the target platform. Focus on row counts, key field values, nulls, and data types.
Transformation Logic Validation
Confirm that joins, filters, and aggregations perform as expected. Validate intermediate tables when transformations are multi-layered.
Process Model Validation
Validate activity object mappings, ensure uniqueness of object identifiers, and verify timestamp ordering and presence across events.
KPI & Metric Validation
Compare KPIs against trusted reference reports and counts. Include both spot checks and regression testing.
Filter Validation
Ensure filters return correct subsets without distorting business logic — combinations, time-based filters, inclusion/exclusion logic, and hierarchical filters.
Iterate. Deliver. Improve.
Every sprint is a chance to show progress, gather feedback, and adjust — so the product we deliver matches the outcomes you care about.
SPRINT & PROJECT METHODOLOGY · 2026