2 of 25

Highlights

SIG prioritization

synchronous & asynchronous
theme definition to forward to PC/Roadmap

Institutional prioritization
Survey
New tools for SIG and institutional ranking
Responsible group: same as roadmap

| www.folio.org

3 of 25

Background

There is an interest to no longer use JIRA for institutional rankings, as it is not seen as the appropriate tool. Existing JIRA rankings should be exported and made available in a spreadsheet for historical purposes.

We may need a way to import rankings back into JIRA.

There was a pointing process introduced for Kiwi that was based on JIRA rankings, as only R1 and R2 features made it into a spreadsheet for institutions to point on. With JIRA being no longer used for rankings, there is either a new process or a new tool needed.

| www.folio.org

4 of 25

Working group members

Thomas Trutt
Marie Widigson
Michelle Futornick
Jacquie Samples
Debra Howell
Martina Tumulla
Jana Freytag (convener)
Martina Schildt (convener)

| www.folio.org

5 of 25

Links and documentation

| www.folio.org

6 of 25

Flowchart

| www.folio.org

7 of 25

Submission of new requests - requirements

not directly part of prioritization process; but related
ideally have consistent way of adding requirements
should be easy and comprehensible across apps
should be easily accessible and usable for new community members as well
least possible duplicative work

| www.folio.org

8 of 25

Submission of new requests - process

New requests are added via a form in Confluence
Use one form per SIG + one form for Cross-App
Relevant information is prefilled as defaults

(such as labels, PO as assignee)

forms will be imported to JIRA via API (

directly/once a week → depends on what is possible

will be added as features with separate (new) status

+ “new_request” label
+ SIG label

PO or convener does duplicate check and brings request into SIG for further refinement and discussion

| www.folio.org

9 of 25

Pros for JIRA

Requests cannot get lost and are easier to track for the providing institution
option to monitor and track via dashboards

for requester, SIG and PO

option to comment,

e.g. if others would like to push the request
for PO or convener to react to new request

linkable to duplicates
history can be kept

| www.folio.org

10 of 25

Goals of prioritization

Julie's feedback: "This is how I would formulate the purpose of prioritisation (i.e. what the SIG is ranking):

Letting whoever looks at the backlog in Jira know, that we want you to work towards getting this request dev-ready, then do the development.

Indeed, you can’t actually force dev teams to take on work, but you can indicate to the PO team lead (who is the guardian of the dev team’s backlog) how the community feels about features"

| www.folio.org

11 of 25

Considerations

Add SIG rank

additional field for calculated rank in JIRA
prioritization as SIG via separate ranking tool
regularly; frequency up to SIG/PO
several weeks to rank
extensive communication
cross-app features: all related SIGs rank

| www.folio.org

12 of 25

Considerations

Institutional ranking

keep one field for calculated institutional rank in JIRA
same feature/epic list as SIG
same ranking tool as SIG
frequency: twice a year
several weeks (> month) to rank
add calculated total rank to JIRA
make variance of ranking available through tool

| www.folio.org

13 of 25

Considerations

Implement weighting for ranking institutions

for implementation status
for consortia vs. single institution
not: OLF members

| www.folio.org

14 of 25

Considerations

What do we rank on?

not preferred: change to ranking epics instead of features
feedback: “Something in between”
find a way to have rankable bundles (discuss with POs?)

NFRs do not need to be ranked
spend X amount of time in development on those (TBD)

| www.folio.org

15 of 25

Considerations

Ranking values

PO rank

keep PO rank as is, because the numbers allow to put features in numerical order

SIG and institutional ranking

will be using 5 ranking levels (similar to R1 to R5)

| www.folio.org

16 of 25

Considerations

Surveys

frequency: once a year
institutions can list most important gaps as free text

e.g. 10 most important functions

will be related to JIRA tickets by PO or SIG convener

| www.folio.org

17 of 25

Considerations

Track features | dashboards

Add label or tag in JIRA
for individual institutions to keep track of individual important features
for broad functional areas

e.g. MM, RA, ACQ, ERM, Cross-app
for easy overview over all SIG JIRAs

| www.folio.org

18 of 25

Considerations

Communication

Extensive
For request and results
In all Committees,

PC SIG convener updates
SIGs
Slack channels
Mailing lists

| www.folio.org

19 of 25

Possible ranking tools

https://airtable.com/

Could be used for broader voting processes

https://seatable.io/en/

Cheaper than airtable

https://uservoice.com/

Could be used for broader voting processes

Miro

Suitable for prioritization discussions within a group
Miro offers an Education account (with full features) that is free to educational institutions. There can be unlimited users interacting with the boards.

Evaluation of tools

| www.folio.org

20 of 25

Next steps

Gather feedback ✅

please comment on these slides

Joint PO and SIG convener meeting

recording will be made available
offer to visit any other interested group
gather feedback via a survey

Presentation of possible tools

separate meeting;pros and cons (incl. costs/budget)
Evaluation of tools

Wolfcon session

| www.folio.org

21 of 25

What is your feedback?

| www.folio.org

22 of 25

Chat

15:44:04 Von Peter Murray an Alle:

App Ideas page: https://wiki.folio.org/display/PLATFORM/FOLIO+App+Ideas

15:50:07 Von Julie Bickle an Alle:

Or they get added in Jira, but not as a "feature" (which has a clear Definition and structure for dev work), but as [Name tbd] "new request" ?

15:51:07 Von Peter Murray an Alle:

It was the "APPIDEAS" project in Jira.

15:51:14 Von Kirstin Kemner-Heek an Alle:

That work can be done by the SIG's

15:51:39 Von Kirstin Kemner-Heek an Alle:

From the SIG's to PO's after first review

15:55:11 Von Charlotte Whitt an Alle:

Often new requirements is driven by libraries, who have this requirement as a road blocker for them in order to adopt FOLIO

15:56:06 Von Owen Stephens an Alle:

I like that Sharon

16:04:44 Von Owen Stephens an Alle:

I agree with that Ian - and there's definitely potential for frustration from the SIGs to see things they have prioritised not getting developed (and I think some SIGs are already in this situation)

16:06:47 Von Kirstin Kemner-Heek an Alle:

+1 Martina

| www.folio.org

23 of 25

Chat

16:08:02 Von Kirstin Kemner-Heek an Alle:

That prioritization is the base to decide on development and open up the opportunities for hopefully future developer Teams to get orientation, what is needed most.

16:09:41 Von Charlotte Whitt an Alle:

And also we need to plan work on features, which span over several apps; so the work being rolled out is useful for the implementing libraries, and not just half-baked functionality

16:12:12 Von Jana Freytag | VZG an Alle:

We have discussed, that NFR and basic industry standards should not be part of the ranking but rather something that will go into development automatically as well.

16:12:27 Von Kirstin Kemner-Heek an Alle:

+1 Owen. Prioritizing gaps / needs/ requirements is just one half of a process to get things done. But it is the necessary start.

16:12:51 Von Harry an Alle:

Owen, I think you have that exactly right. While the priorities help inform interest, it in no way decides what gets worked on next.

16:13:33 Von Gang Zhou (SHL) an Alle:

+1 Owen

16:13:52 Von Harry an Alle:

It has influence. But not a decision maker.

16:15:05 Von Thomas Trutt an Alle:

Sorry, i got tied up.

16:15:46 Von Kirstin Kemner-Heek an Alle:

But development Teams / Stakeholder can base their decisions what they will develop on that Information. That is an indicator what customers want. And other Teams can pick up, what is left over …. it Would be an opportunity to have a transparent process who picks up what - on each Stakeholders own decision. That is not questioned.

| www.folio.org

24 of 25

Chat

16:17:35 Von Maura Byrne an Alle:

Should features fit into epics?

16:17:47 Von Gang Zhou (SHL) an Alle:

+1 Kristin

16:19:00 Von Ian Walls an Alle:

I think all this assumes that we have a single pool or resources that are working against a single queue of features/fixes. I don't think that's realistic in an open source setting

16:19:15 Von Ian Walls an Alle:

different groups are going to have different priorities, and they're free to apply their own resources, and those of like-minded institutions, towards those priorities

16:19:16 Von Harry an Alle:

+1 Ian

16:19:35 Von Gang Zhou (SHL) an Alle:

+1 Ian

16:19:42 Von Thomas Trutt an Alle:

That is defiantly true.

16:19:58 Von Marc Johnson an Alle:

Ian, I think that is a really important point. Which becomes even more important when a feature crosses app boundaries and potentially involves multiple teams

16:20:05 Von Ian Walls an Alle:

as a vendor, should I get to the point of being able to contribute code, I'm going to do what my partner libraries need done. I want to be sure that's given back, but that's where my directive is going to come from

| www.folio.org

25 of 25

Chat

16:20:38 Von Marc Johnson an Alle:

I would also note that development teams don’t tend to make autonomous decisions about what they build. Those decisions tend to come from outside

16:20:48 Von Kristin Martin (University of Chicago; she/her) an Alle:

I hear from POs that they want these ranking from both the SIG and the institutions. I'm not hearing that they feel bound, but they want to get input into direction.

16:22:18 Von Kirstin Kemner-Heek an Alle:

Yes, from the Stakeholder who hires then, for example. That happens in our FOLIO Environment. Other Options are possible. As well as that team decide to do something completely different. All this doesn't exclude any other decisions. But helps to keep an overview.

16:23:35 Von Marie Widigson, Chalmers an Alle:

No additions, Martina, it was a very good summary!

| www.folio.org