Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. The current ranking processing whereby each library ranks each feature from R1 to R5 is still useful for documenting their institution’s requirements. This process also helps the Product Owners decide the order of work when they have few or no features that have been pointed.  It is also useful to the libraries when they are deciding which features to apply points to.
  2. All community libraries (or library networks) and vendors are eligible to vote, regardless of membership status, implementation status, etc.  The only requirement is that the library plans on implementing FOLIO at some point.  All votes will be counted equally.  
  3. All communication will be made via the FOLIO Implementation Group Slack channel.  There will also be a wiki page containing information that has been communicated.
  4. The “ballot” will be a Google spreadsheet containing any feature ranked R1 or R2 by an institution.  All features will be identified as being planned by the capacity plan or not.  The first tab of the spreadsheet will include instructions plus a total points spent/remaining calculation for each library.  
  5. Voting will be transparent.  The Google spreadsheet will be viewable by everyone, and updated by representatives from the various libraries who are given edit permission.
  6. Voting will be stopped on the publicly announced date. The Google sheet will then become view-only.  If an institution has not voted by that day, their votes may not be included.  If an institution needs to change their vote after the cut-off and before re-voting is allowed, they should contact the Capacity Planning Team.
  7. Voting will be done again before the next release, given that needs change over time.
  8. Each library may assign 1-20 points to a single feature.  The maximum of 20 points to one feature means that at a minimum each library will vote for 5 features.  This is being done to avoid a situation where an institution spends all 100 points on a feature no one else wants. 
  9. If a highly pointed feature is blocked by another feature that is not pointed at all, or not highly pointed, the other feature will need to be completed first.  The blocking feature will automatically be raised to the point level of the blocked feature.  Depending on the size of the blocking feature, this may limit our ability to complete the highly pointed feature within the same release.
  10. We only have so much capacity.  If the top 10 features are all related to Inventory, we may not be able to complete all of the features in the same release.  The Capacity Planning Team will attempt to accommodate the highest ranked features, but this cannot be guaranteed.  We will work on as many features as possible before we run out of capacity.
  11. When creating the Capacity Plan, features will be sorted by total points and planned in that order, until we run out of capacity.  We normally complete about 70-80 features per release, depending on the feature estimates and length of the development cycle.  We will continue to allocate 25%-50% of our capacity to bug fixes and support (which may include NFRs and tech debt).  The other 50%-75% will be used for the highly pointed features.
  12. For teams not planned by the Capacity Plan, the Product Owners will use the rankings when considering the order of work for their teams.  
  13. Some features will need to be worked on that are not highly pointed because they are mandatory, tech debt, prerequisites, etc.  These adjustments will be announced so that they are transparent.
  14. Product owners will review the highly pointed features to determine what may be a prerequisite, what may not make sense, etc. and make adjustments as needed.  These adjustments will be announced so that they are transparent.
  15. For Product Owners without points, or with minimum highly pointed features, the Product Owner will use the remaining capacity as they believe it should be used.  Product Owners will continue to use the PO Rank field in the UXPROD issue to show their priorities.  These decisions will be transparent as well.
  16. In situations where the PO Rank field differs from the total ranking of a feature, the Product Owner must supply a justification in the PO Ranking Note field.
  17. The Capacity Planning Team will review the results with the Product Council and discuss any issues that arise.

Remaining Milestones for Proposal

  • March 4, 2021: Share updated draft document with FOLIO Implemention Group
  • March 9, 2021: Discuss at FOLIO Implemention Group meeting.
  • March 10, 2021: Proposal is finalized by the FOLIO Implemention Group and distributed to the Product Council.
  • March 11, 2021: Discuss at Product Council meeting.
  • March 19, 2021: Proposal is finalized by all.