Software Development

Purpose

The Witboost software development workflow turns validated product opportunities into secure, documented, tested, and releasable software. It aligns product, design, engineering, quality assurance, security, and release responsibilities while keeping customer value and technical sustainability visible.

This page explains the end-to-end software workflow. For cadence, prioritization, roles, and meetings, see the Product Delivery Process.

Workflow at a Glance

1. Discovery defines the problem, target users, desired outcome, product scope, and acceptance criteria.
2. Product design explores user flows, wireframes, prototypes, and usability evidence.
3. Technical refinement produces an HLD, a milestone plan, risks, dependencies, and milestone estimates for release planning.
4. Milestone preparation produces an LLD and reviewed Stories for each selected milestone.
5. Delivery implements small, reviewable Stories with tests, documentation, configuration, and peer review.
6. Feature QA validates the complete behavior and records defects.
7. Feature readiness completes configuration, migration, documentation, and operational work.
8. Product release packages, validates, documents, and communicates a stable product version.

Delivery Structure

Witboost delivery follows this hierarchy:

Feature → Delivery Slice → Milestone → Stories and Tasks

• A Feature is a long-lived product outcome that may span multiple releases.
• A Delivery Slice is a releasable portion of a Feature, represented by one delivery-level record in the work-tracking system.
• A Milestone is an independently valuable, estimable, and deferrable part of a Delivery Slice.
• Stories and Tasks describe the implementation work required to complete a Milestone.

This structure keeps product intent stable while allowing lower-priority Milestones to move between releases when capacity, evidence, or risk changes.

1. Discovery

The Product Owner and Delivery Lead coordinate discovery with the Product Designer, relevant Product Area Leads, and specialists.

Discovery establishes:

• the problem or opportunity and affected users;
• the desired outcome and useful success signals;
• the intended product behavior and acceptance criteria;
• explicit non-goals and constraints;
• initial delivery-slice hypotheses;
• open product, design, technical, security, and operational questions.

The product record remains current as evidence and scope decisions evolve. Discovery should make the work clear enough to shape, not attempt to solve every implementation detail.

2. Product Design and Prototyping

Product design starts during discovery and continues through delivery and QA. See Product Design for the broader design principles.

Depending on the change, design activities may include:

1. User-flow exploration to understand how people accomplish the target outcome.
2. Wireframes or early prototypes to compare alternatives and expose missing requirements.
3. Cross-functional review with product, engineering, quality assurance, and customer-facing stakeholders.
4. Interactive prototypes where usability, interaction, or workflow risk justifies them.
5. User testing and iteration to validate assumptions and refine the experience.
6. Implementation support and design QA to resolve details and verify the delivered behavior.

Design work is proportionate to risk. A small local change may need only a reviewed flow or mock-up; a new or complex experience may require several prototype and testing iterations.

3. Technical Refinement

The Feature Owner coordinates technical refinement with developers, the Product Designer, Product Area Leads, and relevant quality or security specialists.

Technical refinement produces three planning outputs:

• a High-Level Design (HLD);
• a Milestone plan;
• an effort estimate in person-days for each Milestone.

Estimates include implementation, review, testing, documentation, configuration, migration, and other required collateral work. Their only purpose is to support release planning; they are not delivery-date commitments.

High-Level Design

The HLD turns the discovery outcome into a credible solution approach. It describes:

• system boundaries and responsibilities;
• major interactions and contracts;
• dependencies and constraints;
• security, compatibility, performance, and operational risks;
• the rationale for the proposed Milestone split;
• open questions that affect feasibility or estimation.

HLD refinement remains lightweight and bounded. If a credible design and Milestone plan cannot be produced without disproportionate analysis, the team splits or defers the slice rather than extending refinement indefinitely.

The Product Owner and Delivery Lead review the HLD before release planning to confirm that the solution still supports the desired outcome, the Milestones are meaningful, and the capacity assumptions are useful for prioritization.

Technical Investigations

A technical investigation is a narrow, time-boxed activity used when evidence is needed for a design or planning decision. It starts with a specific question and expected output, such as a recommendation, compatibility result, prototype finding, or estimate range.

Investigation code is disposable unless it is deliberately converted into planned delivery work and brought up to normal engineering standards.

4. Milestone Design and Story Preparation

Detailed design happens for selected Milestones during delivery preparation, close to the repositories and systems being changed.

Low-Level Design

A Milestone LLD describes the implementation boundaries without becoming a step-by-step coding plan. Depending on the work, it covers:

• repository or component responsibilities;
• interfaces, data contracts, and integration behavior;
• sequencing and dependencies;
• configuration and migration expectations;
• security and failure handling;
• test and verification expectations;
• design details needed for implementation.

Exact file changes, class or function structures, algorithms, and test implementation remain developer decisions made during implementation.

Story Preparation

The Milestone LLD is used to draft Stories. Each Story should contain:

• a clear delivery purpose and bounded scope;
• acceptance signals;
• relevant dependencies and constraints;
• links to the Delivery Slice and design context;
• testing, documentation, configuration, or migration expectations when applicable.

The Feature Owner reviews proposed Stories before they enter delivery. Generated or suggested work items are never published blindly.

5. Implementation

Developers select ready Stories during sprint planning and choose an implementation workflow proportionate to the change.

• Complex or ambiguous work benefits from a structured implementation specification, plan, and task breakdown.
• Well-scoped work may be implemented directly when the Story and linked design already make the path clear.
• Small localized changes should avoid unnecessary ceremony while still meeting normal review and quality controls.

Multiple related Stories may share one implementation specification and one merge request when they form a coherent, small, and reviewable change. The specification and merge request identify every included Story. Work is split before the merge request becomes large or serves unrelated purposes.

During implementation, developers:

1. confirm the Story and design context;
2. define the repository-level implementation approach;
3. implement code, tests, configuration, and documentation together;
4. keep the work-tracking status current;
5. raise blockers, estimate changes, or scope drift immediately;
6. open a merge request with enough context for effective review.

6. Review, Integration, and Definition of Done

Every merge request receives appropriate peer review and follows the owning repository's Definition of Done. The Feature Owner or relevant technical owner confirms consistency with the Milestone design.

Depending on the change, completion includes:

• unit, integration, system, performance, or security tests;
• review of interfaces, data behavior, and backward compatibility;
• configuration and environment updates;
• migration and upgrade guidance;
• user-facing and operational documentation;
• design review for user-interface changes;
• targeted quality assurance for affected behavior.

Changes are integrated through automated build and test pipelines. The default branch remains releasable, and integrated artifacts are made available in development environments for broader verification.

A Story is not complete merely because code has been written or merged. Its applicable tests, documentation, configuration, review, and acceptance expectations must also be complete.

7. Feature Quality Assurance

Feature QA validates the behavior of the complete Delivery Slice rather than only individual code changes. See Quality Assurance for the wider test strategy.

The QA handoff includes:

1. a release candidate deployed to a representative test environment;
2. test scenarios derived from acceptance criteria, risks, and real user flows;
3. functional, integration, regression, usability, and accessibility checks as applicable;
4. traceable defect reports with severity, reproduction evidence, affected behavior, and version;
5. retesting after fixes.

Critical and high-severity defects block release. A lower-severity defect also blocks a Delivery Slice when it prevents an acceptance criterion or essential user flow. Other defects are explicitly prioritized or deferred; they are not silently ignored.

The Product Designer performs design QA for applicable changes, and security specialists validate security-sensitive behavior.

8. Feature Readiness

Before a Delivery Slice can enter a stable release:

• all repository-level Definitions of Done and merge-request checks are complete;
• acceptance criteria have been validated;
• no release-blocking defects remain;
• automated regression coverage is updated where appropriate;
• customer-facing documentation is current;
• configuration, installation, migration, and compatibility guidance is complete;
• operational and support impacts are understood;
• material scope changes are reflected in the relevant product and delivery records;
• the Feature Owner signs off.

For changes that affect shared or demonstration environments, the team also updates the relevant provisioning, configuration, and validation material.

9. Product Release

Product release turns the validated release candidate into a supported product version. See Release Management for versioning, upgrades, and support windows.

Release activities include:

• final regression and security validation;
• publishing versioned software artifacts and deployment packages;
• updating environment configurations;
• producing release notes and change histories;
• documenting migration steps and compatibility information;
• updating product and administrator documentation;
• demonstrating material changes to interested stakeholders;
• communicating availability and required customer actions.

Critical corrections and security fixes may follow a controlled patch path rather than waiting for the next regular release. Patch work follows the same review, testing, documentation, and compatibility expectations appropriate to its risk.

Rescoping During Delivery

Requirements, dependencies, risks, and evidence can change after work starts. When that happens:

1. Any team member raises the issue immediately.
2. The Feature Owner prepares feasible options, such as simplifying a flow, splitting a Milestone, or deferring lower-priority behavior.
3. The Product Owner and Delivery Lead decide what remains in the release, with input from design, quality assurance, security, and other specialists when relevant.
4. The affected design, Stories, acceptance criteria, and release records are updated.
5. Developers stop or re-plan work that no longer belongs to the committed scope.

Deferred work remains visible for future prioritization. Scope is reduced before security or quality controls are weakened.

AI-Assisted Development

AI-assisted tools may help draft designs, Stories, implementation plans, tests, and code. Their output is never authoritative.

• The Feature Owner owns the correctness of technical designs and generated delivery items.
• Developers own the code and tests they deliver.
• Architectural, dependency, security, and performance assumptions are verified against trusted sources and executable evidence.
• Generated work follows the same review, testing, security, documentation, and release controls as manually created work.
• Sensitive or restricted information is supplied only to tools approved for that information.