We launched Iterations in %13.2 and have a lot of ideas for where we could next -- &2422 -- which include things like automatically calculating team velocity/volatility, auto-scheduling iterations, automatically moving issues from one iteration to the next, surfacing iteration data on Issue Boards, and more.
What's the next thing we can add to Iterations to help your team schedule/plan work more effectively?
Please, be careful with automatically moving Issues from one Iteration to the next. This may enable poor planning and teams to over commit. I would suggest a workflow that would allow for teams to decide if they should either move unfinished items onto next iteration or if they would rather place it back on the backlog.
When allowing Issues to move from one Iteration to another, think about the impact that its weight will have on velocity charts. This can be a controversial issue. Some take on the fact that the weight of previous velocity charts should not change when moving Issues, others will say that the Issue was not delivered therefore it should not count or the team should not take credit. My opinion is: Velocity is a function of planning and not a function of reward. Therefore the velocity should remain unchanged.
I would suggest for us to invest on easy Iteration Planning process, it is important to bring the Product Owner community onboard. I would focus on Backlog prioritization and Iteration planning experience as well. Check the Team Planning experience in the Rally product as well for reference.
Surfacing Iteration data on Issue Boards is a great idea. The Rally Iteration Status feature had great reviews from customers on this. It surfaced a few items:
Planned Velocity for the Iteration
How many days till the end of the Iteration
How much weight count or Issue count has been accepted thus far in the Iteration
The ability to quickly access Burnup, burndown and Cumulative Flow Diagram charts from the board.
Please, be careful with automatically moving Issues from one Iteration to the next. This may enable poor planning and teams to over commit. I would suggest a workflow that would allow for teams to decide if they should either move unfinished items onto next iteration or if they would rather place it back on the backlog.
This will be an optional setting.
When allowing Issues to move from one Iteration to another, think about the impact that its weight will have on velocity charts. This can be a controversial issue. Some take on the fact that the weight of previous velocity charts should not change when moving Issues, others will say that the Issue was not delivered therefore it should not count or the team should not take credit. My opinion is: Velocity is a function of planning and not a function of reward. Therefore the velocity should remain unchanged.
Ha I'm well versed in the arguments on both side. I do not believe we will be splitting weights across iterations. I agree with your opinion.
...The ability to quickly access Burnup, burndown and Cumulative Flow Diagram charts from the board.
Also the plan. It will be several releases until we get there but we're on the same page!
@williamchia thanks for the feedback! I wish we could use a single character like other objects in GitLab, but we're running out of meaningful characters so we're exploring a *object: syntax to be more scalable.
*iteration: should trigger a drop down to select from a list of iterations. @mdelaossa is this a bug or we just haven't gotten to it yet?
@gweaver What if different projects in the same group are not following a synchronized Iteration cadence? In this case, would the recommendation be to keep using Milestones?
In the interim, i would advise that they create a group directly above their project or use Milestones until we get this group/project thing figured out.
@gtsiolis: ... there are quite a few design issues in this page besides the broken markdown rendering. Inaccessible colors (labels), new patterns for page actions (dropdown), new styles for empty states, different status labels compared with the status box in similar pages (milestones, issues, merge requests), no edit URL link, broken markdown preview on edit, and more.
Iteration
... different status labels compared with the status box in similar pages (milestones, issues, merge requests)
@gweaver this is referring to the status element used for iterations, see screenshots below:
Issue
Merge Request
Milestone
Iteration
Inaccessible colors (labels)
@gweaver this is referring to the status label colors and Web Content Accessibility Guidelines (WCAG). The background color and the text color combination is failing for normal text for WCAG AA and I think there was a guideline to strive to WCAG AA, see accessibility report. Maybe @tauriedavis can help here.
... new patterns for page actions (dropdown)
@gweaver this is referring to the way you edit the iteration when compared with the edit action across the product.
Snippet
Milestone
Iteration
... new styles for empty states
@gweaver this is referring to the style of the empty issue list. I would expect this to have a similar style with the compact empty state in other areas of the product.
Schedule
Milestone
Iteration
... no edit URL link
@gweaver although a minor issue, this is referring to the URL when you edit the iteration. It's good to have a distinct permalink for the edit page just like we do for the rest of the product. For example, see a label, a milestone.
@gtsiolis thanks for taking the time to add detailed feedback!
this is referring to the status element used for iterations, see screenshots below...
I believe out of all of the screenshots attached, Iterations is the only one using Pajamas for status badges. Over time, we should see all of the other views match Iterations. I know the report app we are building for Iterations will be backported to Milestones in the not to distant future.
this is referring to the status label colors and Web Content Accessibility Guidelines (WCAG). The background color and the text color combination is failing for normal text for WCAG AA
this is referring to the way you edit the iteration when compared with the edit action across the product.
We are exploring a new secondary menu for less used items so they can still be accessed but don't clutter the UI for the majority that will never use those buttons. This will be backported to Milestones and hopefully other things like Issues.
this is referring to the style of the empty issue list. I would expect this to have a similar style with the compact empty state in other areas of the product.
Again, i think the actual pattern is from Pajamas and the other views have not implemented pajamas yet. @hollyreynolds you can confirm or provide follow on improvements to the list empty state.
although a minor issue, this is referring to the URL when you edit the iteration. It's good to have a distinct permalink for the edit page just like we do for the rest of the product.
Great feedback and I agree. I created an issue to add an explicit edit URL - #230705 (closed)
@mikelong I don't think any of our lists are really that consistent. The gitlab-org: # is the title I gave to the iterations and not necessarily part of the design. I named them that way so it was easier to see where an iteration was coming from when selecting it from the dropdown within an issue.
That said...I don't think it was intentional, just the first iteration with the least amount of scope to get something out there. Here is an issue for improving the list view (#227272). Would love your input there.
I'm specifically referring to the gray boundary that the Iterations list items are housed in. It's quite inconsistent with every other list we have. They're style like drag-and-drop issue board items.
This is actually consistent or similar to our labels list and milestones list.
I think we did it for labels because we can reorder those for priority. Then maybe we just reused it for milestones? They're not exactly the same either though.
@gweaver@hollyreynolds I noticed that when I'm in edit view the back button doesn't take me back to the iteration view. For example: Iterations/List -> Iteration 1 -> Iteration 1/Edit [press back button] -> Iterations/List (the back button should have taken me out of edit mode and into iteration 1)
I'd love to add planned Velocity and achieved Velocity to track team's planning accuracy
This is also on our current roadmap (&435) and I'd love to get started on it within the next few releases. Would love your input and collaboration to help shape the proposal!
Looks cool and I'm looking forward to the features in the pipeline!
I do anticipate an issue for us based on the fact that we use a monorepo. We have multiple teams in the same repo who may want to use different iterations or at least measure velocity separately. Maybe this is not a common use case.
Here's an idea: what if we could select a label and see the velocity, charts, etc. for all issues matching that label? We'd have to all use the same iterations, but at least we could measure velocity separately.
Edit: I missed the comment about the working group earlier, that partially answers my question.
The working group about unifying projects / groups would only work if you have multiple projects under one group. But if you only have one project you'd have to use the labels to filter it to certain issues.
Hoping to add to the discussion, I'd really like to see iterations work rather similar to milestones, which is what we are using today to model our sprints. We have three teams working in the same cadence. Each creates their own milestone with the same start and end date. This allows them to easily have their own board views, burndown charts etc. It also allows different teams to pick issues in the same project but still pull them into their own sprint.
Not allowing concurrent group-level iterations would make iterations a tough sell for us, which would be a shame because I really like everything else I'm seeing in this area.
Not allowing concurrent group-level iterations would make iterations a tough sell for us, which would be a shame because I really like everything else I'm seeing in this area.
If you allow concurrent group-level iterations, we would run into the same problem we have with milestones -- you can't reliably calculate velocity across iterations because there is no way to determine the relationship of iterations to one another. We would have to allow Iteration Types or the ability to add a label to an iteration in order to know which iterations to use in calculating a team's velocity (&435).
@m.dessens here's how I'm currently thinking about it....
This allows them to easily have their own board views, burndown charts etc. It also allows different teams to pick issues in the same project but still pull them into their own sprint.
In the shorter term -- Once we ship this -- #225500 (closed) -- you could use labels to denote teams in your mono-repo. "Group By" labels would let you see progress views for each team. With the follow on to the MVC of "Allow the end-user to add/remove label(s) that they want to group issues by." you would be able to filter the charts/issues to a single team's labels. Teams could scope their boards to a given Iteration and their team label (this is what we do). We're also exploring the feasibility of tracking velocity to a label. Once we get to this point on the Iteration report view, we intend to add Iteration/Milestone analytics to Issue Boards themselves so you can quickly see your velocity, current iteration burndown/burnup all without leaving your Board.
In the longer term -- As part of this active working group (https://about.gitlab.com/company/team/structure/working-groups/simplify-groups-and-projects/), we're looking at how to allow teams to decouple issue/project management from their repository while still maintaining a tight integration between the two so the Issue > MR experience is fluid (i.e. assign an issue from your repo project to your Team's group so it shows up in both places). Would love to get your input on this idea.
Solving for this would also enable...
For us, project level iterations make more sense. @ju5t
As a groups/projects would have relative parity from a resources (issues, iterations, repos, etc.) standpoint.
I chose to put Iterations in groups in the near term so we could focus on pushing report views down to projects (#235156 (closed)) while enabling teams to operate on a shared timebox cadence. This approach also makes roll-up reporting much easier as you don't have to scan across multiple concurrent iteration reports and provides a way to get a progress snapshot across multiple dimensions (labels, assignees, projects) within a single view.
That said, this is intended to be a short-term limitation until we figure out the ideal solution for simplifying groups and projects, which is a non-trivial problem but one that needs to be addressed sooner rather than later.
Thanks @gweaver, that makes a lot of sense! What may be a missing link here is that a 'team' is not an entity in Gitlab. You can use (sub)groups to model teams but that hardwires them to repos which may work in most cases but not in all. I understand that adding teams as a full-blown concept to Gitlab opens a new can of worms but I think that's what you need to really get this right.
That said, I'll run iterations in parallel to milestones starting next sprint, share my observations and keep track of new developments on this topic. Thing is, I'm running some DB queries right now to get the reporting I want and I'd be happy to ditch those!
Thing is, I'm running some DB queries right now to get the reporting I want and I'd be happy to ditch those!
Thank you @m.dessens. Would you kindly share what reporting you'd like to see in GitLab (and where you would ideally like those analytics to surface within the product)
What may be a missing link here is that a 'team' is not an entity in Gitlab
This is certainly a contributing factor and I believe it is even a little more nuanced than that. I think in most companies, there are a minimum of three dimensions of organizations:
The actual organizational structure of the company (usually a hierarchy): GitLab for example has a product hierarchy, engineering hierarchy, etc.
The "places of work" / "lines of business" / "value streams" that a company operates -- which are often comprised of cross-functional teams from across the various departments.
Code, infrastructure, pipelines, and all the technical bits that are the value delivery vehicles: Sometimes these can live in the lines of business, but more often than note, some do and other bits are shared services and what not.
Right now GitLab has Groups and Projects, but if you look under the hood, a Project is a collection of resources that has a namespace and a Group is a collection of resources that has a namespace. What if there was just one "container" (not the real name, just a placeholder for this convo) that was a collection of resources and that container could decide which resources to use or not -- and could have more richly expressed relationships with other containers -- both in and across hierarchies.
While not calling the "container" a team (or maybe we do), you could have a hierarchy of them that represented each of the three dimensions of of organization -- and resources could be easily shared among them. I think this generic approach is a bit more future proof than just "teams" because it would allow companies to setup GitLab in a way that was the best reflection of how the actual company, its people, and its technology operates. If we went with just the "teams" approach, we would need to figure out how make them be flexible enough to support the 9 common organizational structures, which feels just as complex as combining groups and projects into one thing.
Question: What is the most appealing path forward to you? What would teams ideally look like to you if they were in GitLab?
To start with the easy question, my current reporting need is to track historical performance. For each sprint, I query for the issues that were done and compare that to the issues that were added to the sprint in the first 2 days of the sprint. This gives me committed vs. done which I paste in a spreadsheet so I keep history. If you're interested, I can show you the sheet.
When it comes to teams, the main reason to have them in Gitlab for me would be to give them the ability to track their performance. So, they would have their own sprint metrics (and as such, their own iterations). We don't have a complex organization so I don't have any requirements from that perspective. If I could define them at the group level, that would be fine.
It's great that you go for iterations, since this is a major step towards getting rid of (annoying) planning tools like Jira. Even when teams use Kanban, iterations could be useful at a higher flight level, when multiple teams need to deliver pieces of software in time.
Even though it's not really related to iterations, the missing capability of organizing issues hierarchically (dependencies) would be another step towards a more plan-driven development.
I would like to see at least some basics features of iterations within GitLab CORE.
@formwandler thanks for the feedback! Right now, the likely buyer for Iterations is a Manager, but as Iterations evolve, I could see some potential opportunities for us to monetize more complex parts of it and move some basic features to Core in line with our stewardship values. This is not a promise or a guarantee but I will revisit the current tier in the not so distant future.
Even though it's not really related to iterations, the missing capability of organizing issues hierarchically (dependencies) would be another step towards a more plan-driven development.
You can do this with Epics -- although they are not in Core. I'll think about ways we could solve for this inline with my above statements.
Feedback on iterations MVC from Enterprise customer:
Overall ask - "is a plan to allow multiple, date overlapping iterations per group?"
Use case:
Our overly simplified structure is like this (it gets far more complicated so doing this isn’t a simple reorganization change)
`Group A
Project – sprint team x Project – sprint team y Project – sprint team z
Group B
Project – sprint team x Project – sprint team y`
If I can only do one overlapping iteration per group I cannot create multiple iterations in a group for each team. We’d have to restructure gitlab to the following
`Group
Project team x
Group
Project team y`
I can facilitate a conversation around this if you'd like - thanks!
This comes with trade-offs though in that it would be difficult if not impossible to roll up "iteration reports" from a project to a group in a meaningful/easily digestible way. I would be interested to speak with your customer to understand how they would expect that reporting roll up to behave.
For now, the workaround is to have project teams operate on a shared iteration cadence -- which i realize may not be ideal.
We have several subgroups with projects and issues in it. Milestones (and in the future iterations) are planned within the parent group.
When I assign an issue from one of those subgroups to an iteration from the parent group, I expect it to see it in the iterations menu of the parent group. Currently, I can assign the issue to an iteration of the parent group, but it doesn't show up.
@clevelandbledsoe I believe we plan to support archiving rather than deleting, as deleting has some difficulties around assigned issues and existing events. Created issue for archiving: #235062
Will an archived iteration still enforce the same rules around overlapping time periods? One of the problems with not being able to delete an iteration is that if someone created it accidentally, especially with a bad start/end, it blocks creating the correct iteration.
Somewhat related, I discovered that you cannot set the dates on an iteration to a date in the past. While this makes sense, in practical terms, what happens when you discovered that someone put the wrong start date on an iteration, three days after the start of the iteration? There's no way to correct the date.
Will an archived iteration still enforce the same rules around overlapping time periods?
@jgutholm great question! I think the window will only be enforced for non-archived ones, but not certain. In the case of bad start/end dates (assuming still in the future) you can edit the dates to be correct, and/or rename the iteration
you cannot set the dates on an iteration to a date in the past
@jgutholm would automating the cadence of Iterations solve for some of this? (i.e. every 2 weeks on Monday at 9AM Eastern) -- so Iterations get autoscheduled according to some predefined mechanism. We could also include templated titles or something similar so the titles always follow the same pattern.
Making an entire iteration in the past would mean events couldn't be added, but there are instances when you want to correct a typo'd start date for example. There are some data integrity issues with this - even if you could move the iteration start date to the past, I don't think it would have any events for that period
I'm not sure how we would solve for this given Iteration reports are intended to be largely event driven -- #230894 (comment 395067871) -- so we can have historically accurate reports (#233707 (closed))
@josh_nugent_haeco yep. Boards are currently undergoing a large refactor to support swimlanes, so we didn't want to throw this into the mix at the same time. Here's the issue -- #196804 (closed) -- and it will be coming within the next few releases.
I noticed that iterations seem to have a gap in the time windows. Let say I have two iterations, one "Aug 5, 2020–Aug 18, 2020" and one "Aug 19, 2020–Sep 1, 2020". On Aug 18, 2020, the first iteration auto closes at some time early, presumably 00:00:00 but the next iteration does not start until 00:00:00 the next day. I can't be sure of the exact time but I noticed this behavior around 6:00 am pacific, where the iteration closing that day was already closed. It seems like the starting date should be date@00:00:00 and ending would date@23:59:59.9999.
The functional impact was that on the last day of the iteration when doing a sprint review, we had to go look in the closed iterations which was a little counterintuitive.
We experienced the same issue as @jgutholm: we had iteration 1 with end date August 31st and iteration 2 started on September 1st. On the morning of August 31st, we found out that Iteration 1 had been closed automatically by GitLab. When I tried editing the iteration end date, it told me that I could not put it on september 1st because it would overlap with iteration 2. Setting iteration 2 to start on September 2nd, did not automatically reopen iteration 1.
We find the auto closing of iterations without the ability to reopen them a bit dangerous and it gives us the impression that we are not in control of what the tool is doing. Closing of an iteration should be a manual action in our opinion.
I half agree with Raymond. I feel like it should be automatic, but you should be able to re-open the iteration to edit it. Therefore an Iteration with problems, like Raymond stated, should be able to be fixed.
I understand that the point-in-time aspect of Iterations is what generates the Iteration report. I believe that the logic to generate the report, in regards to start and end dates should still be able to compute the Iteration report even if the dates were changed. I do not see why this would not be possible, but on the other hand I am not familiar with the code myself.
So I feel like Iteration dates should be editable, even when the Iteration has been closed. Validations should still exist for overlapping Iterations of course. On top of that the Iteration report should "re-build" if dates have been changed.
Side note, thank you so much for adding Iterations! Iterations, when the full feature set has been completed, will be a strong foundational asset to GitLab!
@rbrandon thank you for your report, the Iteration closing on the morning of August 31st is a bug which I'll be addressing ASAP. Issue created: #243575 (closed)
Hey there! I'm loving iterations so far and am wondering if this data will be made of the export issues CSV file? If you can get the iteration data listed there I can then export and build the dashboard and charts I need.
The title of an iteration doesn't help me know which iteration an issue will line up with. Since iterations are defined by their dates, it would be more valuable for me to see Sep 10, 2020–Sep 16, 2020 instead of gitlab-org: #7 when I am assigning an issue to an iteration.
Without knowing anything, I had to figure out that gitlab-org: #7 was the current iteration.
Perhaps we could put the date range in parens next to the title (though that might be a mess or just plain invisible with longer titles). It might also be useful to have shortcut selectors for "Current" and "Next" iteration in the dropdown.
I noticed the iteration's name changed so that we could see the dates in the dropdown list. Clever. This is break my saved quick action, so I had to adjust it.
I wish I could add Iteration as a list in an Issue Board. Currently, I am adding an ~Iteration label to my issues to put them in an individual column as a workaround.
Echoing Raymond, Cleveland and Daniel, I too am sorely missing reopening and deleting/archive of iterations in the case of human errors (PEBCAK).
I also found the following issues with missing epics that may count as feedback on the iteration feature, and could perhaps be added to some of the iteration epics or labeled with a iteration-feature-specific label for easier discovery:
Thank you very much for consolidating these @andtoeoks! What do you think about this proposal -- #285091 (closed). It would sort of negate the need to delete/archive iterations as you would only need to manage the cadence of the iterations -- start date of first iteration, duration of iteration in weeks, etc. It would make managing iterations much more efficient.
Thank you very much for consolidating these @andtoeoks!
No problem, it hope it was useful.
What do you think about this proposal -- #285091 (closed). It would sort of negate the need to delete/archive iterations as you would only need to manage the cadence of the iterations -- start date of first iteration, duration of iteration in weeks, etc. It would make managing iterations much more efficient.
I skimmed over it, and I am not too much a fan of the forced rigidity that this proposal seems to bring, and to me it looks to be moving iterations away from how I personally want to use them.
If the goal with iterations(and iteration cadence) is to enforce a scrum-like process with sprints (i.e timeboxed iterations), the proposal makes sense. But I use the iterations more dynamically (think kanban/agile): I have a rough timebox I aim for (3-4 weeks), and if there are any common holidays (e.g christmas) I add that to the iteration (but I set the iteration end date far into the future to avoid it being automatically closed). Then at the end of the iteration I remove or move unfinished work, and adjust the end date to be the correct date.
I personally don't think automating creation and closing of the iteration need to be part of the MVP, as creating/closing is not particularly timeconsuming, and is an O(1) operation with regards to team size. There is other, far more time-consuming tasks around iterations that I would rather see automated:
on completion of issue the iteration field automatically set to the current active iteration for the project (taking inheritance into account), unless set manually (or give pop-up for developer to fill in iteration if setting it automatically is too much magic)
be able to tie an iteration and a git tag / release together
connect milestones, iterations and epics together somehow
look at burn-down/burn-up by weight and by time spent / time estimated over an iteration
Mind you, the way I use milestones and iterations is:
Miletones: focused on business goal, not timeboxed, tied to minor/major release of product (usually)
Iteration: time-boxed (ish), tied to patch-release of product (usually an iteration ends with a patch-release of the product)
Epics: feature/story focused, not timeboxed, may be rolled out across iterations
The way I initially envisioned this pain point being resolved was just by being able to filter results by groupcompliance. I realize that GitLab groups using scoped labels to identify who is responsible for work may be unique compared to other users.
Reviewing your comment captures much more around the architecture of iterations.
Basic Rules + Mockups
I can see how this evolves the iteration feature to be both more flexible and useful. It feels like you are proposing quite a lot in one issue. If I personally had to make my pick one thing that would be the most important then it would be - Boards can be scoped to only one set (we can determine current) This would free me of scoping the current iteration to my board with a label I am making like Iteration13
Also, consider that not all issues are worth the same. So even though we are 20% done with issues in this iteration, its hard to know if we completed a bunch with a weight of 1 or were they more extensive.
At my company, we have several teams working at several services, and a set of shared microservices which are worked on by all teams whenever new features are required. So several teams with sprints of 2 weeks, and some teams that have sprints of 3 weeks, and some that have a monthly release cadence.
Issues are registered at the repository of each product, and the teams have a different release cadence each. We'd like to be able to register multiple 'iteration tracks', one for each team, so that for each team we have one active iteration measuring their velocity over their respective sprint. We want to be able to link all issues being worked on by team members to the iteration, so that requires the iteration to be defined in the top-level group - the shared repositories need to be accessed by both teams and the issues must be able to be assigned to the iterations of all teams (only one at a time). We currently use Jira for project and issue management, but would love to ditch that dependency for Gitlab, but that's not a viable option right now.
The current proposed solution for administrating concurrent asynchronous sprints in gitlab is using milestones, but that limits our ability to use milestones the way they are meant to be used. Please allow us to define multiple concurrent iteration tracks for different teams.
This could be as 'easy' as lifting the requirement of linking issues to iterations that are directly created in a parent group by also allowing to link to iterations of sub-groups of a shared parent group.
@matthias.vandemeent we're actually talking through some of this on #285091 (closed). Would you be open to a 15 minute Zoom with me at some point in the next week so I can learn more about your use cases and discuss the options we're considering?
@matthias.vandemeent thanks again for taking the time to speak with me. Here is a proposal to address your uses cases -- #285091 (comment 465264060). I'd love your (or anyone else that would find value in supporting multiple iteration cadences within a Group hierarchy) feedback.
@gweaver Feedback for iterations from SimpleSense:
“I want to add a list (to an issue board) for iterations. I do not have the drag & drop functionality like milestones. I think that iteration should be sprints - time bound. A milestone is a goal and iterations are sprints. Milestones will take multiple iterations of work. Milestones do not have hard timelines. We need a board view for iterations (they are the sprints) I cant see what we did in a past sprint (iteration) and what is remaining. I also cant delete iterations either.”
Summary:
Wants ability to create swimlanes for iterations on issue boards
Wants to be able to drag and drop issues in between iterations
Wants to treat iterations like sprints NOT milestones
Question: Is there anything planned to connect Iteration to Releases? Currently we use Milestones for our fixed cadence of monthly releases but will probably switch to Iterations and begin using Milestones for more objective-based grouping. However the integration between Milestones and Releases is nice and we'd like the same with Iterations.
It's not something incredibly important for us, but I didn't find any mention of Releases here or in the Iterations Epic, so I thought I'd ask if you've considered it.
@hsharrison we've bounced around the idea unofficially but don't have any issues at this point. I would be curious to know if it is needed / wanted if we were to ship #199087. Thoughts?
Interesting, I hadn't seen that you were planning that. Yeah, that would possibly be another way of achieving the same thing.
My concerns would be effort of assigning multiple issues vs. one iteration and relatedly a SSOT problem (possibility of mistakenly leaving some issues out of the release that are nevertheless in the iteration). But I think we could figure it out. And I see in the issue that you are thinking about these things, so let's see what you come up with
the /iteration *iteration:<name> "quick" action is very clumsy. What about "/*iteration:` or anything else that would not make me type "iteration" two times?
/iteration current, /iteration next or /iteration +3 quickactions would be awesome (e.g. extremely helpful in a servicedesk template?)
the "related issues" list is not of good use to us. We'd need to see weights, issue state, maybe labels or even containing projects, sort by weight, due date... -- sounds quite like the regular issue list.
Is there any discussion of having Epics inherit start/end date off of iterations, instead of requiring issues to be in milestones to inform the calculation? So far, we are loving the iterations feature, and it would simplify admin if the iterations could inform Epics.
I've fired a few searches, but search-fu must be weak this AM.
I haven't found an issue for this yet, but it would be nice to attribute an issue to an iteration directly from the Issue Creation form, like what we can do for milestones.
Help, my iteration ends tomorrow and I am not sure and can not find anywhere if the open/inprogress issues will automatically move to the next iteration or I have to manually do it? Please advise.
The last straw for me and iterations is the lack of ability to delete an iteration I created under the wrong group and which I can not delete. This is insane. It has no stories associated with it and it's not in the past. The lack of a delete option isn't a safety feature, it's a bug.
Forcing us to leave cruft laying around is bad from. I am not going to back into our report generation code and add an exception check in multiple locations to not use a "bad" iteration that shouldn't be there in the first place.
I didn't see an existing issue for the following, so hopefully it's not a duplicate:
Iteration usability: add more options to scope board to iterations
Context
When scoping a board down to milestones, there are several options:
Any milestone
No milestone
Upcoming
Started
Request
As a gitlab user, I want to be able to scope our boards to iterations the way we used to do it when we were using milestones (because iterations didn't exist yet). The board should be able to be filtered down to:
Any iteration (Iteration is not none)
Current (Iteration is equal to the current/live iteration)
Started (Iteration's start date is earlier than today's date)
Upcoming (Iteration's start date is later than the current/live iteration's end date)
I've been using iterations for a couple months now. I'm just about to enable iteration cadences in our production environment (currently been testing in staging).
A few thoughts:
Full GitLab Flavored Markdown support. Part of our sprint planning ritual is to establish goals, provide why context and call out key dates during the sprint, so I include this info in the iteration itself.
Table lines do not render, I currently make ASCII tables in code blocks
Mermaid doesn't seem to work either
Group By currently only supports labels
Add Epics for a workstream type of view
Add Assignees for an individual view
It would also be nice if there was some capacity vs weight visualizations, for the iteration as a whole and broken down by assignee. We have to juggle planned work and unplanned work, so being able to plan out my sprint in one place and sanity check that I'm not over-stuffing my sprint would be really helpful
Premium customer would like to have the iterations defined at the sub-group level to be accessible in the shared projects of that sub-group: ZD(Internal)
I would, as another premium customer, like this too. We have have multiple development teams working on the same monorepo. We're currently using milestones for tracking sprints, but would like to migrate to iterations instead, so we can use milestones for its intended use instead.
We're currently limited by the fact that iterations can't overlap, which for our use case, they would need, as all teams are working on the same project.