Readers/Web/Team/Story estimation

This page provides guidelines and examples to provide some background on how the reading web team estimates.

We currently use the Fibonacci sequence for points

Tooling

The web team has found the following tools are useful for virtual estimation:

• https://hatjitsu.toolforge.org/
• https://hatjitsu.wheresalice.info/

Examples of pointed tasks

For reference, here's a table with examples of previously pointed cards to be used as a reference in future estimations.

8 (extra large)

Typically 5 days continuous work

• Event logging: Update event logging used for Hovercards

5 (large)

Typically 2 - 3 days continuous work

• Feature: Create Special:Citations fallback for non-JavaScript/Resourceloader unsupported users

3 (medium)

Typically 1.5 to 2 days continuous work

• Tech debt + Upstream: MobileFrontend should use upstreamed mediawiki.router
• UI bug: Search overlay drops 1px when you type into input (note: this was an unusually involved fix and not a good example; please replace)
• Feature change: References sections should always be collapsed
• Deployment preparation: Prepare HoverCards for A/B test on smaller wikipedia project

2 (small)

Typically 1 day continuous work

Regression: Call to undefined method DOMDocument::setAttribute( in MobileFormatter.php on line 239)

• Security review: Security review of Hovercards before beta->default conversion

1 (very small)

Typically 0.5 days continuous work

• Config variable change (deployment) with SWAT: Increase ON percentage for Hovercards A/B test 1
• CSS bug: Rename watchlist icon in main menu to not collide with OOJS

.5 (trivial)

• Rarely used. If the conversation in estimation is taking too long and someone can write the patch in the time it takes to have the conversation it might be a 0.5 pointer, but work is rarely that easy. It can also be used for tasks such as correcting a spelling mistake or updating a wiki page, however we usually avoid creating tasks in this situation and just write the patch.

0 Spikes

Spikes will have the tag #spike and in the title will express a finite window of time during which the task will be worked on. We point these as 0 to note that these have been discussed and agreed upon by the team during an estimation meeting.

The benefit of using points rather than updating the title is that point changes are logged and it is easy to identify any comments made at the time of estimation/discussion.

Estimating tasks in progress

If the team is estimating a task that is currently in progress or has had previous work completed, the expectation will be that the work for the entire task will be estimated (as opposed to only the remaining parts of the work)

Deprecated info

Pokerbot Usage

In August, 2018, we began experimenting with poker bot as a tool for async estimation. Below are some of our conclusions from these experiments:

• Pokerbot does not replace actual estimation - tasks that are estimated using pokerbot should also be discussed by the team as a whole in a grooming meeting or standup
• Pokerbot is useful for getting an idea of a task prior to a meeting
• Pokerbot is particularly useful for discussing tasks during times of the week where there are fewer grooming sessions. For example, to discuss more urgent tasks on a Thursday rather than waiting until the following Tuesday.