[teampractices] Setting norms for points field in Phabricator

Fri Feb 19 20:03:30 UTC 2016

Le 18/02/2016 20:05, Joel Aufrecht 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?

I would not differentiate between an organization engineer and a
community member.  Sounds to me setting the point is the responsibility
of the product owner based on exchanges happening with other. A point
should reflect a discussion reassessing the scoring.

When someone change points without explanations, I would ask what is the
justification behind and revert if none given.

> 2) What should we do about making points consistent across teams?

That sounds too cathedral to me.  It is unrealistic to attempt to
normalize point value which is just an abstraction of a unit of work to
be done.  That will vary among teams, the season, mood and feeling. Some
people might want points in exponential values 1 2 4 8 16 32 others
something that is more or less hours/days of work. I can imagine people
giving 1 point to any task they will accomplish over a week and 0 if
not/best effort.

<wild mode="crazy">
If we were to normalize, we would end up with a director of point
evaluation with a team of bureaucrat writing down policies about point
scoring among the organization.  A band of men in black would be
creating scoreboards to track unappropriate usage of the point system™
and people get fired for misuse.
</wild>

What about not having tasks shared by multiple teams in the first place?
This way each team has the liberty of action they want and the problem
disappear.

Setting the point value between teams is no different from setting the
assignee or the priority.  As an example if I want to create a new
website for yesterday, I will get the task assigned to me with X points
and a high priority.   Now to accomplish that task I would need help
from the operations team to setup the server.   The best way to handle
it *imho* is to create a subtask, flag it for the operations team and
let them deal with the point scoring / priority / assignee.

I have been working in a customer service and I often had a task for the
actual 1/1 with the customer with child tasks sent to various different
teams to get the matter solved.  In turn, they will fill child tasks as
needed.  That would look like:

 Task 1: customer Acme Inc lost its internet connection
   Task 1.1: [ops] can you check port 23 on system B
     Task 1.1.1: [field] send hands to Datacenter to plug back cable 3
   Task 1.2: [sales] calculate compensation for outage
   Task 1.3: [monitoring] alarm did not trigger

Each having different teams, priorities, escalation process, points,
assignee etc...

> 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.

"Policy" might be too strong of a word.  Maybe a guideline explaining
the reason points are set (people agreed on it) and recommendation about
suggesting a scoring change (lets talk!).

> 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.

That sounds reasonable.  Maybe we can come up with a 101 class / how to
score cards book that will cover all the above?

Disclaimer: I don't score anything :D

-- 
Antoine "hashar" Musso