Breaking Down Big Items to “Chewable” Size
In our last article about refinement, we briefly mentioned a practice called “Taking a Bite”. You can access the article here!
Today, we will dive a bit deeper and look at the actual process of doing it!
How do we take a bite, practically?
The practice of taking a bite is simple but hard to do. Even after our second year of adopting the agile journey, our teams are still confused about the practice. It’s common for us, agile coaches, to get questions like:
- “How to practically take a bite?”
- “What does bite size mean?”
- “How small is too small?”
This article is an attempt to answer those questions. But before we dive deeper, let me clarify one important point first: this should not be taken as an authoritative source on taking a bite practice. Instead, consider this as a reflection or perhaps the first step to grasping the “taking a bite” concept better.
Also the underlying assumption here is that teams are cross-functional and components are shared across teams. It’s very difficult to do this if your teams are still arranged based on components.
Now, to answer the first question, practice taking a bite in 2 steps:
STEP 1: Understand the Big Picture
Slicing typically makes little sense if you don’t see the big picture. This is where the background and context of why the item needs to exist is very important. Typical questions to “pull information” are:
- What value does this item provide to our customer and/or business if it is done?
- What will happen if / what are the risks of not doing this?
Product typically comes to refinement with this information. That being said, he/she may not have complete information at the time, and that’s expected. The questions above intend not to interrogate but to have a shared understanding of the why.
STEP 2: What is the minimal minimal value? Bite-sized?
This is the answer to the second question. After we understand the larger expected value that we want to get, we need to figure out what is the minimal/thinnest value that still provides value for the user.
It might not be complete, but still valuable nonetheless.
Let’s say we have a big item where the why and the expected outcome is roughly known, but we can feel that it’s big, let’s call it a mouthful-sized item.
Based on the information that we have at any given moment, we can take a bite by defining the smaller value. This is what we call bite-size.
This is where the third question often comes blazing in: how small is too small?
Here’s an easy answer:
When completing one “item” doesn’t bring value or uncover risks early (will write more about this in another article about splitting based on risk *wink) without finishing other related “items.” Those items might not be a real, substantial “item” (read: too small).
This typically happens if we slice based on components. With practice, your sense of judgment will grow sharper in sizing up the bites.
How small is too small? When is a backlog item no longer a backlog item? Why do humans exist in this world?
OK, but how do we start practicing this?
There are plenty of thinking tools and techniques that we can use; the following are two which we found useful:
Blackbox test thinking
Rather than thinking about “what are the steps to do to finish this”, we want to think about “if this is finished, what does it look like? what output(s) I will get given this input(s)?”
Imagine finishing an item, we need to change some services like so, this is typical sequential thinking to problem solve:
How blackbox test thinking works is to abstract away all those internal workings, and define the expected behavior of the system under test. See the illustration below to get a clearer picture (pun intended):
This way of thinking is useful when we want to slice items based on results as opposed to components.
Practice Specification By Example
While the Blackbox test thinking is more of an individual technique, Specification by Example puts emphasis on collaboration and the importance of thinking together.
The best resources to learn about Specification by Example is from the creator himself, Gojko Adzic, you can read about this extensively in his blog > Specification by Example articles (gojko.net)
Bonus question: What to do if bite-sized is still too big?
When bite-sized is agreed upon, the team feels that the item is still too big to fit into a sprint, most likely it’s because the teams’ knowledge of the system’s components is uneven. One way that we recommend is for 2 (or more) teams with different component knowledge to take the item together into the sprint and work collaboratively using pair/mob programming technique.
Why? Because, techniques like pairing help with spreading component knowledge faster, which helps teams have a better knowledge distribution, which eventually helps teams to get real “bite-sized” items done earlier.
Slicing based on a component means you split the item too small, and is essentially no longer an item. This is quite common in teams that are arranged based on components and/or just started their journey towards shared code ownership.
Component-based slicing is not recommended because it won’t result in valuable deliverables even when it is done. That being said, each organization is different, so be open and mindful of where the teams and organization are at any given moment when practicing taking a bite based on value.
Want more insider insights on how to solve your team's problems? Follow us and read other articles from DKatalis Way of Working series!
