[teampractices] Setting norms for points field in Phabricator

[James Forrester]

This is mostly an issue for tasks that sit in multiple teams' boxes. For VE
I've 'til-now set these to 0 if externally blocked (e.g.
https://phabricator.wikimedia.org/T119780 ), but that only works if the
other team(s) involved don't want to set points themselves.

When points were only available to the few teams using the Sprint extension
this was no-one, to a first approximation (off the top of my head, two
tasks have had clashes like this in the past year, and no-one cared enough
to enforce their way over others). Now all projects have it, it's much more
likely to be a thing.

J.

On 18 February 2016 at 11:40, Max Binder <mbinder at wikimedia.org> wrote:

> What should we do about making points consistent across teams?
>
>
> To clarify, do you mean teams using the same points to mean the same
> thing? Currently, I suspect teams use points to mean different things (Team
> A says 5 points is "a day's work" while Team B says 5 points is "two day's
> work" while Team C says 5 points is not time but complexity, etc).
>
> On Thu, Feb 18, 2016 at 11:05 AM, Joel Aufrecht <jaufrecht at wikimedia.org>
> wrote:
>
>> The points field is now global to all tasks, raising some interesting
>> questions:
>>
>> 1) What do engineers/product owners (staff or otherwise) working on tasks
>> do when community members set or change points?
>>
>> 2) What should we do about making points consistent across teams?
>>
>> My initial thoughts/proposal, which we could run past teams we are
>> working with and engaged community members:
>>
>> 1) we should have a written policy along the lines that points is
>> intended to be used by people doing the engineering work on tasks, and that
>> therefore only those people (staff on teams working on tasks; community
>> members contributing code/testing/other engineering work) should edit
>> points.
>>
>> 2) We should explictly document that points cannot be compared across
>> teams, that there is no single standard definition or meaning for points,
>> and that they cannot be used in isolation to forecast.  In an analogy, I
>> see points as a bit like database ID fields; even if they are exposed, you
>> can't use them for certain things you may be tempted to use them for,
>> because they are warranteed for that use; instead, you should use the
>> appropriate derivation for your purpose.
>>
>> Thoughts?
>>
>>
>>
>> *--Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>


-- 
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforrester at wikimedia.org | @jdforrester
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160218/fdfc03c9/attachment-0001.html>