Introduction
Backlog is an ordered list of everything that is known to be needed in the product. Jile supports a multi-level backlog hierarchy starting from Product Capabilities, Features and Stories.
Capabilities
Product Capability is a high level solution behavior addressing one or more stakeholder needs. Capability is part of the backlog hierarchy and contains one or more features.
Capabilities are typically used as a backlog item when you are building very large solutions with multiple products and teams. Hence unlike other backlog items like features or stories a capability cannot be tagged to a specific team
Grooming
Capabilities are refined as a part of the backlog refinement process in which the capabilities are sufficiently detailed with acceptance criteria, business value, benefits etc. They are further broken down to multiple smaller chunks of module called Features. During the refinement process capability will go through multiple stages before they can considered Ready for implementation.
During the grooming exercise if the teams feels that the capability is too big and cannot fit in a release cadence, they can split the capability into multiple smaller capabilities.
Capabilities can be continuously ranked based on business value or any other attribute deemed fit by the product owner or the product management team. At any point in time capabilities can be either ranked up or down depending on the changing business needs. The top ranked capabilities are picked for implementation during the planning process and helps the team to deliver the most important capability and provide the highest value to its customers.
Planning and Development
When the capabilities are marked as Ready for implementation they can be planned into release schedule. Once the capabilities are planned into a release schedule it moves from the product backlog to the release backlog
Capabilities and its child features can either be planned and delivered in a same release schedule or across multiple release schedules based on the wow configuration.
If a capability is planned in a release schedule then all its child features have to be planned and delivered in the same schedule. However if a capability is not planned into a release schedule then its child features can be planned and delivered across multiple release schedules
Mark as Done
When the capabilities are completed and satisfies the definition of done they are moved to the done state. When the release schedule is closed capabilities in the done state and moved to the done pile automatically
Capability Functions
Product Backlog - Capabilities
Product Backlog - Capabilities Function helps the team to manage a backlog of product capabilities.
- Capture information about a capability like title, description, benefits etc. Estimate the size of a capability using configurable units Rank the capability and create a prioritized list Breakdown capability into one or more features View capabilities in different formats like cards, grids and boards
Release Backlog - Capabilities
Release Backlog - Capabilities Function helps the team to manage a backlog of capabilities planned in a release schedule. A Release schedule is a larger planning cadence containing one or more iteration schedules
- Create and plan new capabilities in the release backlog Visualize the flow of capabilities in the release backlog Track progress of capabilities planned in the release backlog Rank the capabilities within the release backlog Split large capabilities into multiple smaller capabilities Re-plan capabilities into another release schedule
Capability Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of CA###. ( Note : Workspace Admin can customize the prefix ) |
| Title | Brief title of the capability |
| Description | Detailed description of the capability |
| Benefits | Detailed Description of the Benefits which the capability provides to the end users |
| Acceptance Criteria | Detailed set of conditions the capability has to meet to be accepted by the owner / Users |
| Tags | Set of labels to group or categorize related capabilities |
| Status | Status of the capability. |
| Ready Date | Date on which the capability was marked as Ready for implementation. |
| Type | Capability can be of 2 types.
1. Business - A Business capability provides a service that addresses a specific business need. 2. Enabler - Enablers are technical capabilities that support the development of business capabilities. |
| Owner | Capability Owner. (Only Key Members can be tagged as Capability Owner) |
| Workarea | The workarea in which the capability belongs to |
| Release Schedule | Planned release schedule |
| Business Value | Business Value provided by this capability. (Note: Workspace Admin can customize the initial list of values for business value. Business Value can also be configured to have a calculator control based on a set of attributes values defined by the administrator ) |
| Initial Estimate | Initial Size Estimate of the Capability. (Workspace Admin can customize the initial estimate values. Initial Estimate Value can also be configured to have a calculator control based on a set of attributes values defined by the administrator) |
| Story Estimate | Rolled up estimate points of all the Stories tagged to this capability. (Note: Capabilities can be broken down into product features and subsequently into product stories which can be estimated in points.) |
| Entity | DESCRIPTION |
| Objectives | The Objective or the goal this capability addresses |
| Initiatives | The parent initiative that has identified this capability |
| Persona | The user persona whose goals or challenges this capability addresses |
| Components | The software system this capability belongs to |
| Constraints | Non-functional requirements this capability has to address |
| Features | List of all child features of this capability |
Features
Product Feature is a high level solution behavior addressing one or more stakeholder needs. Features are part of the backlog hierarchy and contains one or more stories. Features can either originate from an initiative or capability or can be an independent item.
Grooming
Features are refined as a part of the backlog refinement process in which the features are sufficiently detailed with acceptance criteria, business value, benefits etc. They are further broken down to multiple smaller chunks of module called stories. During the refinement process features will go through multiple stages before they can considered Ready for implementation
During the grooming exercise if the teams feels that the feature is too big and cannot fit in a release cadence, they can split the feature into multiple smaller features.
Ranking
Features can be continuously ranked based on business value or any other attribute deemed fit by the product owner or the product management team. At any point in time features can be either ranked up or down depending on the changing business needs. The top ranked features are always picked for implementation during the planning process and helps the team to deliver the most important features and provide the highest value to its customers. To know more, please visit Jile Ranking.
Planning and Delivery
When the features are marked as Ready for implementation they can be planned into release schedule. Once the features are planned into a release schedule it moves from the Product backlog to the release backlog.
Features and its child Stories can either be planned and delivered in a same release / iteration schedule or across multiple release / iteration schedules based on the wow configuration.
If a feature is planned in a release schedule then all its child stories have to be planned and delivered in the same schedule. However if a feature is not planned into a release schedule then its child stories can be planned and delivered across multiple release / iteration schedules.
Mark as Done
When the features are completed and satisfies the definition of done they are moved to the
Feature Functions
Product Backlog - Features
Product Backlog - Features Function helps the team to manage a backlog of product features.
Release Backlog - Features
Release Backlog - Features Function helps the team to manage a backlog of features planned in a release schedule
- Create and plan new features in the release backlog Visualize the flow of features in the release backlog Track progress of features planned in the release backlog Rank the features within the release backlog Split large features into multiple smaller features Re-plan features into another release schedule
Feature Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of FE###. ( Note : Workspace Admin can customize the prefix ) |
| Title | Brief title of the feature |
| Description | Detailed description of the feature |
| Benefits | Detailed Description of the benefits which the feature provides to the end users |
| Acceptance Criteria | Detailed set of conditions the feature has to meet to be accepted by the owner / users |
| Tags | Set of labels to group or categorize related features |
| Status | Status of the feature |
| Ready Date | Date on which the Feature was marked as Ready for implementation. |
| Type | Feature can be of 2 types.
1. Business - A Business feature provides a service that addresses a specific business need. 2. Enabler - Enablers are technical features that support the development of business features. |
| Team | Team tagged to this feature |
| Owner | Feature Owner. (Only Key Members can be tagged as Feature Owner) |
| Workarea | The workarea in which the feature belongs to |
| Release Schedule | Planned release schedule |
| Business Value | Business Value provided by this feature. (Note: Workspace Admin can customize the initial list of values for business value. Business Value can also be configured to have a calculator control based on a set of attributes values defined by the administrator ) |
| Initial Estimate | Initial Size Estimate of the Feature. (Workspace Admin can customize the initial estimate values. Initial Estimate Value can also be configured to have a calculator control based on a set of attributes values defined by the administrator) |
| Story Estimate | Rolled up estimate points of all the Stories tagged to this Feature. (Note: Features can be broken down into product stories and be estimated in points.) |
| Entity | DESCRIPTION |
| Objectives | The Objective or the goal this feature addresses. |
| Initiatives | The parent initiative that has identified this feature |
| Persona | The User Persona whose goals or challenges this feature addresses |
| Capability | The parent capability this feature belongs to |
| Components | The software system this feature belongs to |
| Constraints | Non-functional requirements this feature has to address |
| Stories | List of all child stories of this feature |
| Tests | List of all test cases of this feature |
Stories
A Story is a high level definition of a system requirement containing just enough information addressing one or more stakeholder needs. Story is the leaf most item of the backlog hierarchy. Stories can either originate from a feature or can be an independent item.
Stories are typically documented in the following format. As a (role) I want (something) so that (benefit).
Grooming
Stories are refined as a part of the backlog refinement process in which the stories are sufficiently detailed with acceptance criteria, estimates etc. Stories can be optionally broken into one or more work items called Tasks. During the refinement process stories will go through multiple stages before they can considered Ready for implementation.
During the grooming exercise if the teams feels that the story is too big and cannot fit in a iteration cadence, they can split the story into multiple smaller stories.
Stories can be continuously ranked based on estimate or any other attribute deemed fit by the product owner or the product management team. At any point in time stories can be either ranked up or down depending on the changing business needs. The top ranked stories are always picked for implementation during the planning process and helps the team to deliver the most important stories and provide the highest value to its customers.
Planning and Delivery
Scrum Teams plan and deliver stories in iterations. When the stories are marked as Ready for implementation they can be planned into an Iteration Schedule. Once the stories are planned into an iteration schedule it moves from the product backlog to the iteration backlog.
Kanban Teams use the Kanban board to visualize and track the flow of stories during the development process
Mark as Done
When the stories are completed and satisfies the definition of done they are moved to the
Story Functions
Product Backlog - Stories
Product Backlog - Stories Function helps the team to manage a backlog of product stories.
Release Backlog - Stories
Release Backlog - Stories Function helps the team to manage a backlog of stories planned in a release schedule
Iteration Backlog - Stories
Iteration Backlog - Stories Function helps the team to manage a backlog of stories planned in an iteration schedule.
- Create and plan new stories in the iteration backlog Visualize the flow of stories in the iteration backlog Track progress of stories in the iteration backlog Create and plan new stories into an iteration Rank the stories within the iteration backlog Breakdown Stories into one or more tasks Re-plan stories into another iteration schedule
Team Dependency Board
Team Dependency Board Function helps the teams to manage dependencies of stories across teams. A Dependency is a relationship between two stories where the completion of one story is dependent on the execution or completion of another story
Story Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of US###. (Note : Workspace Admin can customize the prefix) |
| Title | Brief title of the story |
| Description | Detailed Description of the Story |
| Acceptance Criteria | Detailed set of conditions the story has to meet to be accepted by the Owner / Users |
| Tags | Set of labels to group or categorize related Features |
| Status | Status of the Feature |
| Ready Date | Date on which the Story was marked as Ready for implementation. |
| Type | Story can be of 3 types.
1. Business - A Business Story provides a service that addresses a specific business need. 2. Enabler - Enablers are technical story that support the development of business stories 3. Defect - Defect stories that are broken down from Product Defects. |
| Team | Team tagged to this story |
| Owner | Story Owner. (Only Key Members can be tagged as Feature Owner) |
| Release Schedule | Planned release schedule |
| Estimate | Size of the Story measured in story points. (Workspace Admin can customize the story point values / ranges. Story Estimate can also be configured to have a calculator control based on a set of attributes values defined by the administrator) |
| Entity | DESCRIPTION | Feature | The parent feature that has identified this sory |
| Persona | The user persona whose goals or challenges this story addresses |
| Components | The software system this story belongs to |
| Constraints | Non-functional requirements this story has to address. |
| Tasks | List of all tasks associated with this story |
| Tests | List of all tests associated with this story |
| Issues | List of all issues associated with this story |
Tasks
Tasks
Tasks are development work that the teams performs to complete a Story. Tasks are small enough to be completed by one person in a few hours or up to a maximum of a day. Stories are usually broken down into tasks during the grooming process and estimated in hours. New tasks are also identified and added into the backlog during the iteration. During the iteration team members pick up tasks and complete them.
Team members update the actual consumed effort and estimated remaining effort regularly in the form of work log. This helps the teams to project the effort required to complete the task and also compare it against the original estimate.
Task Functions
Iteration Backlog - Tasks
Iteration Backlog - Tasks Function helps the teams to manage a backlog of tasks planned in an iteration schedule. Tasks are detailed activities that needs to be completed to mark a story as Done.
Task Attributes and Relationships
| ID | A Unique identifier with a 2 letter prefix and a sequence number in the form of TA###. ( Note : Workspace Admin can customize the prefix ) |
| Title | Brief title of the task |
| Description | Detailed description of the task |
| Status | Status of the task |
| Owner | Task Owner. (Only members of the team to which the story is assigned can be tagged as Task Owner) |
| Tags | Set of labels to group or categorize related tasks |
| Planned Effort | Planned task effort measured in person hours |
| Consumed Effort | Actual consumed effort measured in person hours |
| Remaining Effort | Projected remaining effort measured in person hours |
| Total Effort | Consumed Effort + Remaining Effort |
| Entity | DESCRIPTION |
| Story | The parent story to which the task belongs to |