Growth/Team/Task Completion Definition

The Task Completion Definition aims to build a unified understanding of what should be accomplished before a task is considered finished.

It can be applied to different development levels, and those depend on the work cycles of every team. This guide is specifically adapted to the workflow and terminology of the Growth Team and looks at a task/feature completion level once it has been defined on Phabricator

How to use this document

A Task Completion Definition is relevant in two different phases of the development workflow:

1. During task definition: Any item should attach a description of the issue, its acceptance criteria and attach an agreed upon checklist with all the criteria that is relevant for this item.
2. During task review and closure: The checklist that was agreed upon task definition should be used to validate the completion of the item.

To write the Task Completion Definition for a given item, you can follow these steps:

1. Identify the appropriate item level: Are we describing an epic, a feature task or a bug?
2. Identify the correct channel for writing down the Task Completion Definition: This would be a Phabricator epic or ticket tagged under #Growth-Team and, if relevant to Extension:GrowthExperiments, #GrowthExperiments projects.
3. Use the epic/feature task definition template to write a clear and specific Task Completion Definition in the right channel.
4. Use the epic/feature task checklist template to identify which elements should be also considered to validate the completion of the item. Any items that are agreed to be relevant to this epic/feature task should be copied below the Task Completion Definition description.

Epic

An Epic is described by multiple user stories and can involve one or more sub tasks with different Projects. The user story is described from the point of view of the end user/actor/stakeholder. The acceptance criteria for this epic is a list of functional details that are key to the user story.

Epic definition template

Epic: <title> User story: One user story that describes the expected behavior of the system following the format: "As a <user of certain type>, I want to <do this action> so that <the expected result is this one>". Acceptance criteria: Acceptance criteria to add functional details to the user story detailed above, following a format similar to: "Should be able to <understand this format>" Should be able to <handle this kind of function> Should <disallow unregistered users from performing this action> Should <show a comprehensible message to the user when an error arises> Completion checklist: [x] List of non-functional requirements to complete, copied from the epic completion checklist below, negotiated and filtered to only the requirements that are relevant to this milestone [x] E.g. Tests for every involved project should pass [ ] E.g. Must be reviewed and approved by the design/UX team

Epic completion checklist

• Functionality
  • ☑️ Every subtask involved in the user story should have its associated tasks in Phabricator
  • ☑️ Every related task should pass its Task Completion Definition checklist
  • ☑️ Tests for every involved task should pass
  • ☑️ Build process for every involved task should pass
  • ☑️ Coverage for every involved task should have improved or stayed the same
• Design & QA
  • ☑️ Must be reviewed and approved by the design/UX team
  • ☑️ Must be reviewed and approved by Quality Assurance
• Deployment
  • ☑️ Is publicly available in the required environment.
• Documentation
  • ☑️ Must have related and updated documentation
    • Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
    • Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on Extension:GrowthExperiments or Extension:GrowthExperiments/Technical documentation pages.
      

Feature Task

A feature task is described by a Phabricator ticket and is usually a child task or user story from an epic. Every feature task should follow the the agreed upon Growth Team style guide(documentation of this to be done)

Feature Task definition template

Task Title: <title> Description: This could be a user story in the that describes the expected behavior of the system following the format: "As a <user of certain type>, I want to <do this action> so that <the expected result is this one>". It could also be desired functionality whose description may not fit that of a user story format. Acceptance criteria: Acceptance criteria to add functional details to the user story detailed above, following a format similar to: "Should be able to <understand this format>" Should be able to <handle this kind of function> Should <disallow unregistered users from performing this action> Should <show a comprehensible message to the user when an error arises> Completion checklist: [x] List of non-functional requirements to complete, copied from the feature task completion checklist below, negotiated and filtered to only the requirements that are relevant to this milestone [x] E.g. Tests for every involved project should pass [ ] E.g. Must be reviewed and approved by the design/UX team

Feature Task completion checklist

• Functionality
  • ☑️ The patches have been code reviewed and merged
  • ☑️ The task passes its acceptance criteria
• Engineering
  • ☑️ There are existing and passing unit/integration tests
  • ☑️ Tests for every involved patch should pass
  • ☑️ Coverage for every involved project should have improved or stayed the same
• Design & QA
  • ☑️ If the task is UX/Design related: it must be reviewed and approved by the UX/Design team
  • ☑️ Must be reviewed and approved by Quality Assurance.
• Documentation
  • ☑️ Related and updated documentation done where necessary
    • Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc)
    • Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on Extension:GrowthExperiments or Extension:GrowthExperiments/Technical documentation pages.

Bug

A bug is described by a Phabricator Ticket and are to be tagged under "GrowthTeam" and "GrowthExperiments" projects only. All bugs should be filled using this Phabricator Form

Exemptions & Considerations

Not all tasks fit neatly into the descriptions above. Sometimes the external requests to the Growth Team may be a one of request that's not worth the template effort given the life span of the request. The above list should be viewed as a guide that promotes increasing the quality of what we ship out.