Results of the 2023 Prioritization Exercise - The Higher Priorities

The following are the results of the prioritization exercise on January 18th, 2023. We drew a line about halfway down the list and determined that priorities that were above this line were the higher priorities and the ones below the line were lower priorities. That didn't mean that the lower priorities wouldn't get done in 2023, but instead that the higher priorities would be completed first.

Many times, the decision for prioritizing one idea over another was dependency – we couldn't take one aspect of the product development before another one was in place.

To recap, the priorities were created by the product team and product owner and moved to a Miro board. After all the priorities were presented, then we got to work ranking the priorities in single file order. Was this feature more important than this feature? Was the maintenance work imperative to make sure that this product was successful? This was also a time when we might uncover that some features couldn't be developed without having other priorities completed first. After all the presentations, we had a list of epics that were in priority order from the product teams.

Higher Priorities

Priorities submitted are bulleted. This is the order of the priorities as determined at the end of the prioritization process. We have grouped them for ease.

Changing the way we work

• Develop a practice of professional development through learning sprints.

Currently, our sprint practice includes a “buffer” sprint of finishing outstanding work from the sprint and transitioning into local work. This priority reconfigures that sprint into concluding work but also purposefully seeking an educational opportunity to work together. In between cycles we take a “Spindown” without daily Scrum, where team members self-identify issues to work on. The work should be a break from regular project work/constant sprinting, PR review etc. There will be a kick off meeting at the beginning of the week where you let the team know what you will be working on. At the end there will be a review where you let the team know what you accomplished/discovered/experimented with. This idea was blatantly stolen from Northwestern University who has successfully seen high rewards and lower burnout from their team. Since we already have part of this practice in place, this is a low effort/high reward priority that we’ve agreed to try at the end of this sprint cycle.

Deferred Maintenance

• Develop a strategy for ongoing maintenance and security updates.
• Upgrade to Ruby 3.1+ series (multiple products)
• Rails 7 upgrade for all Surfliner products

These three priorities are lumped into the “deferred maintenance category. Maintenance on many of our products has been deferred in lieu of major feature work. However, it is now past due and we are coming up of End-of-Life for Ruby 2.7 and this work is critical to do before feature development in order to make sure we are not solving issues that are resolved with upgraded code bases.

Everyone was in agreement that even though this is not as interesting as other priorities, it is imperative that we make room for this maintenance work.

Plan for the future discovery layer/s.

• Plan for Daylight (Discovery layer for objects)

Create a plan on how to tackle a Discovery layer for objects. This includes identifying the product owner and tech lead, how to gather requirements, and initial development so we can discuss potential blockers.

Although we all agree that undertaking the entire development of Daylight this year is improbable, we agree that putting together a product plan, including potential product owner and tech lead is a priority for 2023.

Significant work towards Comet and Lark

• Lark Update and Maintenance

Lark was last under development years ago, some minimal work may be necessary to confirm current functionality is still in place and perform updates as necessary. The benefits are that we'd not lose the progress already made, and would be prepared for additional development and testing. A part of this would be making a final decision on where Lark will live.

• Comet - Fully featured batch import/export

Extend past work on Bulkrax integration to allow large scale import and export. Well documented mechanisms for ingest at scale are a minimum requirement for realistic Comet adoption at both campuses. We think this should be a priority until we can achieve that goal.

• Lark - Batch creation/test migration/management of new terms

At minimum, ongoing work will require a method to create new terms in batch. Completing a test migration will allow us to verify terms are migrating properly and identify issues with batch creation. Migration failures will open up necessary remediation work ahead of a full migration.

• Comet - Configurable metadata further functional work and M3 controlled vocab/lists and date ranges

• Comet - Improve Comet object lifecycle and auditability

There's a need to holistically address Comet's object lifecycle to clarify what happens when and, where needed, to extend implementation to meet lifecycle trigger requirements. We'd like to include some kind of MVP for audit-ability in this scope, since ingesting prior to audit log implementation will mean objects are missing audit data.

• Lark - Integration of Lark into Comet (including query, storing ID, and label pairs, resolving labels from IDs, and bulk ingest term validation)

Achieving minimal viable Lark integration is necessary for Comet production and implementation

• Comet - Refine Project/Workflows/Role UI

UI work is needed to: make it possible to manage Roles within a Project and create and manage Projects in an intuitive way. Some documentation is also needed to support intra- & inter-campus discussions about Projects and policy.

• Support ingest and management of geospatial objects in Comet (technically this is in the lower priorities line but it fits nicer with the theme here).

Leverages Comet for the management and public distribution of geospatial data.

The line

Now we're at the line that divides the higher priorities from the lower ones. Again, this doesn't mean that the lower priorities won't be completed, just that the higher priorities will be completed first.