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
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)
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.
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.
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:
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