I was curious about things, so I went thru all ten of the “In-Development” Items.
5 have less than 30 days in development. I think these items literally were part of the sprint that delivered the beginning of the month changes like the Folders for custom views, and perhaps didn’t mean internal QA to be pushed to production. My hope/guess is that these items will make it to the next sprint’s push to production.
5 others have items that have been in development for a year or more, and all of those lack any real status updates of substance. Extremely length delays between updates (if there are any).
Heck, over half of the In Production Delivered items from November, were all started about 30 days ago)
So my worry is that one of the biggest criteria for something to actually get promoted to “In-Development” is can it be completed within a 30 day sprint. If it can, it has a high probability, if it cannot, it likely sits in Candidate or Committed purgatory for quite some time.
I don’t think anyone is expecting regular updates for candidate items.
I think most people aren’t expecting regular updates for committed items either.
However…
- In Development - Currently being actively built by our team.
We expect status updates. Major Milestones accomplished, Major Roadblocks encountered, something. I personally would love a 90 day status update that outlines the success or failures of the *previous 90 days* because that’s not something where you could be concerned that we will hold you accountable for educated guesses. It’s not an educated guess, it should be a sanitized summary of already existing internal documentation for the sprint.
Of the ten items currently listed as In-Development.
https://community.incidentiq.com/ideas/device-exchange-enhancements-654/index3.html?tid=654&sort=oldestFirst#comments (In Development for about a year, last update a year ago)
https://community.incidentiq.com/ideas/tagging-other-techs-in-tickets-at-477/index3.html?sort=oldestFirst#comments (30 Days in Development, KB published, but likely missed this update rollout, so probably next months release?)
https://community.incidentiq.com/ideas/the-ability-to-see-who-else-is-looking-at-a-tickets-979/index2.html?sort=oldestFirst#comments (30 days in Development, no release update)
https://community.incidentiq.com/ideas/user-emulation-638/index4.html?sort=oldestFirst#comments (15 days in development)
https://community.incidentiq.com/ideas/add-additional-visibility-controls-to-knowledge-base-articles-teams-location-6907 (1 month in development)
https://community.incidentiq.com/ideas/add-a-follower-by-using-the-at-before-their-name-1286( 1 month in development)
https://community.incidentiq.com/ideas/booking-thresholds-2422 (2 years in development, No status update from dev team regarding progress, roadblocks, 6 layers of refactoring projects required to allow this to actually be in development, versus being switched back to a candidate)
https://community.incidentiq.com/ideas/send-email-alerts-to-parents-guardians-via-rules-engine-804/index2.html?sort=oldestFirst#comments(1 year in development, announced as a tentative release for early 2027. Seeing as we are getting close to this timeline, an update to let us know now if you don’t see a release prior to the end of Q1 2027. We would rather hear now that you don’t think you can make “early 2027” when we are in late 2026, rather than hearing in Mid 2027 “Ooopsie Doodles”
https://community.incidentiq.com/ideas/user-role-needs-more-granular-roles-486 (In Development 3 year ago, there are lots of other features that were rolled out that might be able to accomplish the initial request, but in a fairly clunky way)
https://community.incidentiq.com/ideas/recurring-events-in-google-calendar-recurring-events-in-iq-events-3392 (In Development 2 years ago, no recent updates). I can see where maybe you have some difficulties because of how Google deals with Recurring events - https://developers.google.com/workspace/calendar/api/concepts/events-calendars#recurring-events & https://developers.google.com/workspace/calendar/api/guides/recurringevents#accessing_instances )
Looking at this roughly, it’s at least 3 separate goals.
1 - Reliable Ingest Recurring events from Google Calendar (This seems like it’s easy and well documented)
2 - Support editing recurring events within iIQ events without needing it to be done manually for each event instance
3 - Push Recurring events reliably back into Google Calendar.
I can totally understand where 2 and 3 might be far more difficult, so figure out how many people would benefit from having the first part delivered event if it comes with the caveat that edits are not possible, and pushing changes back are not supported. A One Way ingest might be all some people are looking for.
So in total, 10 items in development, 5 of them started within the last 30 days, likely part of the “sprint” that saw most of these items that were delivered here at the beginning of the month. 5 items outstanding,
