From Stories to Features

Figure 1 — The imaginary line between initiatives/features (why and what) and epics/stories (how and who). Image by Talkdesk

The moment a key internal stakeholder of a Product-Engineering organization tells you: “I am not able to know what are the features being built at Talkdesk”. And, at the same time, teams have their work visible and available to anyone in the organization, you know that there’s a gap that needs to be closed.

Deep Dive

When Talkdesk decided to set the delivery expectations with the market in terms of “we are going to release major features on our product three times a year”, a few challenges and a lot of questions arose, both from the inside and the customers.

This article focuses on the efforts the organization has put in place to clarify, as much as possible, what would be the next set of features available in the Talkdesk product on the next release. And yes, mostly before the beginning of the cycle.

The number of public releases per year is likely to change, but that doesn’t affect what’s about to be detailed.

Release Process Draft

First of all, we have crafted a process. The following is a very short summary of the activities that we have set to help on the above:

• Strategic goals definition and their connection with the long-term roadmap.
• Scope alignment, prioritization, team identification, and high-level sizing.
• Release kickoff to establish a water-line between what’s likely to happen, what looks like a stretch goal and what’s out for the upcoming release.
• Execution, happening typically on two-week iterations of planning, delivery (product increments deployed to production), review and retrospect.
• Monitor through usual Talkdesk practices (like forecasting using yesterday’s weather or Monte Carlo simulations).
• Go live: early access for a subset of customers, or generally available for all customers (for this article, activities like preparation of marketing materials or strategies to early onboard customers are not considered).

Figure 2 — The Talkdesk process for public releases. Image by Talkdesk

At this point, we are sure you could ask a lot of questions about the process itself, but we would like you to think about the high-level sizing “small” step in particular, especially about:

• What a common ask typically looks like.
• The amount of discovery work that needs to be done by the teams.
• The refinement of the initial ask (what and why) in several workable items (how and by whom).

At most, it’s expected to end the exercise with a work breakdown structure of a few hierarchy levels (at least two) and some/several work items, depending on the complexity of the request.

Now, let’s get back to the releases’ reality and the entire Product-Engineering organization, and try to imagine the result of several (20+) teams doing the described exercise.

It’s easy to understand that we ended up with lots of different flavors in terms of structure, granularity, level of detail and certainty around estimates.

But isn’t that exactly what we should expect from an organization like Talkdesk? Especially from the Product-Engineering part of it that aims for high levels of agility? Yes, for sure!

The Trigger

Let’s say that for a specific release we got around:

• 215 epics and 720 stories.
• 40% of the above as part of major initiatives connected to the strategic goals.
• Some teams used subtasks on their stories.

Regardless of the teams’ usage of epics as “big stories” or “labels/ buckets”, epics were always part of the delivery strategy, answering questions like “which big blocks of work do we have? Which part of the product is this epic contributing to?”

The truth is when you are answering questions like the above, you are quite far from being able to answer the following: “when are we going to be able to start onboarding the first customer on this new functionality?”

We had the confirmation of that when a key stakeholder of a Product-Engineering organization told us:

I am not able to know what’s being built at Talkdesk.

When our teams have everything available, updated, properly communicated, and a relevant stakeholder tells us that, we know that there’s a gap.

We realized that we were missing a crystal clear view on the features (capabilities) that our teams were adding to the product — A customer-centric gap! Why? Because that’s the language that your customers understand and that’s the only way to measure real progress in terms of delivery.

It’s the difference between having a handful of artifacts deployed in production and being ready to start the onboarding of a customer in a specific feature.

The Hierarchy of Work Items

By that time, it became clear to us that we needed to change the nature of the conversations while discussing the release wishlists. This puts much more focus on the customer experience, on the impact that we are expecting to have with a specific feature, with our plans to have early adopters using it, not forgetting the required work to get the job done.

And that is briefly the story on how we moved from stories to features — From deployable artifacts to features that delight our customers.

Instead of creating or strengthening a barrier between the requester and the doer, it has contributed to bridging a gap in the way we used to think about the product features. Since then, we are sure that we have spent much more time on the problem space, and we suppose it has contributed to better solutions.

And it will continue to happen as it gets acknowledged by an increasing number of teams.

The following is the complete description of the entire hierarchy of work items that we have been using at Talkdesk ever since:

1. Initiative: an effort of the organization to achieve a certain set of goals towards the company’s vision and strategic goals. Positioned at the highest level of the work items hierarchy, initiatives may span through multiple releases and they typically involve multiple teams.
2. Feature: a customer consumable product capability that adds some type of value to the Talkdesk product. It encompasses all the required work to have customers to start using or benefiting from it. Typically, it involves work from more than one team.
3. Epic: the highest level of work items that contribute to a feature. They are at the release level, which means that they shouldn’t span multiple releases to be completed. Epics belong to only one team, so it’s expected to have several epics for a single feature.
4. Story/bug/task: the most granular level of work items — As well as bugs and tasks. They are at the iteration level, and typically there are a handful of stories to get an epic done. One story should fit into an iteration of a single team (two weeks is the most common duration for an iteration at Talkdesk).
5. Subtask: as part of a work item from the previous level, these are typically small items that help to track progress. They are a fine grain representation of the team/individual strategy to get an item done.

Below is a real example of a past initiative at Talkdesk (live):

Figure 3 — Example of a past initiative at Talkdesk (live). Image by Talkdesk

The Minimum Levels of Consistency

Since I joined Talkdesk in January 2016, we’ve worked on several threads of activities that have contributed to the foundations of what we call “the single source of truth”.

It is the existence of a single truth regarding what we are building (with the why and for whom), and how we are progressing.

We still have a long way to go and we can only get there if we continue to work under minimum levels of consistency like the ones described above.

Figure 4 - Single source of truth. Image by Talkdesk

In this case, they have allowed us to answer in five minutes to: “what’s being built at Talkdesk?”, without having to ask a specific person or facing the risk of getting two different answers when asking two different people.