Wikimedia Language engineering/Process Overview

Wikimedia Language Engineering - Agile Processes and Tools Used

Team Structure

Management

1. Engineering Director

Product Definition and Prioritization

1. Product Owner

Team Facilitation and Coordination

1. Scrum Master

Development Team

1. UX and Interaction Designers
2. Senior Software Engineers
3. Software Engineers
4. Associate Software Engineers

---

Sprint Duration

1. Each sprint is of 2 Weeks
2. In exceptional cases like travel, the team can opt for a shorter or longer sprint.
3. A shorter sprint is not less than 1 week
4. A longer sprint is not more than 3 weeks
5. The team has opted for breaks to be taken in between sprints, to coincide with the quarterly travel schedules that last between 7-10 days.
6. Sprint change i.e. closing and planning happens on Tuesdays and Wednesdays, respectively of the sprint change week (unless a planned sprint break is to occur).

---

Planning and Development

Product and Release Backlog

1. User requirements brought forward by the Product Owner are included as stories in the Product Backlog
2. The team does not maintain a separate Technical Debt Backlog and technical stories (i.e. independent of any user feature) are also included in the Product Backlog (as they surface)
3. The Release Backlog hasn't been heavily used in the past as the team worked on several products simultaneously
4. Presently, the team identifies a release milestone (e.g. MVP for Content Translation) and uses a Release Backlog exclusively for this release
5. Future Release is used as a catchall release for all stories that are beyond the scope of the Release Backlog

Story Refinement & Estimation

1. Stories from the Release Backlog are refined and prepared for sprint planning
2. Story refinement is done in 2 phases:
   1. Mid-sprint refinement
   2. Sprint Planning
3. The Product Owner prioritises user feature stories from the Release Backlog. These stories are passed on to the development team for technical refinement. The Development team provides estimation of size (Small, Medium, Large, Epic) and hours as days of work for items that can have predictable estimations.
4. The Development team adds any Technical Debt stories that may be seen as necessary for the user feature stories
5. The team presently does not use Estimation Points and is waiting to recalibrate points according to size and hour based efforts.
6. Tasks within the stories (if necessary) are created
7. Depending upon the nature of the story, this exercise may be done in a group or isolated
8. The refined and prepared stories are brought to the Planning meeting for a round of final estimation check and inclusion into the sprint
9. Stories are verified to ensure the following are present:
   1. Unambiguous Acceptance Criteria
   2. Estimated size
   3. Estimated hours days/sprint time-frame for completion of the story (including all tasks)

Story Selection

1. Due to the ongoing point recalibration exercise lack of any estimation points, the team does not have a stable completion velocity.
2. Refined Stories are selected for the sprint based on priority
3. In an attempt to ensure uniformity in efforts, unless absolutely necessary stories are restricted to Medium and Small sizes.
4. Few Large stories are presently being included in the sprint but their number will be further restricted based on observed trend of effort spent and completion status.
5. Bigger stories are marked as top-level tracking tickets and sub-tickets are prepared as per requirements
6. A Development Buffer of refined stories is maintained as a priority set from the backlog

Sprint Closing and Retrospectives

1. Unless otherwise specified, a sprint is completed after 2 weeks.
2. The completed stories are demonstrated during the sprint closing meeting
3. If unfinished stories are to be continued it can have 3 different follow-ups:
   1. it can be time-boxed to finish in the intermediary hours before the next sprint starts
   2. it can be taken to the next sprint. This is common practice for tickets that require us to work with other teams (external or internal to WMF) or deployment tickets that can follow a different timeline
   3. a new card is created from the existing card for inclusion in a subsequent sprint and information of its non-completion/additional work/follow-up ticket is added to the existing card. The existing card is then reviewed and closed.
4. Sprint Retrospective consists of:
   1. action items from the past retrospective
   2. quick review of any important issues on any story (e.g. wrong estimation, unanticipated blockers, diversions etc.)
   3. sprint highlights
   4. suggestions for improvement

---

The following section is not used any more as the team uses Phabricator

[DEPRECATED] STORIES : MINGLE DEFINITION & ASSOCIATED WORKFLOW

A story typically begins in the analysis phase, moves through the development and then the testing / review phases before being showcased to the team / end user and signed off.

A typical story transition is as shown below :

Ready for analysis -> In analysis -> Ready for Development -> In Development -> Ready for Testing -> In Testing -> Review -> Ready for sign off -> Accepted

Some of the important story properties as defined in Mingle are :

1. Status – depicts where in the workflow, the story currently is
2. Owner – the current owner of the story
3. Priority – indicates the importance of the story.
4. Story size –indicates the size of the story as small, medium or large. This property is meant to be used for early stage release planning when the team does not have complete details of all the requirements but do want to size the requirements and plan them. The size is indicative and is relative to the rest of the requirements. The story size can be used to come up with the development plan for the product to be released.
5. Estimated effort(hrs) – captures the estimated effort in hours and is used for sprint planning. The requirements are analyzed and discussed in detail before the sprint commences and hence the team will be able to task out the requirements and estimate them in hours.
6. Actual effort (hrs) – captures the actual effort spent on the story at every stage of the workflow. It is meant to capture the sum total of all efforts spent on a story including development, testing and review. It is the team member’s onus to ensure the effort is cumulatively captured.

ANALYSIS PHASE

Transition : Ready for analysis  -> In analysis

A story is typically created in the 'Ready for analysis' status and is moved to 'In analysis' status prior to the commencement of the sprint. This happens before the refinement sessions when the prioritized list of stories get allocated to the respective story owners who then start analyzing the stories. Refinement sessions are utilized for collaborating with a larger team to analyse, validate and if possible, estimate the requirements.

Mingle Related Transition Details :

The following two properties are prompted during this transition:

1. Priority  : High/medium/low ( Mandatory)

2. Epic story : ( Optional )

The Product owner should indicate the 'Priority' of the story if its not already done. Associating with the relevant 'Epic story' helps map requirements appropriately in the epic-feature-sub feature tree hierarchy.

Transition : In analysis -> Development buffer

Its common practice to have a few stories kept ready in the development buffer so as to ensure the team is engaged effectively when the work allocated is completed ahead of schedule.

Transition-In analysisTODevBuffer.png 67 KB

Mingle related Transition details :

The following four properties are prompted during this transition:

1. Owner : Assign the correct owner relevant to this stage of the workflow. ( Should be the developer for all development stories )
2. Story size : Ideally this should already be captured but if not, system prompts for the size. ( If it’s a newly introduced story )
3. Estimated effort (hrs ) : This is not mandatory at this point but can be captured if the information is handy.
4. Epic story: If you have missed associating it earlier, here is another chance to do so. ( Please note, it has not been mandatory as there will be stories without epics )

DEVELOPMENT PHASE

Transition: In analysis -> Ready for development 
Transition: Development Buffer -> Ready for development

A story can be moved to 'Ready for development' status only if

• Analysis is complete and all the acceptance criteria is clearly defined and agreed to by the team.
• The estimated effort is captured.

Depicts Mingle transition from In analysis to Development Buffer

The following four properties are prompted during this transition:

1. Owner : Assign the correct owner relevant to this stage of the workflow. ( Should be the developer for all development stories )
2. Story size : Ideally this should already be captured but if not, system prompts for the size. ( If it’s a newly introduced story )
3. Estimated effort (hrs ) : This is mandated at this point as the story is deemed ready for development.
4. Epic story: If you have missed associating it earlier, here is another chance to do so. ( Please note, it has not been mandatory as there will be stories without epics )

Transition: Ready for Development -> In Development

Depicts Mingle transition from Ready for Development to In Development

A story once moved to Ready for development can be picked up for development. This transition prompts for owner to ensure the person working on the story is allocated.

POST DEVELOPMENT PHASE

Transition: In Development -> Ready for Testing

Depicts Mingle transition from In Development to Ready for testing

Once the Story development is done and is ready for testing, the story can be moved to Ready for testing and the transition prompts for Actual effort and handover of ownership for testing. Note that the actual effort captures the development effort for the story.

Transition: Ready for testing -> In testing

Transition moves card to in testing phase.

Transition: In testing -> Review

Depicts Mingle Transition from In testing to review

Post testing, when the card is moved to ‘REVIEW’ , the transition prompts for actual effort for testing and handover of ownership for the review phase. Please note the actual effort needs to be added onto as this field will already have the development effort.

Transition: Review -> Ready for sign off

Depicts Mingle Transition from Review to Ready for sign off

Post review, when the card transitions to ‘Ready for sign off’, the transitions prompts for actual effort during the review phase.Please note the actual effort needs to be added onto the existing field as this field will already have the testing effort.

Transition: Ready for sign off -> Accepted

This is the final transition where the story is deemed done and moved to Accepted status.

---