# Beta ### Purpose Beta is where the preferred alpha approach is built and tested with real users. The goal is to develop a usable, secure and supportable service or product and prepare it for live operation. ### When to Use This Phase Use beta when alpha evidence supports a preferred solution and the customer is ready to build, test and release usable increments with real users. ### Primary Decision At the end of this phase, we should be able to answer: > Is the service good enough, safe enough and operationally ready enough to move into live use? ### Core Questions * What is the minimum viable service? * Which users will access private beta? * When can public or wider beta begin? * What must be tested before live? * What support model is needed? * What metrics will show performance? * What security and data evidence is required? * What defects or risks block live release? ### Key Activities * production-grade build * private beta release * public or wider beta release where appropriate * user research with real users * accessibility testing * integration testing * security testing * performance testing * service support design * operational readiness planning * release planning * defect management * documentation ### Expected Outputs * working service or product * release notes * tested user journeys * support model * operational documentation * security evidence * performance evidence * accessibility evidence * service metrics * live readiness assessment * updated roadmap ### Entry Criteria * alpha recommendation approved * beta Statement of Work agreed * backlog prioritised * team mobilised * environments available or planned * security approach agreed * acceptance model agreed ### Exit Criteria * service works for intended users * critical user journeys are tested * security and assurance requirements are met or risk-accepted * support model is ready * monitoring is in place * performance is acceptable * live release decision is recorded ### Evidence to Capture * completed backlog items * test evidence * user research findings * defect log * accessibility report * security review * deployment records * monitoring evidence * support readiness checklist * live readiness report * acceptance certificates ### Commercial and Statement of Work Considerations * tie milestones to evidence and accepted deliverables * use change control for material scope changes * track customer dependencies that affect delivery * maintain payment evidence * ensure supplier deliverables support acceptance ### IP and Accelerator Considerations * separate reusable components from customer-specific outputs where possible * confirm ownership and licence of any foreground IP * record open-source components * avoid embedding restricted customer material into reusable assets * update accelerator library only after IP review ### Security, Data and Assurance Considerations * apply secure development practices * manage secrets properly * run vulnerability checks * confirm access controls * test data handling * prepare security evidence * confirm incident and support routes before live ### Common Risks * beta treated as a full uncontrolled build * private beta feedback ignored * operational support designed too late * security evidence delayed * performance issues discovered at live gate * scope expands without change control * supplier tasks not integrated into release plan ### Practical Checklist * Confirm beta scope and acceptance criteria * Set up environments and repositories * Build and test increments * Run private beta with selected users * Capture and prioritise feedback * Run security, accessibility and performance checks * Prepare support model * Prepare live readiness evidence * Run beta exit review * Record live decision --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/agile-delivery-playbook/delivery-phases/beta.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.