❓ Frequently Asked Questions

The Sequifi Delivery Framework is our standard operating procedure for building and delivering software. It covers the complete workflow from idea inception through production release and ongoing support, with clear handoffs between Business, Product, UX/UI, Development, and Support teams.

Three main reasons: Predictability - everyone knows when things will ship; Quality - clear checkpoints prevent bugs from slipping through; Fast response - structured escalation for production issues without derailing sprint work.

Key additions include: formal Definition of Ready/Done gates, 7-day UAT regression testing, design running one sprint ahead, structured support handoff documentation, and mandatory RCA for every P0 incident.

No. The philosophy is "process enables speed, not replaces judgment." We're adding structure where it prevents problems - like quality gates that catch issues before production. We explicitly right-size everything: a bug fix doesn't need a 4-hour PRD session.

Match process rigor to complexity. Large new features get full PRDs, design sessions, and comprehensive testing. Small bug fixes just need a good ticket. Enhancement features get lightweight PRDs. We don't apply heavyweight process to lightweight work.

We don't try to plan precisely what we'll build 2-3 months from now. We focus on the next two sprints and land them well. Beyond that, we have direction and roadmap items, but not detailed specs. This keeps us adaptable.

We commit to the current sprint. We plan the next sprint. Beyond that is intentionally flexible. This allows us to adapt to changing priorities, new information, and urgent client needs.

Precise dates can't be achieved at scale without "big upfront design" which conflicts with agility. Instead, we optimize for delivering value quickly and iteratively. When we show consistent speed, trust builds and focus shifts from "you missed the date" to "how do we get more value."

Customers only benefit from the complete, working product - not from individual components. A feature in staging isn't value delivered. Teams aren't done when their part is done; they're done when value is shipped and customers can use it.

Yes, this is the standard for all teams. Consistency enables cross-team coordination and predictability. That said, we iterate on the framework itself - if something isn't working, we change it through retrospectives.

This is version 1.0. We expect to iterate and improve it based on experience. If something creates friction without adding value, we'll change it.

The product backlog is maintained in Index by the Product Owner.

Submit requests through Index or communicate with the Product Owner. Include: clear title, business justification (why is this needed?), expected outcomes (what does success look like?), and priority rationale (why this priority level?).

The Product Owner triages new submissions weekly. Nothing sits unreviewed for more than one week. You'll receive feedback on whether the item was accepted, needs more information, or was deprioritized.

Priority considers: business/strategic importance, client impact (how many affected, how severe), regulatory or deadline requirements, and dependencies. The Product Owner makes the call with stakeholder input during refinement sessions.

Critical: Business-critical, blocking clients, regulatory (current/next sprint). High: Important for business goals, significant client impact (next 2-3 sprints). Medium: Nice to have, improves experience (next quarter). Low: Future consideration, minor improvements (roadmap/icebox).

Yes. Priorities are validated during bi-weekly refinement sessions. If business circumstances change, raise it with the Product Owner. Priorities aren't set in stone.

Bi-weekly sessions (1-2 hours) where Product Owner, leads, and stakeholders review top 10-15 items. We clarify requirements, define acceptance criteria, validate priorities, and identify dependencies. Items leave ready for design or sprint.

No. Well-understood bugs and small tasks can skip refinement and go directly to sprint. Refinement is for items that need clarification or have complexity.

We target 2-3 sprints worth of items in "Ready" state at all times. This ensures teams never run out of refined work and can plan ahead.

Items with no updates for 3+ months are flagged as stale. We target less than 10% stale items. Stale items are reviewed and either reprioritized, clarified, or closed.

After an item is refined and marked "Ready for Design." Design runs one sprint ahead of development - while dev builds Sprint N, design works on Sprint N+1.

No. Bug fixes, backend changes, and minor UI tweaks can reference existing patterns. New designs are for new features, significant UX changes, or new screens.

High-fidelity mockups for all states (default, error, empty, loading), responsive breakpoints (desktop, tablet, mobile), interaction specifications, exported assets, and a walkthrough with the dev team.

The feature doesn't enter the sprint. We don't start development with incomplete designs. The feature waits for the next sprint when designs are complete.

All designs are created and maintained in Figma.

Full PRD: Large new features. Lightweight PRD (objective + stories + AC): Feature enhancements. Ticket only: Bug fixes. Tech spec: Technical debt/refactoring.

The Product Owner leads PRD creation with input from Functional Lead, Technical Lead, Business Stakeholders, and UX Lead. It's a collaborative effort, typically in a 2-4 hour session per feature.

Feature overview, objectives, business benefits, use cases, user stories with acceptance criteria, design references, dependencies, and explicitly out-of-scope items. See the PRD Template.

When scenarios and use cases are well-detailed, they should read like test cases. QA should be able to derive test cases directly from the PRD without additional interpretation. The PRD becomes the single source of truth for dev, QA, and stakeholders.

Both Functional Lead and Technical Architect must sign off. This is the gate - nothing enters a sprint without an approved PRD (for features that require one) and finalized designs.

That's exactly why we have the session - to resolve disagreements before development starts. Functional Lead facilitates alignment. Unresolved items are documented as "Open Questions" and must be closed before sprint entry.

PRDs are stored in Google Drive: Sequifi Product Docs in each feature's sub-folder.

Two weeks (10 working days).

Sprint Planning. 2-4 hours. The Product Owner presents prioritized backlog items, team discusses technical approach, stories are estimated (story points), and the team commits to a Sprint Goal and Sprint Backlog.

What a story needs before entering sprint: PRD approved (if applicable), acceptance criteria defined, UX/UI designs complete and reviewed, dependencies identified, and story sized under 8 points (otherwise split).

What a story needs to be considered complete: code complete and peer reviewed, unit tests written and passing, integration tests passing, QA tested and approved, documentation updated, deployed to staging.

15-minute timebox, every day. Each team member answers: What did I complete yesterday? What am I working on today? Any blockers? Detailed discussions are taken offline.

Mid-sprint (Day 4-5). 1-2 hours. This prepares items for the NEXT sprint, keeping the pipeline flowing.

Only P0/P1 production issues. Everything else waits for the next sprint. If we constantly interrupt sprints, we lose predictability.

Flag it in standup immediately. Options: reduce scope, split the story, or carry it to next sprint. We don't extend sprints.

If close to done, they carry over to the next sprint. Otherwise, they go back to the backlog for re-prioritization. We don't mark things "done" that aren't done.

Day 10, 1-2 hours. Team demos completed features to stakeholders. Stakeholder feedback is captured. Product Owner accepts or rejects stories based on acceptance criteria.

Day 10, 1 hour, after Sprint Review. Team reflects: What went well? What needs improvement? Output: 2-3 actionable improvements for next sprint with owners assigned.

Sprint Review: PO, leads, scrum team, and stakeholders (open invitation). Retrospective: Technical Lead, PC, dev team, QA. Product Owner is optional. It's a safe space for the team.

Technical Lead protects the sprint. New requests go to backlog for next sprint prioritization, unless it's a P0/P1 production issue that must be addressed immediately.

Capacity is confirmed during Sprint Planning. We account for PTO, holidays, and recurring meetings. The team commits to what they can actually deliver.

Continuously during the sprint as features complete. Days 8-10 are focused on final regression and sign-off.

Staging: Development testing environment. Features are tested as they're built. UAT: Pre-production environment. Full 7-day regression testing happens here before production release.

Comprehensive testing across all modules, all user roles, and all critical paths takes 8-12 hours of actual testing. Spread over a week allows for bug fixes, retesting, and thorough coverage. Rushed testing leads to escaped defects.

All modules, all user roles, all critical paths. Payroll flows get extra attention given their time-sensitivity. It's not just testing new features - it's ensuring we didn't break existing functionality.

Yes. Quality Engineer has veto power on releases. If they haven't signed off, the release doesn't happen.

We prioritize what gets tested. Critical paths and payroll flows are non-negotiable. Lower-risk areas may get lighter testing. Over time, we invest in automation to extend coverage.

A quality checklist for user stories. Independent, Negotiable, Valuable, Estimable, Small, Testable. Stories meeting these criteria are well-defined and deliverable.

Shippable: Can go to production independently. Consumable: Users get value when turned on. Well-defined: Product, Business, Tech all contributed. Estimatable: Team can guess effort. Time-bound: Fits in a sprint.

A bug that makes it to production without being caught in development or testing. We track escaped defects as a quality metric - the trend should be decreasing.

Key metrics: Escaped defects (bugs in production), commitment vs delivered ratio (target >85%), P0/P1 incident frequency (should trend down), and regression test pass rate.

Every Wednesday at 11 AM, after completing 7-day UAT regression testing.

Mid-week provides Monday-Tuesday for final prep and Thursday-Friday for monitoring. It also avoids Tuesday and Friday, which are common payroll processing days for clients.

Wednesday 9 AM, before release. Technical Architect, Quality Engineer, and Product Manager review readiness: all features complete, QA signed off, no P0/P1 bugs, release notes ready, rollback plan ready. Any of them can veto.

P0 or P1 bugs found in UAT. Missing QA sign-off. Incomplete features that are core to the release. Missing rollback plan. Technical Architect, Quality Engineer, or Product Manager veto.

The release moves to the next Wednesday. We don't force a bad release - rushing costs more than waiting a week.

2-hour monitoring window. Team checks: application loads, login works, core features function, error logs clean, performance normal, no spike in support tickets.

Before a release is complete, we document: feature overview, user guide, configuration options, known limitations, troubleshooting guide, workarounds, affected clients, and escalation contacts. Support team must acknowledge receipt.

Not until support handoff is delivered and acknowledged. A feature in production without support documentation isn't complete.

Release notes are prepared before every Wednesday release and shared by Product Owner. Major features get demo recordings.

Rollback immediately: System down, core feature broken for all users, data corruption. Fix forward: Single feature broken with workaround available. See Rollback Procedure.

Technical Architect makes the final call on rollbacks.

Client reports to CSM → CSM posts to #sequifi_support Slack channel with details → Support team triages → Logs in GitHub → Technical Lead classifies severity.

Client affected, priority assessment, functional area, issue description, steps to replicate (if possible), video/PostHog recording (recommended), and payroll cutoff time (if applicable).

Support team acknowledges in #sequifi_support within 1 hour for standard issues, 15 minutes for P0-PAYROLL.

P0-PAYROLL: Time-critical payroll bug, cutoff <12 hours (2-4 hour resolution).
P1-PAYROLL: Payroll bug, cutoff 12-48 hours away (12-24 hour resolution).
P0 Critical: System down, data loss, security breach (4-8 hours).
P1 High: Core feature broken, multiple clients (24-48 hours).
P2 Medium: Feature degraded, workaround exists (3-7 days, next release).
P3 Low: Minor issues, cosmetic (2-4 weeks).

Technical Lead makes the final classification, with input from Technical Architect, Quality Engineer, and Customer Success. When in doubt, we escalate higher - it's easier to downgrade than to realize too late.

P0-PAYROLL has a hard deadline - payroll cutoff is less than 12 hours away. Everything stops. War room spins up immediately. Regular P0 is critical but not time-bound to payroll processing.

For P0-PAYROLL, the team immediately joins a video call and stays connected until the issue is resolved. All hands on deck, continuous communication, updates every 30-60 minutes to affected clients.

They skip full UAT regression. We do targeted testing of critical paths only. Speed matters more. A proper permanent fix may be scheduled for the standard release if the hotfix was temporary.

We explore temporary workarounds - manual fixes, data patches, feature flags to disable the broken component. We communicate transparently with affected clients. Permanent fix follows in standard release.

All bugs are logged in GitHub: SEQ Bug Tracker.

Tier 1: Project Coordinator - first responder, triage (15 min response). Tier 2: Support Engineer + QA - develop and test fix (30 min). Tier 3: Technical Lead + Technical Architect - decisions, approvals, deployment.

Root Cause Analysis. Required within 48 hours of every P0. Uses the 5-Whys method to identify the systemic cause. Output includes immediate fixes (done), short-term improvements (this sprint), and long-term changes (next quarter).

No. It's explicitly blameless. We're asking "what in our system allowed this to happen?" not "who wrote the bug?" Bugs are learning opportunities.

CSM keeps the client informed. For war room situations, updates every 30-60 minutes until resolved. Transparency builds trust even during problems.

Manages the product backlog, prioritizes items, leads PRD creation, facilitates refinement sessions, presents items at Sprint Planning, accepts/rejects stories at Sprint Review.

Cross-team oversight, stakeholder management, validates business alignment, participates in PRD sign-off, makes go/no-go decisions on releases.

Architecture decisions across all teams, technical standards, code review for major changes, merge to main (production deploy), rollback decisions, and leads RCAs for P0 incidents.

Each team's Technical Lead combines technical leadership with Scrum Master responsibilities: makes technical decisions for the team, conducts code reviews, classifies bug severity, merges to staging for QA testing, facilitates sprint ceremonies, removes blockers, protects the sprint from scope creep, coaches the team on process, and tracks action items from retrospectives.

Combining these roles ensures that technical decisions and process facilitation are aligned. The Technical Lead has both the technical authority to make decisions and the process responsibility to keep the team moving. This reduces handoffs and ensures the person facilitating ceremonies also understands the technical constraints and trade-offs.

Technical Architect (shared across all teams) handles architecture decisions, technical standards, and rollback decisions across the organization. Technical Lead (per scrum team) handles their team's technical decisions plus Scrum Master responsibilities like facilitating ceremonies and removing blockers.

Owns release sign-off (can block releases), oversees regression testing, provides input on bug severity classification, ensures test coverage, maintains test automation.

Tracks progress, handles reporting, first responder for support issues (Tier 1), coordinates communication, manages logistics.

Technical Architect, Quality Engineer, or Product Manager - any of them can veto at Go/No-Go.

Technical Lead makes the final classification, with input from Technical Architect, Quality Engineer, and Customer Success.

Technical Architect makes the final call on production rollbacks.

We don't blame individuals. The RCA process identifies systemic gaps. Was it requirements? Testing? Code review? Process? We fix the system, not point fingers.

Shared roles (Functional Lead, Technical Architect, Product Owner, Design Team) span all teams and handle cross-team coordination. Scrum team roles (Technical Lead, developers, QA, PC) are within a single team. Customer Success Team works directly with clients.

Bi-weekly refinement sessions (requirements, priorities). PRD sessions for major features (2-4 hours). Sprint Reviews every two weeks (demos, feedback). You're not in daily standups - that's execution team only.

Roughly 4-6 hours per sprint: bi-weekly refinement (1-2 hours), Sprint Review (1-2 hours), plus PRD sessions for features you're involved in (2-4 hours as needed).

Attend Sprint Reviews to see demos. On the Home page, use the Sequifi Q1 26 and Prodigy Q1 26 roadmaps for planned work. Release notes share what shipped each Wednesday.

We can tell you which sprint it's planned for, but we commit sprint-by-sprint, not months out. Focus is speed and adaptability over precise long-term dates.

For production issues: report through CSM → #sequifi_support. For priority escalation on backlog items: speak with Product Owner or Functional Lead.

Raise it in refinement sessions. Provide business context and impact. The Product Owner makes the call, but priorities are negotiable with good justification.

Sprint Planning is for the execution team. Your input happens earlier - in refinement and PRD sessions. Sprint Review is the ceremony for stakeholder participation.

Sprint Review is the formal venue. You can also provide feedback anytime to the Product Owner, which gets captured as new backlog items for iteration.

Product Backlog: Index
Bug Tracking: GitHub: SEQ Bug Tracker
Feature Development: GitHub: Feature Projects
Designs: Figma
PRDs & Docs: Google Drive
Communication: Slack (#sequifi_support)

Yes. See PRD Template.

Yes. See RCA Template.

User Story template, Bug Report template, Definition of Ready checklist, Definition of Done checklist, Pre-Deployment checklist, Post-Deployment checklist, Code Review checklist, Rollback Procedure. All on the Templates page.

We right-size it. Small changes get small docs. Templates reduce effort. A well-written PRD is requirements, acceptance criteria, and test cases in one - do it once, use it three ways.

Starting from the next sprint. Some practices (like 7-day UAT) may phase in over 2-3 sprints as we build the rhythm.

The wiki documents everything. We'll do walkthrough sessions with each team. Templates and checklists make it easy to follow. Learn by doing with support.

We iterate. Retrospectives every sprint surface what's working and what's not. If something adds friction without value, we change it. This is v1.0, not the final version.

Raise it in your team's retrospective. If it's cross-team, bring it to Scrum of Scrums or Technical Sync. Good ideas get incorporated.

No. It's about working smarter with clear gates, not adding headcount. The upfront investment in quality (refinement, design ahead, PRDs) reduces rework downstream.

Probably the 7-day UAT regression window and design running one sprint ahead. These add some lead time but significantly reduce escaped defects and last-minute scrambles.

Velocity: Story points completed per sprint. Commitment vs Delivered: Target >85%. Escaped Defects: Should trend down. P0/P1 Frequency: Should trend down. Burndown: Daily progress tracking.

Total story points completed (not just started) per sprint. We track 3-sprint rolling average. Used for capacity planning and release forecasting.

No. Metrics are guides, not goals. Gaming velocity defeats the purpose. Focus on sustainable delivery of value. A stable velocity trend is better than an artificially inflated one.

The ratio of what we committed to in Sprint Planning vs what we actually completed. Target is >85%. It measures planning accuracy.

A bug that reaches production without being caught. We track this to measure quality. The trend should be decreasing over time.

Fewer escaped defects. More predictable delivery (stable velocity). Faster incident response. Higher stakeholder satisfaction. Less firefighting, more planned work.

A daily visualization of remaining work in the sprint. Shows if we're on track, ahead, or behind. Helps identify problems early.

Sprint-level metrics in Sprint Review/Retro. Trend analysis monthly or quarterly. Metrics should inform decisions, not create bureaucracy.