Epics, Features, and User Stories are trending words in the Agile community. Any organization that has adopted the agile way of working is seemingly obsessed with epics, features, and user stories and these organizations cannot seem to get enough of them. Indeed these work items are a critical part of breaking down into deliverable items of value but are NOT the only thing. Depending on your organization’s structure, approach to long-term planning, and scope, tracking features or user stories work fine.

The Problem

When it comes to learning about how well the program and project are doing at a higher level that consists of senior leadership, managers, and business owners, they are interested in the overall progress of the product rather than knowing about how a feature or a user story is going. They need answers to the age-old questions “Are we going to make it on time? Is the project within budget?” They are interested in a quick, easy, and definitive way to see a health check of their program. The already skeptical stakeholders won’t tend to dabble at a granular level to know the progress of how their product is doing.

From a financial standpoint, it is difficult to fund features or epics. This funding is usually based on the vision and the predicted ROI and speculated or predicted figures that a program or a project can bring. When working in an agile environment, you only put up some of your requirements upfront and plan according to them. Not all can be predefined in agile because it is an ongoing exploratory process. Requirements are constantly being refined to produce small chunks of value upon which frequent feedback is obtained, improvements are made, and so on. Features and user stories all have a start and an end date as they are planned as executable pieces of valuable deliverables but at times even those dates can change as well.

When it comes to effectively tracking your work, there has to be a certain hierarchy established. Creating features, user stories and tasks lends itself to being hierarchical information in an organization. Thus determining the progress of the work being done across all levels of understanding in an organization cannot be done just using features or user stories. Every level in an organization has a different requirement and a distinct way and amount of information that needs to be addressed.

What are Shared Services and Components?

In large organizations, development teams would be working for various components or providing shared services. These two aspects contribute towards the success of the release train but the development times are dedicated only part time for this. The work for shared services and components is not solely dependent on being done for one planned release train, rather it can be for different projects and products that belong to one or more than one release train. Development teams may have to work back and forth in order to fulfill some of the responsibilities of shared services and components which can be required whenever they are needed. The nature of the work done in the shared services and components can range from a minor fix, support work for system architecture, or an ongoing improvement that is always being enhanced and improved in the background which can neither be categorized into a feature nor a user story. In fact, they are something that does not necessarily need to be discussed with the stakeholders.

How to Track the Work for Shared Services and Components?

Tracking the work done by shared services can be difficult for project or program managers. There needs to be a separate backlog for their work that needs to be prioritized like a program backlog. Unlike a release train that has a focused program backlog for its development, the work that is done for shared services and components can be added to a backlog but it would not be dedicated to one release train. It would need to be prioritized and would consist of all the necessary artifacts roadmaps and other supporting items needed to manage and track the work done. It can include work from all the different products, projects, and release trains for which the work is being done. And the hardest part of it all is that this backlog will not have your conventional features or user stories.

The Solution for Tracking

Tools like JIRA are centered on providing the progress of a Release Train that is in focus and that is planned to be delivered. However, it gives you a limited ability to track the progress of enhancements within a component. Thus the visualization that we have obtained is one-sided. Working on the product for the Release Train is indeed the nucleus of what an organization does. But if we shift the spotlight to what the teams are doing and to further highlight the problem that the development teams face, alongside the development for the Release Train, they are simultaneously working on categories, products, shared services, or components that may not be part of the Release Train that may be planned to be delivered first. How can they be tracked? Moving forward, an effective way of clearly conveying the progress and helping track the progress of the work being done at a higher level can be done by using Batches.

What is a Batch?

Batches provide you with freedom. Freedom to plan however you like in whatever way you like. It can be a container for high-level requirements that can be further broken down into projects, initiatives, epics(s), or features(s). It can also be a component or a functionality that needs to be enhanced periodically.

This example gives an overview of some of the core elements of building a house. If the work is small, it can be divided into Epics and Features for the execution of the work. However, plumbing work for the entire house is no mean feat, therefore you might want to keep track of those on an even higher level. You may want to make enhancements during the course of the year, maybe they are mini projects by themselves. On an Epic and Feature level in ALM tools, this would not suffice, you cannot track them with features or epics.

How Does a Batch Help with Tracking?

A batch can be used as a high-level backlog or a roadmap for high-level planning. It can have dashboards within batches for the execution of one sprint or Program Increment (if working with Scaled Agile Framework). Planning with batches provides a clearer and more accurate way of tracking. It can have anything that is needed to work with regardless of the size and complexity. It can span across one or multiple quarters, Program Increments, or Sprints. Batches can be linked with other batches. They can be used to prioritize according to their value, ROI, user engagement, or as simply as their delivery deadline.

Kendis: Transform Your Approach to Planning and Execution

Elevate your organization with Kendis, a premier solution designed to fuel your success through features like Batches, OKRs, Strategic Themes, Roadmaps, Solution Boards, and top-notch PI/Big Room Planning and Tracking capabilities. Visit Kendis.io to explore the full spectrum of our offerings and transform the way you strategize, plan, and achieve your goals.