Generalize issue weights
Description
- Currently we have issue weights.
- Not every team finds the weights useful because it is just a linear set of numbers.
- Generalize the concept so that users can do some sort of customization on them. For example, re-labeling the weights to "small", "medium", "large", or a Fibonacci sequence.
- Under the hood, we should keep the same set of values to keep the product simple and easily maintainable.
Original description
It would be awesome to add a story-points field to issues, and show a count of story-points per project and milestone (done/not-done/total), this shouldn't be too difficult to implement and would go a good way towards doing away with extra tools such as Redmine instead using gitlab for project management.
-
Add story-point (unsigned integer) to issues
-
Show total points per project and per milestone
-
Show done points per project and per milestone
-
Show todo (not done) points per project and per milestone
Activity
Hi @AlexisFinn, this concept already exists in the Enterprise Edition product, it is known as Issue Weight.
You can see the an example of total weight per milestone on the next GitLab-CE release milestone.
Hum, ok, this should do fine (although traditionally story-points range is more than 1-9, but its arbitrary anyway ). But whereas it says you can get a total weight per milestone, can you get a total per projects ? And can you get a total remaining and a total done ? If so then i'll be really looking forward to this in the CE edition, it would be an incentive to do-away with Redmine (One less tool yeah !)
IMHO, story points and issue weight are totally different. We use both these terms (not in a Gitlab environment) - the former indicates the effort required for an issue and the latter indicates the order by which the issue to be worked. Issue weight is something like priority, but priority is more related to business people, and issue weight is used by developers and testers.
We are migrating from our legacy mantis+websvn environment to Gitlab and it would be extremely helpful if we have this feature in Gitlab. Currently we use Google Sheet for sprint planning.
It would be nice to have story points in issues, so that we can do size estimation easily and calculate sprint velocity or do a burn down chart.
Another option is to have a custom field for story point, so that a more generic implementation is possible.
I agree with @manilal it's totally different to Issue Weight. Please reconsider to add Story Points to issues it would help a lot. Cause the Weight is more like the value of an issue for the customer. Story points indicate how much time it needs to implement it. Maybe it would be useful to make it possible to switch an option for a repository to change the time tracking feature to story points tracking?
Nice too see this reopened, I do hope it get's implemented as this would be a huge step into integrating project management directly into gitlab.
@mrgrauel I disagree, time tracking and story points tracking can both be used at the same time, as they have different meaning.
Also, I don't see any reason to limit the story points options to pre-defined hard-coded values, it just adds complexity to the feature (as far as implentation/coding goes) without any real benefit to the user.
Finally I believe - and ∞ should be one and the same, as they represent a task that can't be properly evaluated for whatever reason, and therefore will not be part of the total count of story points. Wether that reason is a lack of information, or because it represents an ongoing background task or something else can be managed via tags.
Edited by username-removed-570091I agree with @AlexisFinn
Thanks for the discussion.
-
We have prioritization features like priority labels and sorting in our various list views and re-ordeing on issue boards. Definitely effort estimates impact priority. (e.g. "this is a quick win, so let's prioritize this higher"). But this specific use case is harder to automate. And so at least right now I see prioritization and effort estimation as two different things. Please let me know if I'm missing a different connection / relationship.
-
Time tracking is what we are using for time-based effort estimation and tracking use cases. Many teams like to use that for time tracking and time-based planning / project management. (e.g. if you are a consulting organization and you need to estimate a project's effort in terms of time, which converts to a monetary value based on rates.)
-
Issue weight is what we are using for non-time-based effort estimation use cases. This comes from the agile/scrum world where the goal is not to have a time-equivalent point system. Instead, everything is supposed to be relative and it helps your team with estimation over time. For example, a 4-point estimated story should be roughly twice the effort of a 2-point story. Over time, your team gets a rhythm, and you can tell your business owners that you can deliver 15 points per sprint. So the points don't correspond exactly to exact time estimates. This is a well-known practice and many tools have similar features. We have a lot of work here to improve here and build more features. I think some great ideas here are already presented in the above. If we are to iterate on issue weights, it would very likely be further iterated on in EE. Summarizing:
- Some quick wins might be allowing for different weight schemes (Fibonacci is a common one), or even customized ones, per project perhaps? @smcgivern : Is this feasible?
- Infinity weight seems to be an interesting design. Some tools have different issue types, and want to impose on you whether to allow to have points on them or not. We prefer to use labels (instead of issue types), because our design is strategically less prescriptive. And so in that case, having Infinity weight seems like an interesting way to allow you for those use cases, but still in a controlled setting. An example of other tools is Pivotal, which has different issue types that don't allow points: https://www.pivotaltracker.com/blog/bugs-chores-estimate-estimate/.
- Having a free-from number field for the weight doesn't seem like a good idea because we want to encourage best practices.
- Capturing point progress and seeing how your team is doing sprint to sprint are great use cases. We are starting with burn down charts, and hope to expand these to other areas: https://gitlab.com/gitlab-org/gitlab-ee/issues/91
@mrgrauel: Not understanding what you mean issue weight is more for the customer. Could you elaborate? https://gitlab.com/gitlab-org/gitlab-ce/issues/21595#note_26791830
-
We use Scrum as our agile framework, to use scrum as it was designed we need two values on each issue:
- indicates the value for the customer (priority)
- indicates a non-time-based effort estimation such as story points (estimation)
As you said the prioritisation and effort estimation are two different things! I agree, but it's not a solution to change the weight feature. At the moment it's not possible to get both values for an issue in GitLab if you use scrum as your agile framework.
The first one is an indicator for the product owner to give the issue a non technical value with a strong focus on the customer value. Technical dependency shouldn't influence this value at all. The second (story-points) is the estimation of the development team how much effort is needed to complete the issue.
The best solution for our team would be add another value for each issue called Story Points.
Story Point Meaning None Not estimated 0 No effort 1 Very small effort 2 Small effort: double the size of a very little effort 3 Medium effort: as big as a very small effort and a small effort 5 Big effort: as large as a small and a medium effort 8 Very big effort: as large as a medium and a big effort 13 Huge effort: as large as a very big and a big effort 20 Very huge effort: as large as a huge and a very big effort 40 Gigantic effort: as large a two very huge efforts 100 Unbelievable effort: more as double the size of a gigantic effort Does it help to understand our problem? @victorwu
Same here, but I maintain that story-points should be a free-form number for several reasons
-
As pointed out by @victorwu story points are an arbitrary relative value, so the meaning of each value should be determined in-team, and i've definitely seen non-standard values being used sometimes.
-
What is generally refered to as 'best practices' is not automatically the best for everyone, many times specific technical or conceptual choices or specific environments require specific rules. Imagine that a specific global project tracking tool is being used by a company but that tool only accepts values between 0 and 1, or only values over 100, meaning you need to adapt you story points values to work with the tool. This should be allowed.
-
Forcing a user to select one of a preset list of story point values is not 'encouraging' best practices but forcing them on you, wich as pointed out previously might just render the feature unusable on some projects.
-
I strongly believe that it is not gitlab's role as a repository management tool to deal too much with best practices, there are other tools out there such as Jenkins or Grumphp that are designed to take care of whatever practices a company or a dev team wishes to enforce on it's members, but ultimately the choice must stay with the team. Imagine if Gitlab didn't allow you to unlock the Master branch forcing you do send a merge request each time.
The tool must adapt to the user's needs, not the opposite.
Edited by username-removed-570091-
Good Point @AlexisFinn! I agree with you that "the tool must adapt to the user's needs, not the opposite".
Story Points and maybe Weight also should have editable values for each repository, but a default set of values should be given.
Wouldn't it be a good solution to split it in two issues?
- Implement Story Points with a default set (like the fibonacci numbers)
- Implement editable Story Points and Weight values
@mrgrauel Having a preset yet editable set of values per project would be pretty ideal but that also means more work for the Gitlab dev team, and therefore potentially not seeing this feature implemented anytime soon.
As a dev I'm always thinking: Go for the simplest most flexible solution, and make the user be responsible for data content.
Edited by username-removed-570091@victorwu I don't follow how allowing people to configure the weights fits with:
- Having a free-from number field for the weight doesn't seem like a good idea because we want to encourage best practices.
What's the distinction?
Another option would be to keep the 1-9, but allow the 'names' to be configured. So your 1-9 could display as 1, 2, 3, 5, 8, 12, 21, 34, 55?
@smcgivern that wouldn't help! Weight is not a not-time-based effort if you also want to have an indicator for customer value (priority) on each issue.
The meaning of each value is important and should be kept seperate: For example:
Task: Allow users to subscribe to newsletter with a simple form Weight: 9, because this is a very important feature for the client Story Points: 3, because the dev team estimated this is a fairly simple task Priority: Low, as there are a large number of higher priority tasks that need to be acomplished to make this possible (such as setting up smtp server, configuring customisable email in BO, etc..) @smcgivern : Sorry I should've been more clear. A suggestion is project-level configuration. So we would have some level of customization at the project level, and all issues would be restricted to use that scheme. I don't think we should let any user enter any value on the issue itself. So it would still be a dropdown. So that's the level of customization I would be comfortable with from a feature perspective.
@victorwu my concern there is that validation is a pain, because if you change the values, we may have some issues with invalid weights. That's where my suggestion of relabelling the existing 1..9 came in, because then we could store the same values, but just change how they are referred to.
@smcgivern : That makes sense! I think re-labelling is perfect. Then it's more of just a UX design problem. How to best display the feature for users to configure at the project label. But underneath the hood you have essentially an enumerated list of values and use them to mean anything. They could be linear, fibonacci, t-shirt sizes, whatever! Just enumerated fixed list sounds perfect and keeps the product very simple. I like it!
Thanks @mrgrauel and others for the discussion.
A product owner can use various mechanisms to indicate customer/business value right? Using labels is one way. Another is using re-ordering in an issue board to indicate priority. But in any case, it seems that the we can make a simple improvement in generalizing the weight concept here: https://gitlab.com/gitlab-org/gitlab-ce/issues/21595#note_26983043.
It would solve the story point problem and allow users to use them however they see fit. And then for product owners to indicate priority, customer value, etc., we can manage that in a separate issue.
I'll update the description here to propose generalizing weights.
@smcgivern @victorwu Weight concerns the importance given to the feature in the overall project whereas story-points is the estimated complexity of implementation. They are two different things and must be allowed to co-exist otherwise we'll be sticking with redmine for project management as it allows for such coexistence.
I totally agree with @AlexisFinn. It does not fix the problem, cause we need both the weight as it is and story points! It's to totally different things!
Edited by username-removed-19731If this is the proposed solution then it must be possible to assign several 'weights' to a single issue, each one having it's own label.
Also the number of weight values must be increased as 9 different values isn't enough to cover the conventional story-points values.
And finally and most importantly it must be possible to get a total count of each group of relabelled weight per project and per milestone counting of course the relabelled values, not the original 1-9 weight values. this point must be stressed because without it the feature is completely useless
Frankly, although admitedly I haven't looked at the source code, I don't understand how this is easier and cleaner than simply adding a free-form number story point field.
Ok that would allow a dev to basically input any BS story-point value in there, but as justly pointed out by @mlncn here https://gitlab.com/gitlab-org/gitlab-ce/issues/21595#note_27001507 that should be delt with in-team, no fault with the tool itself.
Thanks for the feedback @AlexisFinn and @mrgrauel .
We'll iterate on "weights" to serve non-time-based effort estimate use cases. This includes continuing to iterate on burndown charts (https://gitlab.com/gitlab-org/gitlab-ee/issues/91), and the milestone view, and planning/tracking of issues that involve effort estimates. As we are moving along in this approach:
- We can cover more use cases with a generalized labeling of weights.
- But we have to be careful because with generalized labeling, we can no longer necessarily rely on the weights being a number. If we constraint to numbers to start, that would be great, because burndown charts with summing of issue weights would still make sense. But having "small", "medium", "large" labels would be incompatible.
As well, much of the discussion here has focused on "weights" versus "story points". Feel free to continue discussing. But I wanted to make sure I communicate that I keep using the term "weights" because that's in the product currently and thus very unlikely to change. However, very much our product direction is that we are now heading in the direction of using "weights" to serve the non-time-based effort estimate use cases. So I realize that's confusing because maybe if we just used "story points" in the beginning it would avoid this problem. So in summary, "weights" in GitLab should indeed be considered a feature to solve the "story points" use cases. And we will continue to iterate on this area. I'm re-purposing the other issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/21595) to consider the problem of indicating customer priority as a separate problem.
The feature here in this issue we'll slowly get into more focus and likely revolve around generalized labeling. Feel free to open separate issues if you think we should discuss other problems and use cases that that doesn't solve.
And as for creating a generic field that you can enter any field in, that could be a great one-off solution, and we should consider that as a separate issue. It also would be related to custom fields, and I encourage people to also leave feedback there: https://gitlab.com/gitlab-org/gitlab-ee/issues/1906.
Thanks for your feedback. It is definitely appreciated and the discussion helps GitLab continue to be great.
mentioned in issue #141 (closed)
mentioned in merge request !120 (closed)
added issue weight and removed ~155959 labels
changed milestone to %Backlog
changed milestone to %Next 2-3 months
changed milestone to %Next 3-6 months
Clearly weight is NOT value point (for stakeholders) nor story point (for team's DEVs). It's not priority either, and ordering issue visually should be enough (as we can't order on labels). As is, we cannot use it for anything in Agile spirit.
Allowing us to have semi-Fib' scale instead of linear would be of some help; or to let us determine ourselves the value set would be even better, instead of setting values for us ('cause all of us don't have the same usage of this). The two linear/Fib' scales can be proposed to encourage best practices, of course.
Definitely having 3 scales would fit any need: one for value point (or user priority in Waterfall), one for story point (or complexity in waterfall), and one for priority (though in Agile it's determined by combining previous values).
P.S. This of course is not related to time spent/planned : @mrgrauel wrote "Story points indicate how much time it needs to implement it." which is definitely wrong. It's the effort, not the time! My vision of Agile (which I practice since a dozen years) is much more similar to @victorwu's one.
Awaiting to see the implementation of https://gitlab.com/gitlab-org/gitlab-ce/issues/21595 and #1906 ;)
