Page MenuHomePhabricator

Define and implement time estimations using points
Closed, ResolvedPublic0.5 Estimated Story Points

Description

From experience of phabricator use for project management [Discovery Team

Story Points[edit]
The Analysis and Portal teams have started estimating stories using points; the Portal team uses the following estimation guidelines:

1 is ultra small. e.g: changing a color, a button size, limited to a few lines of code that are ok to be changed. Very rare actually.
2 is small: good, but in practice still hard to be this fast (latency due to code reviews cycle, testing cycle, merging...)
3 is a SMALL change.
5 is a MEDIUM change. It is a good compromise between fast developers (estimating 3) and less comfortable ones (estimating 8). It is a MEDIUM change that is *quick* to make, or a SMALL change that is *slow* to make.
8 is a BIG change. It should be a pretty big feature already.
13 is a bit big. It's always better to break it down, but sometimes it doesn't make sense. At least we know this is big and should be every one's concern.
20 is too big. We also had 40 and 100. if you get there, you have a problem.
The Analysis team uses the following estimation guidelines:

1 is about half a day's work
2 is about a full day's work
and so on…

Event Timeline

When we set up Tasks for a batch upload, a focus was on transfering knowledge about the details of a batch upload from @Lokal_Profil to me. That purpose was well met in my eyes. However, the result is that a large portion of the tasks are on a less-than-10-minutes-to-complete level which might not be optimal for time estimation of the overall project.

Can higher-level tasks be identified that are at least on the level of half-a-days work and become the basis for project management use of phabricator rather than phabricator-as-a-tutorial?

Jopparn set the point value for this task to 0.5.

This is resolved (for COH) by the WMSE wide implementation of 1pt = 1h