Describe what issue people are facing, or what area is problematic.
If the below are under discussion or open to alternatives, note it here.
- a list of steps
- describing how the feature will behave
- assumes "happy path" case with no errors
- are there multiple routes to the new functionality? (helps testers to know)
- anything known about precise specifications to be met
- e.g. file sizes, types, dimensions, units, currency values, rounding
- any known business logic to apply, e.g. "derive Total Budget with formula x / z..."
- a list of error message text that may be shown to the user
- how fast should a page load or a UI element respond?
- how fast is the functionality available to be used, once the page loads?
- how quickly is the data expected to grow, per Campaign or per User
- how quickly should the server respond to requests?
- what's the timeout if a downstream service is unavailable?
- are any feature flags required?
- is a new permission required?
- does this affect the Zefr approvals process?
- may this feature be exposed both to external and internal users?
- is this feature restricted to certain Roles or users?
- if so, list the Roles here
- do users need notification before this is deployed?
Does behavior vary based on Campaign Launch State? Fill out the following list, including one entry for each possible Action in this story. This should kept in long-term documentation in our CM Statuses spreadsheet.
- Action (usually one of Create/Update/Delete/Duplicate)
- Draft - Allowed or Disallowed?
- Running - (if Disallowed, include a reason to be used as an error message)
- Retired
- Next Action
- Draft - Disallowed
- Running - etc.
- Retired
The above only shows Generic Launch States. We have more fine-grained states for internal campaign approvals, and intermediate states while awaiting work by CO or CA.
Most of the following should be
- filled in by developers, based on above Acceptance Criteria
- Used to created sub-tasks, as needed. Sub-tasks may contain further technical details (e.g. about database requirements)
- Be amended / updated by Product, as needed
Is a new API endpoint required?
- what will the new API path(s) be?
- follow our REST conventions for CRUD endpoints
- is this primarily for our frontend?
- if so, coordinate with them on flattening the response, sending ids, and sort order of data
- call out failure conditions may be encountered
- call out any negative cases or specific disallowed inputs, as needed
Are you modifying an existing API endpoint?
- Is this a breaking change?
- If so, we need a new /vX endpoint to preserved backward compatibility?
- If not, we may be able to add it. Confirm with other clients that may be using this endpoint.
- Is this a breaking change, but only used by our front end?
- coordinate with the front end devs to see if a new API version is desired, or if we want to coordinate deploys
Other things to flag, usually in the PR:
- are any migrations required?
- do new permissions need to be set up in Accts?
- did we update any Python packages?
- are there config values that must be propagated?
- are they added to defaults.cfg, for reference
- do all developers know to include them in their own dev.cfg?
- are deployment configs updated (Jenkins / Docker)?
- are there any secrets that need to distributed?
If this is a major new area of functionality, describe how the feature "flow" is expected to go.
- make sure error conditions are handled
- indicate if a new page/URL will be created for this feature
Other things to flag:
- are there any NPM private packages being updated?
- any NPM packages that need to be updated?
- global components being updated
Include a link or attachment for our mock.
Make sure the following information is conveyed:
- if the mock is not yet ready, when will it be added? (possibly notify the Slack channel too)
- if the mock is still in progress? expected finalization?
- is the design finalized? Or shall devs clean it up using established style guide?
- where should error messages be shown? (or call out that standard toast notifications are used)
- are any field length issues called out? (e.g. really long strings or text)
- are any item count issues called out? (e.g. we may have to show 15 of a thing in this space)
- are there any currency fields that need to be localized?
- any time or date fields to be localized?
- Will unit testing suffice?
- Will testers need an additional ticket to add further unit tests?
- Do we need integration tests? (e.g. hit other running services)
- Do we need to add steps for our automated test suite?
- Do we need to tag HTML elements with test hooks or ids?
- Does anything need manual browser testing?
- Are there any permission or Organization-related test cases?
- Do we need to coordinate work with other teams?
- which team?
- Campaign Optimizer (launching, mid-campaign updates)
- Campaign Analytics (reconciliation, stats)
- Avails
- who is the main point of contact?
- are there any tickets tracking their work?
- should they be invited to any planning meetings? additional meetings?
- do they need anything from us in order to begin their work?
- do they need to change anything in their code based on our work?
- which team?
- Do we need to use any Zefr services?
- which service? Accts, ZPAPI, Elasticsearch, Kafka...
- do we need new API keys or secrets?
- are there any rate limits we should be concerned about?
- will service latency, uptime, or performance affect us?
- should we add any notifications if the service goes down?
- who is the point of contact during development? for long term support?
- Do we need to use any external services?
- which service? AdWords, YouTube Data API, Apigee, S3...
- do we need new API keys or secrets?
- are there any rate limits we should be concerned about?
- will service latency, uptime, or performance affect us?
- should we add any notifications if the service goes down?