Analytics - Delivery by Features

Scope changes, feature delivery variations and progress tracking

Kendis Team avatar
Written by Kendis Team
Updated over a week ago

Features planning and tracking is an important part of the PI/Big room planning. Since many teams are often involved in delivering a feature, tracking isn't a simple task. With Kendis analytics, valuable information for Release Train Engineers (RTEs), Business Owners, Program Managers, and other relevant team members is readily available.

Difficult questions like what got added to the PI after planning, or which features have slipped their original plans are often impossible to find in your agile tools like Jira or AzureDevOps.

This section of analytics has

  1. Scope Changes

  2. Variations

  3. List View for Features by Team/Sprint

1. Scope Changes

This section is only available once your board is in the Tracking state.

What is a Scope Change?

Any feature or story added to the board after the planning is considered a scope change. In other words, once the board is in a tracking state any new items that appear on the board will be marked as scope changes. Story points for scope changes are the sum of story points for all the stories added in the tracking state.

The percentage will calculate the amount of change to the overall board, depending on existing features, stories, or story points.

Tip: These numbers are clickable and show the exact contents that are added to the board

2. Delivery Variations

Feature delivery variation means the features that have changed their "Phoenix" sprint after the planning, e.g. if a feature was supposed to be done by Sprint 3 and when a story moved from Sprint 3 to Sprint 4, it will push the feature delivery to sprint 4. Finding such information is very difficult but with Kendis analytics, it is available right away at your fingertips.

Sprint Planning Variations show the stories that have changed their originally planned sprints. The purpose of this information is to make it easier to understand the changes that happened after the planning, since teams often plan their stories after PI planning during their sprint plannings, however, sometimes a crucial feature could be delayed just because a story that was originally supposed to be done in Sprint-x was moved to some other sprint.

3. Features List View By Teams/Sprints

This section provides a comprehensive overview of the features that are planned on your board. It shows the ID, Summary, Status and the percentage completion based on the number of stories and story points (estimate).

The last 2 columns are most important ones, they show the split of a feature to teams and sprints.

The notation X/Y means that X = Done and Y= Total.

Example

FEA-5 has the following break down and it means that there are 5 stories in total, 1 in progress, and 4 done. There are 2 teams, CRM and DWH that are involved. The CRM team has 2 stories and both are done. DWH team has 3 stories and 2 are done, the only open story is in S4 (Sprint 4), which is highlighted by 0/1.

Filteration options

In this section, there are a number of filtration options available

  • Planned Features: List of features that are planned by the teams.

  • Spill Over: Stories that are not completed in a sprint and moved to another sprint are referred to as spill over. This would only work when you start and end sprint at Kendis.

  • Scope Change - Added: Show the features and stories that are added to the board or teams (previously unplanned and now planned) in tracking state

  • Scope Change - Removed: Show the features that are removed in tracking state from the board or teams (previously planned and now unplanned)

Did this answer your question?