When migrating from another product it may be useful to add historical data that is currently in progress, or just to move all the data over to keep it in a single location. For this to work Iterations need to support having dates in the past.
The user should be able to create a new Iteration that has dates in the past.
Proposal
allow iteration creation in the past if it does not overlap with existing iterations
Further details
Allows historical data to be migrated into the project from external services.
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
This should not only be for creating an Iteration, but also for the editing of an Iteration.
Like mentioned here: #221284 (comment 393731353)
What if a user made a typo and needed to modify the iteration start date, but did not realize there was a typo until the start date pasted the current date.
Please, please, please add the ability to do past start & end dates so I can use the awesome Iterations feature!
@gweaver hopefully this will add you to participants so you are informed of this issue a.k.a. get even more emails about Iterations than you already do. Muahahaha!
@common_knowledge this is not really as trivial as it sounds. I'd like to explore how we could solve for this but in the long run, Iterations reports are going to be driven by an events so we can show historically accurate information on burnup/burndown charts. If something happened in the past, we won't have events for it as @psimyn noted (#221284 (comment 393731353)).
@gweaver Thanks for the reply. I did a quick search but could not find anything regarding Iteration events. Is there an epic or plan our there that describes what this is?
Thanks!
@gweaver I think I understand what you are saying. Basically it is easy to remove the validation to create past events, but the problem is the report not generating properly since the past iteration would 'closed' once it is created.
So I guess the question on my end is...
What extra data can be provided, when associating issues with a past iteration, to make a past Iteration report generate properly?
Iterations reports are going to be driven by an events so we can show historically accurate information on burnup/burndown charts. If something happened in the past, we won't have events for it
Actually, the events we are recording aren't tied to iterations. Even when an issue isn't assigned to a milestone / iteration, we record the same events. So I think creating dates in the past should work.
The problem is if you set those dates to be before we started tracking events (Events are tracked starting 13.3) then you wouldn't have any data.
The problem is if you set those dates to be before we started tracking events (Events are tracked starting 13.3) then you wouldn't have any data.
So basically any past Iterations created, pre 13.3, will not have any data, but could still have Issues associated with them.
If so, then that would be fine. Since before Iterations were implemented, Sprints were done with Milestones and thus missed issues were not tracked anyway except with labels like"MISSED::Sprint - 2020-08-02", etc. So there is no harm in not having data in those past Iterations as it is nor better, nor worse than it is without iterations. Except now you would be able to at least "bucket" all issues, even old issues into Iterations aka move them all from Milestones. Thus, Milestones could then be used for what they are intended for... Actual project milestones, as a child of an Epic in an Agile PM practice.
So I think creating dates in the past should work.
So does this mean all that needs to happen to have Iterations in the past is to remove the validations for Iteration Start and End dates in Create/Edit Iteration screens?
So does this mean all that needs to happen to have Iterations in the past is to remove the validations for Iteration Start and End dates in Create/Edit Iteration screens?
I think so, but I haven't really worked on iterations so I cannot say for sure.
I also do not know if the missing data is the only reason for not allowing dates in the past.
@mdelaossa Thoughts on this? We would really like to use Iterations, but cannot unless past dates are allowed. If the result of Iterations created with past dates is a empty/broken Iteration report, then that is fine, as it is not any worse than it currently is.
If allowed, then this should be a super easy fix.
@gweaver Can we please get this verified to see if past dates wont cause major problems? If not can we get this assigned and maybe added to Milestone since it would be a very quick fix. I would hate for this issue to fall through the cracks.
BTW.... You guys are amazing! I wish other software teams were as knowledgeable, down to earth, responsive, and as open as the GitLab team is!
As far as I understand the missing data in reports was our only concern for not allowing dates in the past, so this would be a Product decision.
cc/ @gweaver
Sounds like this could be a dialog upon creating a past Iteration (via API would not need dialog).... "Please be aware that the creation of an Iteration in the past will result in Issues associated to an Iteration, but the Iteration report will be empty as the Iteration report is generated point-in-time."
@common_knowledge I'll put it on our roadmap for the next few releases but without any data in the Iteration report, what is the value in creating Iterations in the past? I'm just curious
Right now we use Milestones as our Iterations/Sprints. I want to use the power of Iterations now for our sprints. So I will need to port over all of our past sprints from Milestones to Iterations. Then we can use Milestones as they are intended for, and then finally we will then be able to use Epics how they are supposed to be used. We use labels in Milestones as our hack as actual Milestones so its messy. So when they are ported over to Iterations, I will convert the 'label' milestones to actual Milestones we have done in the past. Reporting of past sprints is all done on the side and/or in Jira in the future. Iteration reports will only be handy when looking at last sprint and current sprint, at least for us.
This is basically the last piece of the pie that will enable us to have a streamlined PM process without hacking things.
@gweaver Haha we shall see what GitLab brings to the table in the future. The only reason we will do it in Jira in the future is because we manage IT tickets and other IT projects in Jira so I basically import data from GitLab into Jira so we can have all IT related analytics under one platform.
That being said... I am in GitLab 90% of the time and in Jira the other 10%... so i will probably use GitLab for all "software" based analytics versus "high level" business analytics for the department in Jira or Excel.
@gweaver I aggree with @common_knowledge on the need for past iteration dates. But another reason is to simply let folks play with them and learn about them. Which means being able to delete them as well.
@common_knowledge@cemcconn as we've been thinking about Iterations and getting feedback from the community, it seems there is value in exploring the idea of automating the cadence of iterations (#285091 (closed)). In this case, you would define a "start date" and an Iteration duration in weeks. Based on that, iterations would be created automatically.
It would sort negate the need to delete any single Iteration because you would just be changing variables such as iteration length and start date. What do you think?
@gweaver I think this would be a beneficial feature. I would no longer have to automatically create new Iterations (Technically Milestones though since we have not switched to Iterations) via our BOT script.
I will comment in the other post, but I still need...
The ability to create Iterations in the past.
The ability to assign issues to an Iteration that has already ended... for old issues. (via the API is fine)
If the Iteration "Cadence" was added, I believe that a modification to the Cadence (2 weeks to 1 week), would retroactively effect previous Iterations. So all Iterations would be overwritten to the newly set cadence.
All I really NEED right now is those first two points. The cadence thing is just a nice to have feature that I can easily automate, and since I already have automated this it would just be a code change once we start using Iterations.
Until those first 2 points are met, we cannot use Iterations. So I guess my point is that I would be very happy if the 2 easy things were completed before I really cared about an extra feature that does not really save me any time.
The ability to assign issues to an Iteration that has already ended... for old issues. (via the API is fine)
@common_knowledge I think we can technically allow creating iterations in the past, but I would like to understand what would you expect from reporting point of view when issues are assigned to a past iteration that already ended? If you are mainly interested in calculating velocity, capacity from that iteration, then that is 100% doable as long as issues have weights and iteration has a duration . However the charts would not be able to reflect any meaningful data in terms of how iteration progressed as all/most added issues would be added afterwards and most probably on a single day.
@acroitor Thanks, and that is totally acceptable. I wouldn't care if it didn't give any reports or statistics, as long as I can see that Issue x was assigned to Iteration y in the past and the dates of that Iteration was available. Any sort of past reporting or data analytics would be done outside of GitLab, probably in Excel. This sort of data analytics would be used for overall team, individual developer, and project performance.
So if these 2 things are possible then that is a win, regardless of what reporting is available.
The ability to create Iterations in the past.
The ability to assign issues to an Iteration that has already ended... for old issues. (via the API is fine)