Product owner is a role on an Agile scrum team. The product owner (PO) represents the business or user community and is responsible for working with this group to determine what features will be in the product release. Other roles in scrum include scrum master and development team.
Product Owner Responsibilities, and Tasks (2021-02)
This list includes current tasks undertaken by POs, as well as tasks for which POs share the workload with the Community, SIGs and SMEs
Requirement analysis
Research and gather proposed features and /or user stories and requirements
- Review UI mockups with various stakeholders
- Work with UX/UI designers on mockups and adherence to FOLIO UI standards
- Gather datasets
- Document/Define NFRs with team and stakeholders
- Define UI permission requirements
- Write permissions stories as:
- "As a user with permission A, I want to do X."
- Permission spreadsheet (see permission)
- Document in release notes (see release notes)
- Build permission sets in Github and use those for testing
- Write up Bugs
Backlog maintenance
- Refine development team feature/epic backlog
- Refine development team user story backlog
- Write/refine UI stories
- Ensure MOD(backend modules) stories are outlined and linked to appropriate UI (frontend modules) stories and Feature stories
- Review and prioritize bugs for your dev team modules/apps that were submitted by others
- Features Prioritization: Review calculated rankings, review/adjust PO rankings to reflect shifting priorities
- With scrum master, ensure that sprint management is happening - planning, pointing, reviewing
- Work with dev leads to provide high level estimates on features
Platform maintenance
- Write accessibility user stories
- Ensure personal data is captured
- See that your domain/apps contribute to a cohesive FOLIO user experience
Product development
- Help other teams with knowledge transfer as related to your team's apps/modules
- Coordinate development work across multiple teams for a feature(s)
- Help with onboarding new development team members
- Coordinate testing across multiple teams for a feature(s)
- Respond to questions from developers
- Backend User Story Verification (Postman)
- Frontend User Story Verification (either snapshot/scratch dev)
- Attend scrum ceremonies (scrum, sprint planning, sprint review, sprint retros)
QA and Product Testing
- Conduct Usability/User Acceptance Testing (UAT) Testing
- Conduct Accessibility Testing
- Participate in BugFest
- Write QA Tests
- Run QA tests
- Include permission tests
- Performance testing
- Write performance test stories
Release management https://wiki.folio.org/display/REL/Releases+Home
- Prepare for Capacity Planning meetings
- Update estimates
- Identify/Report at-risk features to capacity planning/SIGs
- BugFest
- Supply BugFest data (if necessary for your testing)
- Recruit BugFest participants
- Take Bugfest cases when no participant is assigned
- Create BugFest test cases
- Manage Bugfest test cases
- Release notes
- Update and maintain release notes
- Lead release planning /launch efforts
- Attend release meetings
- Update Documentation
- Manage Hotfix releases
- Triage hotfix defects
- Validate resolution, test in snapshot
- Seek hotfix approval
Stakeholder communication / Customer support
- Support knowledge sharing for features you implement (Respond to questions in slack, make presentations to stakeholders etc.)
- Address customers and prospects' questions
- Lead/attend SIG meetings (include present features/findings)
- With dev team, plan, practice, and present FOLIO-wide sprint demos
PO Education
- Attend /Participate in PO meetings
- Monitor PO Slack channel
- Mentor POs
- Acquire and enhance PO skills set
- Update applicable wiki PO pages
Helpful links
Team vs module responsibility matrix
See Getting Started for Product Owners page for more details on processes and links to resources.
"Thin thread" development
One of the key benefits of scrum development methodology is that it is iterative and incremental. The goal is to release testable software early and often, so that feedback can inform future development. "Thin thread" development supports this goal by putting the emphasis on development of MINIMAL features needed to support an end-to-end workflow, prioritizing those workflows that cross apps.
Writing user stories using "INVEST"
A great mnemonic for structuring user stories is INVEST:
| Letter | Meaning | Description |
|---|---|---|
| I | Independent | The user story should be self-contained, in a way that there is no inherent dependency on another PBI. |
| N | Negotiable | User stories are not explicit contracts and should leave space for discussion. |
| V | Valuable | A user story must deliver value to the stakeholders. |
| E | Estimate-able | You must always be able to estimate the size of a user story. |
| S | Small | User stories should not be so big as to become impossible to plan/task/prioritize within a level of accuracy. |
| T | Testable | The user story or its related description must provide the necessary information to make test development possible. |
https://en.wikipedia.org/wiki/INVEST_(mnemonic)