Web platforms
Content updates should not need a deployment
Keep editable content and uploaded files separate from application releases, and give editors a workflow that matches the website.
ExploreHow to plan a useful first release
Choose one complete user task, define its boundaries and make acceptance examples part of the brief.
A smaller release must still finish a task
A first release is not useful just because it has fewer screens. Pick a task that a real person can complete from beginning to end: submit and track a request, place and review an order, or create and share a document.
List the information required, the decision points and the success state. Include who handles the task when the normal path fails.
Write examples before estimating
A normal case
Describe the expected input and the resulting record or action.
An invalid case
Describe what the user sees when a required field is missing or a rule is broken.
An access case
Describe what happens when someone tries to view or change another account's information.
These examples expose ambiguity while it is still inexpensive to resolve.
Keep dependencies visible
Content, payment accounts, external APIs and data imports can determine when a release is usable. Assign an owner to each dependency and record the assumptions behind the estimate.
When scope changes, revisit the order of work. A visible trade-off is healthier than calling every new request part of the original plan.
Review a working slice
Use representative data in a separate environment and ask the reviewer to complete the task. Record what is unclear and which acceptance example it affects.
The outcome of the review should be a decision, not simply a collection of screenshots.
See our delivery process