Product managers receive input from various sources, such as:

• User feedback
• Market research
• New rules and legislation
• And company objectives and key results (OKRs) These inputs are translated into initiatives to ensure alignment between stakeholder needs and company objectives. In an Agile environment, initiatives are broken down into epics. An epic represents a large body of work that spans multiple months or even quarters and requires further refinement for implementation. To refine an epic, product teams use features. A feature still requires multiple sprints to be completed but fits within a single release cycle of the product. Features are prioritized on the product roadmap based on a score, which can be calculated using various methods and frameworks, such as RICE. This score is based on 4 factors:
• Reach: being the number of users that will be affected by this feature within a month.
• The impact on revenue, user experience, satisfaction or other key metrics.
• The confidence the team has in the estimation of the reach, impact and effort.
• And finally, the effort which are the estimated work days required for successful completion of the feature. The RICE score itself is calculated by multiplying Reach, Impact and Confidence and dividing this by Effort. Features with the highest RICE score should get the highest priority. Each feature consists of one or multiple user stories. A user story is a simple description of a part of the feature from the perspective of the user. It must fit within a single sprint and includes acceptance criteria to ensure complete and correct implementation. A good user story meets three requirements:
• It is well written in the form of: As a…, I want to …, so that I can .
• It contains acceptance tests in the form of. Given , When … Then …
• It is well-documented Each story has an expected workload that must fit within the timeframe of a sprint. If this is not the the case, the story must be broken down into multiple stories. A user story is assigned to a single team member the is responsible for the correct implementation of the story.

Epics

This table holds the general information about the epics. These are large bodies of work that are defined based on the company’s goals and objectives.

Fields

• ID. This formula field assigns a unique number to each epic based on the Autonumber.
• Autonumber. This hidden field is used to generate the ID.
• Title. The epic’s short title.
• Description. The epic’s detailed description.
• Features. This linked field to the Features table shows an overview of all features associated with the epic.
• Features count. This count field holds the number of features associated with the epics.

Views

• All epics. Displays all epics in chronological order of their ID.

Features

This table contains the information about the features and their calculated RICE score to prioritize them.

Fields

• ID. This formula field assigns a unique number to each epic based on the Autonumber.
• Autonumber. This hidden field is used to generate the ID.
• Title. The feature’s short title.
• Description. The feature’s detailed description.
• Epic. This linked field to the Epics table shows the epic of the feature.
• Epic name. This is a hidden field used for group by functionality.
• User stories. This linked field to the User stories table shows an overview of all user stories associated with this feature.
• Status. This single select field holds the status of the feature.
• RICE. This formula field calculates the RICE score by multiplying Reach, Impact, Confidence and dividing them by Effort.
• Reach. The estimated reach for the feature on a scale from 1 to 10.
• Impact. The estimated impact for the feature on a scale from 1 to 10.
• Confidence. The confidence of the estimations on a scale from 1 to 10.
• Effort. The estimated effort for the feature expressed in a number of days.
• User story effort. This rollup field calculates the sum of the estimated workload of all associated user stories.
• Effort difference. This formula field calculates the difference between Effort and User story effort.
• Complete. This formula field returns true if all user stories associated with the feature are completed.

Views

• All features. Displays all features in chronological order of their RICE score.
• Completed features. Displays all the features that are marked as completed.
• RICE calculation. Displays only the fields used for the RICE calculation.
• All features grouped by epic. Displays all features grouped by their epic.
• All features by status. Displays all features in an Kanban stacked by their Status.

User stories

User stories are a further refinement of the features. This table holds information to check if a user story is ready for estimation and status information.

Fields

• ID. This formula field assigns a unique number to each epic based on the Autonumber.
• Autonumber. This hidden field is used to generate the ID.
• Story. The actual user story in the form of “As a …, I want to… so that I can ”
• Acceptance criteria. The criteria defined to mark a story as completed.
• Feature. This linked field to the Features table shows the feature of the user story.
• Feature complete. This lookup field shows if all user stories for the feature are completed.
• Feature name. This is a hidden field used for group by functionality.
• Feature status. This lookup field show the status of the associated feature.
• Documentation. This file field holds one or more documents with the details of the user story. This can be wireframes, technical documentation,…
• Status. This single select field holds the status of the user story
• Can be estimated. This formula field checks if Story correct, Criteria correct and Documentation provided are all true.
• Story correct. This formula field checks if the Story is written according to the guidelines.
• Criteria correct. This formula field checks if the Acceptance criteria are written according to the guidelines.
• Documentation provided. This formula field checks if one or more documents are uploaded for the story.
• Feature effort. This lookup field show the estimated effort of the associated feature.
• Estimated work. The estimated workload in days to complete the user story.
• Re-estimate. This formula field checks if the difference between the estimated effort for the user stories is in line with the estimated effort for the entire feature.
• Refine. This formula field calculates if the user story can be completed in a single sprint.
• Assignee. This linked field to the Team table assign as team member to the user story.
• Sprint. This linked field to the Sprints table assigns the user story to a sprint.
• Assignee name. This is a hidden field used for group by functionality.
• Sprint name. This is a hidden field used for group by functionality.
• Epic name. This is a hidden field used for group by functionality.

Views

• All user stories. Displays all user stories in chronological order of their RICE score.
• User stories not ready for estimation. Displays the user stories that cannot be estimated yet because one of the criteria is lacking.
• User stories with workload > 1 week. Displays the user stories with an estimated workload of more than 5 days.
• All user stories grouped by epic and feature. Displays all user stories grouped by their associated epic and feature.
• User stories grouped by sprint and assignee. Displays all user stories grouped by their sprint and assignee.
• Workload estimation. Displays all user stories with only the field that are related to workload estimation.
• User stories in progress. Displays the user stories that are currently in progress.
• User stories stacked by status. Displays all user stories in a Kanban stacked by their Status.

Sprints

A sprint completes a number of user stories over a period of time. This template uses sprints with a fixed period of two weeks.

Fields

• ID. The sprint’s unique ID.
• From. The sprint’s start date.
• Until. The sprint’s deadline.
• Quarter. This single select field holds the quarter of the sprint.
• Status. This single select field holds the status of the sprint.
• Release. This linked field to the Releases table shows the release the sprint belongs to.
• User stories. This linked field to the User stories table shows an overview of all the user stories that are assigned to the sprint.
• Assigned stories. This count field shows the number of user stories associated with the sprint.
• Completed stories. This formula field calculates the number of user stories that are completed.
• Assigned workload. This rollup field summarizes the estimated workload for this sprint.
• Completed workload. This formula field calculates the estimated workload that is completed.
• Progress %. This formula field calculates the progress of the sprint by comparing the Assigned workload and Completed workload.
• Feature complete code. This formula field shows which features are completed during the sprint.
• Feature complete. This lookup field shows a checkbox if a user story completes a feature.
• Release name. TThis is a hidden field used for group by functionality.

Views

• All sprints. Displays all sprints in chronological order of their From date.
• All sprints grouped by release. Displays all sprints grouped by their release.
• All sprints grouped by quarter. Displays all sprints grouped by their quarter.
• All sprints stacked by status. Displays all sprints in a Kanban stacked by their Status.

Releases

A new release of the product occurs when one or multiple features are fully implemented. This table contains the information about past, present and future releases.

Fields

• Codename. The release’s unique name.
• Version. The release’s version number.
• Status. This single select field holds that status for the release.
• Sprints. This linked field to the Sprints table shows an overview of all sprints associated with the releases.
• Features implemented. This lookup field shows checkboxes for all features that must be implemented during this release.
• Estimated release. This rollup field shows the end date of the final sprint associated with the release.

Views

• All releases. Displays all releases in chronological order of their Codename.
• All releases stacked by status. Displays all releases in an Kanban stacked by their Status.

Team

The table contains the general information about the team members that implement user stories.

Fields

• Name. The team member’s name.
• Email. The team member’s e-mail.
• Phone. The team member’s phone.
• Photo. The team member’s profile picture.
• Job role. This single select field holds the job role or speciality of the team member.
• User stories. This linked field to the User stories table shows an overview of all user stories assigned to the team member.
• User stories count. This count field shows the number of user stories assigned to the team member.
• User stories in progress. This formula field shows the user stories where the team member is currently working on.
• Estimated work. This rollup field summarizes the estimated workload of all user stories assigned to the team member.

Views

• All team members. Displays all team members in chronological order of their User stories count.
• All team members grouped by job role. Displays all team members grouped by their job role.
• Gallery: all team members. Displays all team members in a gallery view.