Planning Process Proposal

Overview of Process

Give each institution (including vendors) 100 points to apply to outstanding features, per the “Rules” listed below.   The ranking system we have been using (where institutions rank features from R1 to R5) is helpful for overall planning, but doesn’t narrow down the critical features to a small enough pool.

Goals of Process

• For libraries to communicate their top features and priorities from among the 300+ features ranked R1 by at least one institution, so that available development resources can be assigned accordingly where possible.
• To ensure that everyone in the community has a clear understanding of what features are included in a specific release and why.

Summary of Process

1. An announcement will be made on the FOLIO Implementation Group Slack channel when the two-week pointing process is planned.
   
2. An announcement will be made on the FOLIO Implementation Group Slack channel when the two-week pointing process has started.
3. A link to the “ballot” will be provided.  The “ballot” will consist of a spreadsheet listing all features that have at least one R1 or R2 rank from an institution.  If a feature you want to point is missing from the spreadsheet, please add it to the end.
4. Each institution will provide the name of one to two people who will be entering the points for the institution here (everyone else will only have view rights to the "ballot").
5. In the appropriate column of the “ballot”, the person your institution has designated as an “updater” will enter a value from 1 to 20 points for the features your institution deems most critical.  The more points your institution applies to a single feature the more likely the feature is going to be completed soon.  (The maximum points an institution is allowed to enter for one feature is 20.)
6. A reminder will be sent after the first week of the process so that institutions know the deadline is approaching in one week.
7. At the end of the two-week pointing process, update access to the “ballot” will be turned off. 
   
8. The results of the pointing process will be documented on the appropriate wiki page (which is Pointing Features for Kiwi Release for the first round).
   
9. A retrospective of the process and results will be conducted at the next FOLIO Implementation Group meeting.
10. When the release is being planned, the wiki page mentioned above will reflect which features are being planned for each team, which features have to wait and why, etc. 

Details of Process

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.