Every FOLIO UXPROD feature goes through the series of phases from initiation (the feature is Opened by PO) to release. The whole set of FOLIO features is represented on the Kanban board here. However, there are features that teams/stakeholders create to represent the work on addressing technical debt, incorporating improvements to the application, regular release activities, etc. Such features are not a subject of that process.

Snippet of the Jira board that demonstrates Kanban flow

Feature Pipeline

Open

PO Analysis (DRAFT)

PO Analysis complete (DEV READY)?

Team Review

Implementation

In Review

Complete

Stage benefits

Analysis stage is intended to provide the guidelines and a list of needed points that has to be provided before features are ready to be taken into development. By following that, we're able to deliver the highest value based on the known information and reducing the probability of scope creep and avoiding feature benefits misunderstanding.

Team review stage helps us to understand whether we have all the needed info before taking a feature into release cycle/development. Teams can identify the missed and confusing parts as the future work packages owners. So that's easier for them to see what's missing to deliver what's expected.

NOTE: Team feedback can reveal new information on viability and fit for purpose that may require additional feature analysis before a team can validate understanding

This column is intended to display all the features in progress for easier monitoring

Features currently in progress aligned with current release cycle

Feature moved to implementation when the first user story defined by the team is moved to 'In progress'

Features completed in any release cycle.

Release Management Notification

Exit Criteria

Feature is determined to be Viable and Fit for purpose
Dependent teams/components identified and stated in the feature
Feature must meet Feature Readiness:
Features must include the below information to be moved from Analysis to Team review. Not all steps will apply to all features, but all questions should be considered and noted as Not Applicable if they do not apply
- Feature Title
  Feature Description
  Acceptance Criteria
  Architecture Diagram (component, etc.)
  Feature Level NFRs
  Performance specifics
  Mockups (UI/UX)
  Localization & Translation
SAs have confirmed NFRs are appropriately defined and the specific NFRs are placed in the feature
Release name is added

Team validates understanding of the Feature
Team confirms understanding with Product owner
Team is aligned with dependent teams (if applicable)
Sequence diagram(s) are complete and reviewed by implementing Team with SA and linked to the feature in Jira/Wiki

FOLIO UXPROD DoD met (NEED LINK)

Workflow

When 'Team review' criteria is met, PO adds a label 'Ready to Pull' and team can start implementation of the feature.

If feature is not ready, notes are added in the feature's Jira and discussion with product team is needed on the best course of actions based on priorities and highlighted risks.

To make sure the feature contains required level of details for understanding and effective implementation by the team, it's highly recommended prior to committing and pulling the feature in progress to perform a team level exercise and fill in respective responses in the Feature Readiness checklist below. As a final step of the review, team makes a Fist to Five vote and discusses the result. If it's lower than 4, further discussion is needed to address or mitigate discovered issues. When Team review criteria is met, PO adds a label 'Ready to Pull' and team can start implementation of the feature.

A proposed filled in feature review form should be linked to the feature in Jira. The Wiki page with the form itself should be placed in a centralized space to keep a track of all the business features that FOLIO has. It is proposed to create a Feature Readiness space under the umbrella of https://folio-org.atlassian.net/wiki/display/PC/FOLIO+Product+Council or similar one and place feature readiness details of all features there. It is also suggested to use an approach similar to https://folio-org.atlassian.net/wiki/display/PC/Decision+log where information about child pages is aggregated as a table. Of the required fields - the name of the feature, a link to its dedicated page, names of PO & development team, status (e.g., draft, in review, ready to pull).

Specifications on the roles mentioned in the Feature Readiness checklist:

'Key Driver' a contact person who is able to provide clarification on the respective item and support the team with necessary level of details (business or technical).
'Triad' is a group of PO, SM, Team Lead
'Dev Manager' -

connect with feature life cycle, Jira statuses, teams' place on the roadmap

Status	READY TO PULL / IN REVIEW / READY TO PULL
PO
Dev team
Comment	<put comment here>

Documentation

<Link to feature Jira>
<Link to other related documentation, e.g. requirements list, architectural and / or technical design etc.>

Feature readiness checklist

Note - Every feature must have a dedicated SA. SA should support PO in business analysis, clarification requirements, understanding how requirements are feasible with current architecture, assist with clarifying quality attributes (NFRs) specific for the feature.

#	Area	Validation question	Key Driver	Comment
1	Business value	Has the feature intent/context been conveyed to the team?	PO
2	Skills	Is the team equipped with the appropriate skills and domain knowledge to succeed in delivering the feature? If not, is the team aligned on necessary consultancy, knowledge transfer, etc. that will need to be accounted for in feature plan?	Triad/Dev Manager/SA order?
3	Requirements	Is the feature information up to date (applicable when the feature was refined earlier)?	PO	The refinement process should be done before the actual development was started. Refinement should be done under the current release and the feature may be added to the next one.
4	Requirements	Are the scope/requirements and acceptance criteria clear and well-understood by the team?	PO	Suggestion to have a list of high-level requirements before the feature is presented to a team as a feature candidate.
5	Requirements	Is it clear for team how to test/verify the feature?	PO	PO can provide a list of Draft TC with the basic "happy-path" scenarios and most common negative errors.
6	Requirements	Are design/mock-ups for UI finalized and linked/attached to the feature (if required by the feature)?	PO/UX designer	UX guidelines are followed
7	Architecture	Are the architectural artifacts finalized and linked/attached to the feature (if required by the feature)?	SA/TL
8	Architecture	Does the team have a firm understanding of the architecture involved to deliver the feature and is the runway in place?	SA/TL
9	Modules	Have the modules that will be added/modified been identified (if applicable)?	SA/TL
10	Modules	Has the team discussed and confirmed the dependent modules interactions with their owners (if applicable)?	Triad/ SA/ Owning team Triad
11	NFRs	Has the current state of NFR compliance of those modules/components been reviewed?	PO/SA	Document with product NFRs must be provided to teams
12	NFRs	Is it clear for team how to test/verify required NFR/compliance gaps to ensure the components can be released for this feature?	PO/SA
13	Process	Are all significant pending questions on the feature, assumptions, risks, and follow-up actions documented, resolved?	SM/PO
14	Estimation	Has the team provided T-shirt estimate for the feature (BE/FE/AQA)?	SM
15	Final step	Are the Triad and DEV/QA engineers aligned that the feature is "Ready to Pull" in upcoming release cycle?	SM

Folio Development Teams

[DRAFT] Team Review stage

Documentation

Feature readiness checklist