Hi Sander,
[...]
> *Labels*
> This area is the one I have the most feedback on. The terminology of
> Severity and Priority has been a discussion topic from me on multiple
> occasions. I think we need to be careful to properly keep them apart. In
> the abstract, a issue which is very severe may not get the highest
> priority. This might be e.g. because the issue is very hard to reproduce.
> Cooking up an example, suppose we had a bug where bst gets confused about
> the state of workspaces. And the only way to recover is to close all
> workspaces and start over. And this happened once, with no reproduction
> recipe. I would call that very severe, but low/no priority.
I share your experience about that debate.
:)
My intention is to reserve the concept "Priority" for the roadmap only, not
for engineering tasks, bugs, etc. When dealing with non paid contributors,
priority might be perceived as "this is what we want you to work on". In my
experience, this meaning is taken in a different way (less directive) when it
is related with roadmap than with tasks/bugs.
Combining severity, impact and status with the roadmap priorities, it should
be fairly simple to imply a sense of priority in tasks/bugs in the upstream
project. If this is not enough, we can always create a priority scale.
I am aware this approach is not perfect. I explain later why. I am not
entirely happy with choosing the word severity. In multicultural environments,
as many of the you know, the concept of severity might have slightly different
meanings. This is just an example of why a policy document is needed to
clarify the scales and values assigned, even in the most obvious cases.
[...]
> I find it interesting that the first definition talks about priority, not
> severity.
That was my bad. My initial intention was to have the roadmap user stories in
the same repo than the technical tasks. I changed my mine after evaluating how
the enhancement tickets are currently being used. I will send a proposal about
how to manage the roadmap.
As mentioned before, I would like to reserve the concept of priority to
roadmap discussions.
Thanks for clarifying. Let's clean up the terminology and move on.
> > Important: default severity for processed items that should be
>
> executed/considered.
>
> Do we call the default Important, because if it wasn't important it
> shouldn't be worked on?
>
> > Urgent: to pay attention in the immediate future when possible.
>
> Again, this reads more like priority than severity.
>
> > Critical: topics that require attention immediately when possible. This
>
> label already exists.
>
> Same.
>
> Actual severity seems to be captured by a label not in the proposal,
> High_Impact?
The above is exactly the kind of debate I did not want to get into. I hoped
that by leaving the definitions open enough, most people would feel
comfortable. Then, by using them, we could tune the definitions. Here is why...
I aim to please?
The issues we are creating in gitlab are, at least of the following kind:
* Defects
* work packages (tasks)
* user stories
* epics (big tasks that can be sliced)
* requests (services, goods...)
* others (combinations of the above, different ones...)
Formally speaking, Each one of the above fall into different categories when
it comes to classify them, with different scales and values.
When we are talking about incidents management, priority comes as a
intersection (matrix) of the concepts Urgency and Impact.
When applied to risk management the impact concept changes and, depending on
the type of risk management we are talking about (acquisition, operational,
assessment...) , you will find different applications and scales for severity
and impact.
When talking about software quality, it is interesting the concept of defect
criticality. The class of defect depends (formally) on two scales: Severity/
Impact and Likelihood/Visibility We were using the label Critical in this
context. I tried to avoid it at first, and introduced the impact scale later.
When talking about user stories, we can classify them by MoSCoW, paired
comparison, Kano Analysis, a variety of points systems...based on the business
value which can be directly related with impact, severity or/and priority
depending on the circumstances and methodology approach.
My point here is that due to the wide variety of types of issues we are
dealing with, it is arguable which scales to use for what and which values to
apply.
I would be more than happy if we can consolidate three scales with 3 to 4
levels each in a future. Even in such case, the type of issues currently being
are too wide to find out the right scale to categorize each one of them.
I will try to improve the current situation by:
* Rewriting the description of each severity level, looking for a better
differentiation of a priority concept.
* I deliverable added the word impact to the only label we have for the Impact
scale to avoid misunderstanding. I will rewrite the scale definition and label
description to be more accurate.
Thanks.
In any case, I would like to avoid being strict.
In my experience, when scales
become a topic, it means that the project is demanding a significant increase
of structure, in which case we are talking about the need for a project
manager.
I think there is some grey area there.
> *Boards*
> I can see those be useful for transparency/visibility. Is there a way to
> monitor how often these are actually used?
Not that I can think of on Gitlab. I am using them already on every meeting
for both, preparing it and to follow it up.
@All. I would appreciate if in a few weeks you tell me if you are using them
and what for.
Once we have a solid roadmap, we can translate user stories into weekly tasks
which, together with the boards, would provide us forecasting capabilities,
based on previous records.
So WIP visibility is the first step towards forecasting completion times in
controlled environments, which Open Source projects are usually not.
[...]
>
>
> Thanks for putting the proposal together, and for volunteering to maintain
> this data.
My pleasure. I am getting good help from Laurence.
@All Thank you all for dedicating effort to keep the tickets healthy, so using
the boards is possible (and useful).
I hope the above explanations does not sound too presumptuous but I consider
myself a veteran in PMO vs engineering/R&D/product battles. I try to avoid
getting into them unless absolutely required.
:)
Cheers,
Sander
Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy. See https://www.codethink.co.uk/privacy.html
