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

🎯 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 🎱

[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]

🎱 - I think it's better, than ☝️

[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: #18 (comment)

[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: 🎱 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 😄 or to "archive" your labels if needed.