Taking an objective and defining the solution is hard. It's also the place where many of us get it wrong.

Pre-2010 most software product teams were using a waterfall approach. They were designing large features, sometimes entire products upfront. And they were doing so well ahead of engineers building them.

Then gradually most of us shifted to agile. Features got broken into smaller and smaller units. Eventually they got so small that we lost sight of the big picture.

One thing we love about Shape Up is that small teams build decent chunks of work. And they are not confined to short sprints.

At Joyous we favour this approach too. Here are the steps we take to carve objectives into smaller chunks.

Figure 9 Breaking objectives into chunks of features

Carve objectives into chunks

• We take the objectives from the positive roadmap and carve them into smaller chunks. Each chunk is deployable, and consists of many features.
• It should be possible to build these chunks in parallel. So, there shouldn't be too much interdependency between them.

• Next, arrange them in the order it makes most sense to build them in.
• For each chunk:
• Create a list of all the features that you'd like to include.
• Divide the feature list into two parts. Those that must be in the first release, and those that can wait until after.

Let's take a look at the major chunks of our flexible conversations objective.

Figure 10 The six chunks of Flexible Conversations

Each feature you include in the first release extends the time to initial release. Try and set aside as many features as possible for later.

Next, let's look at the features for some of these chunks, divided into the first release, and those that can wait.

Figure 11 Four chunks with first release features (white), and features that can wait (yellow)

Features that can wait

Keep trying to set aside features. You'll be attached to including features in the first release that can likely wait. It's not to say that you won't build these features. Although separating them out leaves the door open.

The goal is to shorten the time until a customer first experiences an improvement. Once the first release is out then you can deliver the other features in a constant flurry thereafter.

Before going any further socialise your plan. This allows other stakeholders the opportunity to refine the plan further without wasting time designing the wrong features.

Important considerations when defining features

Start with the problem. We create a document called a Joy Map in which we map out the details of each chunk. Our first step is to describe the problem.

This includes:

• The challenges we are trying to solve.
• The short term impact of not solving the challenges.
• The long term impact of not solving the challenges.
• The high-level customer use cases that relate to this challenge.
• The success metrics we should consider as we design our solution.
• Links to related information that provide more background and context.

We continue to flesh out the details of the Joy Map later, after the solution has been designed in Figma.

Deliver tangible value. A product shouldn't go too long without delivering value that a user can see and experience. Delivering changes only in the background doesn't feel like progress to customers.

Manage risk for significant changes. Three big risks for significant changes include:

• Time to release. Aim to deliver tangible value as soon as possible. And then continuously add more value thereafter.

• Logical progression. Don't shift the product so much that you can no longer sense check what has come out, or that users feel lost.
• Future proofing on a hunch. If you are not solving a real problem validated with data - from many correlated angles - then you are making stuff up. Don't waste time making stuff up.

Poorly written code is a kill joy. While you want to work as efficiently as possible, rushing significant changes out the door is a bad idea. If you need to get work out in a hurry, it's better to reduce functional scope over compromising on quality. No engineer wants to spend their life up against a code base built in haste. This will also cost you and your customers in the long run.

Be transparent, always. We forecast how long we think the work will take, in actual time - updating our forecasts weekly. Our Joy Board in our Notion workspace has two views. A Gantt chart, and a Kan Ban view. All large chunks of work are forecast and described here. This includes work across all our engineering crews and data science.

We share our forecasts with all our stakeholders, customers included. Towards the tail end of a long project we will set a hard release date. We commit as a collective, rather than having a date set on anyone's behalf.

Figure 12 The Joy Board - A Gantt Chart in which we forecast all work

‍