Tackling your Epic product problems — using DIY thinking

So far on our journey of using DIY thinking to address Product Management thought processes we have traversed through two key steps; deciding that something needs to be done (part I), and then defining your problem (part II).

Once you know that something needs to be done, and you have then defined what that problem is, we can get down to the bare bones of the issue — how to tackle that problem.

Breaking the problem down

For those who have been following along, this may feel like treading old ground… we’ve already broken down our problem (the bedroom being outdated) into a number of different parts; the carpet needs changing, the walls need painting, the wardrobe needs something doing and we need some new curtains.

“Two paintbrushes of varying size dipped in paint lying on table, California College of the Arts” by William Felker on Unsplash

These may seem to be small parts but inevitably when you’re looking at your product problems they can more often than not be broken down further.

In agile we often call these larger pieces Epics.

In a Scrum team we can break down these epics during a scoping meeting, maybe over the desk after a chat, or an insightful product manager might do this themselves but the reason we do this is clear;

Reducing your epics down to the smallest testable or releasable tasks is essential to ensuring your deliver your items in the most efficient way possible. [tweet this]

Looking at the walls, the task we have currently is that the “walls need painting” — this is so high level that it is actually unhelpful to try and tackle.

So let’s look at this a bit closer— what paint do we use? What colour should it be? Can we paint straight over the existing wallpaper? Do we need an undercoat?

The answers to these questions actually fall into two different camps — discovery and delivery — but the combination of each ends in very distinct releasable tasks.

In truth discovery and delivery should be ongoing together, hand in hand, with the discovery driving the delivery — in an Agile sense this is called Dual Track Agile. (That said, for now we’ll be considering them as parallel items but see our next instalment for more information around this.)

For our example of “painting the bedroom walls”, we can break down tasks as follows:

Discovery: Assessing the plaster, choosing a paint type (matt or gloss), choosing a paint colour

Delivery: Stripping the wallpaper, plastering the walls, painting an undercoat, masking the skirting boards, rollering the walls, cutting-in the edges

These lists are non-exhaustive and some may be things we don’t actually need to tackle. However, you will see there is crossover over of when things can be tackled.

By following a continuous process of discovery and delivery Dual Track Agile allows us to not only determine if something needs to be done, but also to plan when it is done

In this example you’ll maybe notice that before we can do any of the things on the list the “stripping the wallpaper” task has to happen — without this we cannot find out whether the plaster needs doing or start on any of the other tasks, as the existing wallpaper is in the way.


But what order should we tackle the other items? For us truly take time to look at this, we can’t just look at the “Paint the Walls” item in isolation, but also need to include the broken down pieces of our other tasks to ensure that we are not holding resources for one task when they could be working on something else.

For example, one of the tasks associated with changing the carpet is removing the old carpet — this can be done at various stages;

Maybe you want to reuse the carpet, so you want to remove it before you start on the painting.

Maybe instead you want it there as a backup in case your dust sheets fail.

Maybe it just doesn’t matter to your flow and you’ll remove it as soon as you’ve got a spare twenty minutes between other tasks.

Often you may not know the answer to these questions until you start on a different part of a different task.

If you lift up that carpet and find beautifully polished floorboards underneath, then maybe the tasks needed can actually be reduced. On the other hand if you lift it up and find the floorboards are rotten then once again we have to add tasks to the backlog.

This back and forth is common in delivering a product, and is why agile delivery is not simply straight forwards and cannot be accurately expressed in traditional tools like Gantt charts (I will cover this in more detail in a future article).

The most important thing to remember is that:

Every product backlog item should be the smallest possible piece that is independently testable or releasable. [tweet this]

Stripping the wallpaper is a testable piece — you can only test that you have removed all of the wallpaper once all the wallpaper is off. Until then the job is not complete, is not testable (as there may be something hiding under the bit that is left on) and is not releasable. The job may not be finished, but it plausibly could be (if somehow the walls underneath were polished marble for example)

By following this rule it allows you to effectively prioritise the backlog, plan the order of tasks and allow your discovery to drive your delivery


Breaking your epic’s down into smaller product backlog items is an integral step to being able to accurately tackle your Epic product problems

Using DIY thinking means we can look at this problem with a practical mindset on this breaking down process which will help when addressing some more difficult pieces of work.

Occasionally, the breaking down is not always obvious, and sometimes it isn’t required or doesnt make sense, but working together with your Scrum team and discussing these pieces of work will make the the scope of work clearer and everyone happier!


Next time we will dive a bit deeper into the Dual Track Agile discovery process and how this works within our DIY Thinking mindset.