Add support for story points

[jsobiecki]

I think that nice feature would be support for story points, just like mentioned at http://feedback.gitlab.com/forums/176466-general/suggestions/5784694-add-effort-estimation-in-issues forum thread.

[StephenOTT]

Did you look at the feedback form with my original comment? GitHub Time Tracking supports Budget estimations (can call them story estimations) https://github.com/StephenOTT/GitHub-Time-Tracking#logging-budgets-for-an-issue

:dart: 14h

[StephenOTT]

It should be supported in the GitLab code as well: https://github.com/StephenOTT/GitLab-Time-Tracking#logging-budgets-for-a-milestone

[StephenOTT]

Was also playing with :8ball:

[jsobiecki]

Yes, but hours <> story points :) I played with milestone budget, and I agree - it's very nice feature. But I would like to have possibility to estimate issues using story points, and have possibility to use this metric for a evaluating velocity of team. I also see in code, that logic that allows to set budget (in hours) for issues is not ready / commented out. Any plans to implement it?

[jsobiecki]

:8ball: - I think it's better, than :point_up:

[StephenOTT]

The budget for issues was commented out just for simplicity of implementing the GitLab port. Few modifications and it should work fine.

@harijari Do you see more than 1 person logging points for a issue?

[StephenOTT]

@harijari in the GitHub port i toyed with using Labels/Tags to deal with things like points or any other sort of Hierarchy (issue categorization, prioritization, team and sub-team assignments, etc).

So you would create a Labels/tags called:

• Story Point: 1
• Story Point: 2
• Story Point: 3
• Story Point: 5
• Story Point: 8
• Story Point: 13
• Story Point: 21
• Story Point: 34

Then you apply the story point label and the parser will grab those labels and convert into whatever your numbers were to add them up.

Thoughts?

This model was based on the idea that the story point was a single attribute applied to the issue rather than a bunch of users voting/submitting their thoughts about what the story point should be.

See the issues here: https://github.com/StephenOTT/Test1/issues With the Labels of Priority: Low, Priority: Medium, Priority: High. The Low, Medium, and High would be categorized and you could sort/filter based on issue priority. The original goal was to add layers to tags so you could sort them better rather than deal with situations like this: https://github.com/wet-boew/wet-boew/issues

BUT the same concept can be applied to Story points and we just add an extra layer of analysis for the Story point Tag/label that adds up the points (could even do a simple matrix so you don't need to use points, but you could assign words to have numeric values. So someone would applied Story Point: Low, is given 1 points, and a Med gets 5 points, and a High gets a 12 points, etc)

Here is the label code from GitHub-Time-Tracking: https://github.com/StephenOTT/GitHub-Time-Tracking/blob/master/time_tracker/labels_processor.rb

[StephenOTT]

The other possible downside is that Labels are not archivable. Meaning that if you change your Point system you cannot keep the points that you applied to old issues unless you create new labels for the new point system.

[jsobiecki]

@StephenOTT

Do you see more than 1 person logging points for a issue?

No. It's attribute of issue.

@harijari in the GitHub port i toyed with using Labels/Tags to deal with things like points or any other sort of Hierarchy (issue categorization, prioritization, team and sub-team assignments, etc).

So you would create a Labels/tags called: ...

Hmm, sounds quite nice. My rationale for using approach similar to milestone budgets was, that as I wrote - I'm ruby noob, this pull request is probably first ruby code I ever wrote :). I have seen that similar use case is already solved, and writing different logic (in this case labels) will increase technical difficulty for me, and I wanted to have something working fast.

When I think about this, I like your suggestion. Logic for parsing labels should be easier, and it allows to filter issues using story points in a gitlab UI. I'll try to refactor this code and return with updated PR.

[StephenOTT]

I can take a look at my label processor code as well and look to do a port. Take a look at this comment though as it is a implication of using labels: https://github.com/StephenOTT/GitLab-Time-Tracking/issues/18#issuecomment-168783796

[StephenOTT]

We could add a third key value to this array of hashes: https://github.com/StephenOTT/GitHub-Time-Tracking/blob/master/time_tracker/accepted_labels_categories.rb

Would be like: {:category => "Story Point:", :label => "Low Complexity", :value => 1}

[jsobiecki]

Hmm, I don't know gitlab data model, but what if instead of preparing fixed list of accepted labels, using bit similar approach like for comments.

What I mean by this, it to iterate through all labels of issue, and if one of it matches pattern (something like this: :8ball: 3), store appropriate value on tracking app side. This would be more flexible (some people doesn't use Fibonacci and prefer exponential series for story points), and it wouldn't require creation long list of accepted labels.

[jsobiecki]

I see that gitlab doesn't support emoji in labels, but unicode has plenty of icons, for example: ⬤

[StephenOTT]

Neither does Github. The problem with unicode will be usability. Users will have to know the code or copy it from somewhere. (Sure you could also have a helper function in the app that creates the labels through the API, but i kinda see that as a last resort.

The idea would be as follows:

1. You would use a labels to store Story Points.
2. A user would apply a story point label to an issue.
3. If more than one story point label is applied, only the first story point label in the list will be used. (or all of them could be counted, but may make more sense to only accept the first one)
4. Users would create their labels and assign values however they choose. You do not need to use Fibonacci or any other number system. So the accepted_label_categories would look like:

{:category => "Size:", :label => "Small", :value => 1},
{:category => "Size:", :label => "Medium", :value => 2},
{:category => "Size:", :label => "Large", :value => 3},

Any category, label, and value can be used, as the longer term idea was to store this data in a YML file or directly in the database (so that it would be user configurable within the UI of the application).

The :value would be used as the number that is added up so you can have size assessments of your stories: "How many points are in each milestone", "how many points are allocated to each budget", etc.

Using this would allow someone to use any Category and label name their chose. We can provide recommendations/best practices as to the most use friendly category names and labels, but it would ultimately be the implementor's decision.

The code would run and we create a special function that looks for the defined "Story Point" Category and labels, and it would look for the :value key in the ruby hash and apply the point to issue/snapshot. We would also likely store the category and labels as well for historical reporting purposes.

@harijari, Thoughts?

@harijari What are you thoughts on this issue:

The other possible downside is that Labels are not archivable. Meaning that if you change your Point system you cannot keep the points that you applied to old issues unless you create new labels for the new point system.

With labels not being archivable it means that if you changed your labels in the future, after you had applied them to issues for N amount of time, then you run a fresh download of all your data, your new download would/may not have the correct story point assignments. A work around for this is to never change your labels :smile: or to "archive" your labels if needed.

[jsobiecki]

@harijari What are you thoughts on this issue: The other possible downside is that Labels are not archivable. Meaning that if you change your Point system you cannot keep the points that you applied to old issues unless you create new labels for the new point system.

I think it's edge case and it's safe to skip it now. But if we want to support such edge case, I think that one idea would be to have some sort of migrations, from old "story points" schema to new one. But this one would require update of issues on gitlab side.

About general approach - It looks good for me. My suggestion would be, what if we could use patterns instead of fixed list of labels, it means, instead of:

{:category => "Size:", :label => "Small", :value => 1},
{:category => "Size:", :label => "Medium", :value => 2},
{:category => "Size:", :label => "Large", :value => 3},

give possibility to use interpolated string, something like

{:category => "Size:", :pattern => ":value"},

Where pattern can be normal string, but :value is a special placeholder for numeric value. I see that having values "hidden" behind literal labels is more generic (we can change values of labels, without changing labels on gitlab side), but it would require only one, generic label definition, instead of few / several definitions.

[StephenOTT]

Where pattern can be normal string, but :value is a special placeholder for numeric value. I see that having values "hidden" behind literal labels is more generic (we can change values of labels, without changing labels on gitlab side), but it would require only one, generic label definition, instead of few / several definitions.

can you explain this a bit further?

My thinking was as follows:

1. There would be two levels / 1 grouping level of tags/labels supported. This means that is someone created the following label: Project Management: Monthly Review, the Group would be Program Management, and the label would be Monthly Review. But in GH/GL, the actual label would be Project Management: Monthly Review, as we would parse on the colon : to do the separation. This works well because it is very human readable.
2. Every label gets a colour and has a unique ID. These are logged and determined by GH/GL, and therefore we can store that information in the DB to ensure that we can uniquely identify the label even if the label name in GH/GL changes.
3. The categories and labels are stored in app as a list rather than a pattern so there is no accidental creation of labels that get used by the Time Tracking application. It is a sort of security buffer to ensure that only the labels that the time manager needs to know about are included and parsed.
4. if the accepted label array was:

{:category => "Story Size:", :label => "Small", :value => 1},
{:category => "Story Size:", :label => "Medium", :value => 2},
{:category => "Story Size:", :label => "Large", :value => 3},

or

{:category => "Story Size:", :label => "1", :value => 1},
{:category => "Story Size:", :label => "2", :value => 2},
{:category => "Story Size:", :label => "3", :value => 3},

it would be the same values that would be calculated. While the Category and Label are parsed from the GH/GL label, the value field is only stored in the Time Tracking application. Which means that you can map your numeric values to any words you like.

you could even do:

{:category => "Story Size_old:", :label => "Small", :value => 1},
{:category => "Story Size_old:", :label => "Medium", :value => 2},
{:category => "Story Size_old:", :label => "Large", :value => 3},
{:category => "Story Size:", :label => "Simple", :value => 1},
{:category => "Story Size:", :label => "Typical", :value => 2},
{:category => "Story Size:", :label => "Complex", :value => 4},

or any combination. And note that :value is defined solely in the time tracking application and is not stored in the label in GH/GL.

Now if we wanted to store the value we could using another parser such as:

Story Point: Low: 1 and even just Story Point: 1 Both examples can be supported at the same time.

[jsobiecki]

can you explain this a bit further?

I think we can quit this. My idea was to give end user possibility to use pattern of accepted label instead of list of definitions. But I accept your point "he categories and labels are stored in app as a list rather than a pattern so there is no accidental creation of labels that get used by the Time Tracking application.".

In general, I like your idea :)

[StephenOTT]

@harijari do you have any ideas on how the UI should function for story points?

[jsobiecki]

@StephenOTT Do you mean, how it should be reported in your app?

[gandhiano]

Is there any progress on this? Regarding UI, you may get inspiration from taiga.io, which is focused on agile project development and as such has been built from the ground-up to support the attribution of story points.

[StephenOTT]

Have you looked at ZenHub.com? They have a full suite of tracking tools which includes epics, story points, and time.