Feature Sizing

We know that a Feature should “fit” into a PI, but how exactly do we accomplish this? Feature sizing is a bit of an art (not an Agile Release Train) and a bit of a science. We want the Feature to be of value to the customer, but it also can’t be so big that it takes us a long time to deliver it.

The challenge that Product Management is up against is the same challenge that Goldilocks had with the three bears: finding the Feature that is “just right.” When we first launch an ART, the Features tend to be “too big.” We lack the knowledge and experience to know how much work the ART can deliver in a PI.

We often see this play out in the first stage of PI Planning. Product Management presents the top 10 Features, and at the end of Day 1, we realize that we will be lucky to complete 1 (or at best, 2) of the Features. To avoid this in the future, ARTs will often overcorrect, and we will see Features that are “too small.” Now, almost every Feature can be delivered in a single iteration.

It can take upwards of a year after the ART is launched before we start to normalize and get Features that are “just right.” The question becomes, how do we get Features that are “just right” earlier in the process? There’s no magic bullet, but here are strategies to adopt early with your ART:

• Get feedback: This seems like it should be simple and that it would be a normal part of the process, but often, Product Management works in a bubble with only the Product Owners and doesn’t ask the teams that will be doing the work to share how long it will take to deliver it. The estimate doesn’t need to be precise, and an understanding needs to be established that this isn’t a commitment but an estimate.
• Keep batch sizes small: Suggest that Product Management creates a couple of Features to start, maybe two or three, and then gets feedback. Are the Features too big, too small, or just right? Maybe the Features have too much detail or not enough. In the same way that we look for the teams to get continuous feedback on the work they are delivering, Product Management and Product Owners should get feedback on the work they are delivering in the form of Features and stories.
• Definition of Done: Ensure that the Definition of Done (DoD) aligns with and supports the current environmental setup. We have encountered DoDs stating the work needed to be in production for the Feature to be considered “done.” The organization had constraints and bottlenecks in the process and the fastest timeline from development to production was eight weeks (almost an entire PI). We adjusted the DoD from production to pre-production and then worked with the System Team on streamlining the move to production over time.

What about Points?

We typically don’t assign points to Features or estimate them from a points perspective. When we size Features, we are looking to ensure that they are deliverable in a PI. We want to leverage the concept of relative sizing to help with estimation.

Pro tip

When we relatively size Features, we often start with a Feature that took us three to four iterations to complete and call that a medium. We then take a new Feature and decide whether this new Feature is bigger, smaller, or the same size as our first Feature.

Some ARTs add up the number of story points once the Feature is completed and establish ranges for Features, similar to Epics, to help with forecasting. For example, a small Feature is 50 to 150 points, while a medium Feature is between 150 and 300. We could then potentially look at the average velocity of the ART and the Features in the backlog and roughly estimate when a Feature could potentially be delivered. We strongly encourage you to use this practice with extreme caution as it can lead to perceived commitments.

Pro tip

When working with teams and ARTs, I typically encourage T-shirt sizing the Features as small, medium, and large. I look for a small Feature to be delivered in about 2–3 iterations, a medium Feature typically is 3–4 iterations, and if we have a large Feature, we work to split it into smaller Features.

Now, let’s take a look at some options for splitting and combining Features.

Feature Splitting and Combining

In our experience, most of the time, we see Features that are “too big” based on the feedback from the teams. We will want and need to split our Features into smaller, more manageable work to keep our batch sizes small. There are many different ways and methodologies to split work. SAFe® has 10 ways [6]. Ultimately, whatever practices you follow for splitting stories, you can scale those to Features.

Here are some ways you can split stories that apply to Features:

• Workflow steps
• Business rule variations
• Major effort
• Simple/complex
• Variations in data
• Data entry methods
• Deferred system qualities
• Operations (for example, Create, Read, Update, Delete (CRUD))
• Use case scenarios
• Break-out spike

One watchpoint when splitting Features (or stories) is that we want to try and keep each Feature as independent as possible from another Feature to enable early value delivery.

If you find that your Features are generally “too small,” it’s important to work with the teams to identify natural combinations using the same concepts you used to split a story, only in reverse. Combine Features that were originally split by operations into one or maybe two Features.

Caution – but Jira doesn’t have Features!

Many of your organizations use Jira as your agile tool, as it is one of the most popular tools on the market. At the time of writing, Jira currently doesn’t have “Features” in the sense that SAFe® has defined them. There are numerous workarounds and add-ons available to leverage Features in Jira. However, my advice is Keep It Super Simple (KISS). Simply use Jira Epics as Features and ensure that the organization understands. A Rosetta Stone of sorts in that, in our organization, a Jira Epic is equivalent to a SAFe® Feature.

Now that we know what Features are and why they are important, let’s take a look at some ways we can prioritize them.