Agile

Engineering teams at WMF are "agile", frequently delivering improved features. The default cadence for core MediaWiki and deployed extensions is all code merged to master in Git is deployed every week.

Some teams adopt "big A" Agile software development, formalizing this into engineers working on "stories" (user-facing features) in planned 1-3 week "sprints". They use Phabricator to plan the work. (Some teams have yet to migrate to Phabricator from Mingle, Trello and other project management tools.

Category:Wikimedia Foundation teams internals gives some insight into teams' approaches.

Terminology glossary
There is shared terminology (no more arcane than w:WP:TLA :-) ).
 * http://www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms

TODO our own terminology table
 * Iteration
 * another term for a sprint


 * MVP
 * Minimum viable product - has just those features that allow the product to be deployed, and no more.
 * Tag - a cross-component keyword (like "accessibility"). Tags must be proposed and discussed before being created. Icon+Color: Tag+Yellow
 * Component - a distinct and recognizable piece of software/service.
 * Team - an existing team - creation must be documented. Team projects can be automatically added to (sub)component tasks by requesting a global Herald rule. Icon+Color: Team+Violet.
 * Projects and subproject types (from Phabricator/Creating_and_renaming_projects
 * Sprint - a subproject of a team being worked on in a certain timeframe. Specify the start and end dates when requesting creation of a new Sprint project. Icon+Color: Deadline+Green.
 * Release - subprojects that belong to a specific deployment defined by a date or a (future) software version. Icon+Color: Release+Orange.
 * Goal - projects without a defined ending date but which can be definitely realistically be defined as finished at some point. Creation must be documented. Icon+Color: Goal+Orange.
 * Private / ACL projects enforce policy restrictions to not unnecessarily restricted Team project membership and to allow any people to join and watch such Team projects. Creation must be proposed and discussed before being created. See T90491. Icon+Color: Policy+Red.
 * Personal per-user projects - track progress of personal tasks. They currently are a test only, see T555. Creation must be documented. Icon+Color: Accounting+Checkered.
 * Umbrella projects - larger projects that do not have a distinct code base and that consist of several (sub)components. Umbrella projects can be automatically added to (sub)component tasks by requesting a global Herald rule. Creation must be documented. Icon+Color: Umbrella+Blue.
 * Patch-To-Review - a project automatically added to a task when a related patch in Gerrit links to that task.