| Activity | Notes | Useful links/info |
|---|
| Release Planning / Roadmap | Three times in a year are planned by POs. High-level roadmap for the next quarter consists of the the list of features assigned to PO. Features are created in UXPROD project in Jira and estimated in T-shirt sizes upon overview with the team. Level of confidence must be added together with estimation on BE and FE sides. Stories/tasks/bugs are created in corresponding JIRA projects (each module has a separate JIRA project related to a separate git repo) and must be linked to a feature in UXPROD project. | - Review Getting Started for Product Owners.
- Review folio features dashboards:
- Juniper (R2 2021)
- Kiwi (R3 2021)
- Review Releases - Home:
- Release timelines
- Release and pre-release activities epics
- Release tasks are created in teams' backlog to plan and track effort required for release activities
- Tasks for pre-release upgrades are created in teams' backlog to plan and track effort
- Work with PO to get the features up-to-date (assigned to PO, correct statuses and epics, fix versions).
- Example: Filter of Features prioritized by PO
- Example: Feature board with quick filters by Release (fix version)
- Make sure Features are estimated in T-shirts and level of confidence is added
- Make sure Stories/tasks/bugs are linked to Features.
- Make sure you have grouping "features" created if necessary (for example, to group all the work planned relating to e2e/API/unit tests tech debt, bugfixes/enhancements related to various previously delivered features, etc.)
- Roadmap can be created to visualize current focus of a team (For example, Thunderjet - Roadmap / Status Reports)
|
| Backlog Grooming | PO is responsible for adding stories to the backlog. Team can add stories to the backlog on behalf of PO, but PO is accountable to review and prioritize. Prioritization of backlog must be done by PO. Backlog grooming are held using https://www.planitpoker.com. Stories/Bugs are estimated in Story points (no estimations in hours!). In case Story/Bug cannot be estimated and additional investigation is required, a spike can be added (in a form of story) to investigate before assessing an actual story and taking in to Sprint. | - Backlog items are created in separate Jira projects corresponding to the repo the changes will be committed to. FE and BE items required for the same piece of functionality are created as separate items in different Jira projects. Make sure such dependent items are appropriately linked in Jira.
- Make sure PO works on backlog to add stories with detailed descriptions and acceptance criteria (for example -
STCOM-438
-
Getting issue details...
STATUS
,
MODFIN-199
-
Getting issue details...
STATUS
,
UIF-318
-
Getting issue details...
STATUS
).
- Review Templates for User stories and Bugs: Standard Bug Write-Up Format; Development Backlogs → User stories (example of team specific templates - Thunderjet - Definition of Ready).
- Templates can be added to Template project and fetched by specific Jira projects to pre-populate description while creation of new items in the project.
- Make sure PO prioritizes backlog items on regular basis.
- Make sure the items are put to Draft if they are not yet ready for grooming.
- Create team room on https://www.planitpoker.com and organize regular Backlog Grooming meetings using https://www.planitpoker.com.
- Make sure the team understands relative estimation and have workshops on baseline stories at least once per 6 months.
|
| Sprint Planning | All Folio Teams share Sprints timeline: two-week sprints (three-week sprint around NY) Usually sprints are closed on Friday/Monday and started on Friday/Monday. | - Capacity Planning based on expected availability of the team (allocation, public holidays, vacations, etc.)
- Expected Velocity planning based on the expected capacity and average velocity and average capacity of the team.
- Select planning approach suitable for the team: general planning based on average velocity of the team as a whole, planning by platform (if there are several platforms) or even individual planning with assignment of stories to team-members while planning (if there are some individuals with specific skills and stories cannot be taken by any team-members).
- Consider spillovers while planning next sprint, they cannot be ignored.
- Optional: Sprint Planning summary to indicate capacity utilization while planning and forecast for next sprint.
|
| Daily Stand-ups | Taking place the same time and place every work day. | - Drive Stand-ups with new teams. Try to ask team-members to drive Stand-ups in more mature teams.
- Optional: Daily Standup Notes with major items completed, decisions made and actions for the team-members.
|
| Sprint Review / Internal Demo | The meeting is to review the board and understand the amount of spillover, reasons for the stories to be incomplete and to present completed work internally to the team-members and PO.
| - Get understanding of spillover reasons and how much effort is still required to get the stories completed.
- Drive internal demo for the team-members to screenshare and present completed work to the team.
- Make sure all the accepted stories are closed.
- Analyze metrics upon sprint closure: DC/jira.
- Optional: Sprint Closure Report for the team to outline current status and work on further improvements.
- Update bi-weekly doc for Ebsco to mention changes in plan and issues/risks.
- Update DC on EPAM side to provide data for Sprint Report.
|
| Sprint Retrospective | Sprint Retro is held using https://funretro.io/. The team is to add cards before the meeting to save time. Likes and dislikes are discussed during the meeting and Action plan is created. Action plan is updated on team's confluence page to track progress on completion. | - https://easyretro.io/ Create a board for your team; clear the cards after Retro Action Plan is updated, and use the same Board for further Retros.
- Make sure you remind the team about any actions pending based on the previous Retro.
- Update Retro action plan on team's confluence page regularly (for example - Acquisitions - Retrospective / Action Plan).
- Review Retro Actions and discuss results with the team to mark actions as done if any improvements confirmed.
- Optional: use polls in Slack to vote if there are improvements for retro actions.
|
| System Demo | System Demo is a joint demo for all the teams and is organized once per two sprints. The team and PO should decide whether to present anything on System demo. Slide deck must be updated to outline major updates for two previous sprints. | - Discuss with PO if they want to present any of the completed functionality. System Demo is more user oriented and non-functional updates, refactoring, back-end development can be hardly presented.
- Check with PO if slide deck is updated for System Demo.
|