In the previous chapter, we talked about the Plan itself, and the importance of a properly Estimated Task to it. The gap between a Task and an Estimated task is bridged first by minimizing uncertainties. In this chapter, we’ll be learning a hands-on practice to uncover what is the work that needs to get done. A process of discovery which the Task and its owner needs to go through.
The process will end with a collection of certain enough Sub-tasks. Those are executable and actionable items which can be done sequentially. They would all form up something to deliver with a certain enough value, a Deliverable. These Sub-Tasks are a prerequisite to getting a certain enough Estimation, which we’ll learn how to do in the follow up chapter.
It is expected of the solution and its technical design to change while going through this process. As such, it is critical that the owners/engineers would be open for Change and Feedback. To keep their minds open, it’s better to ask the owners for non-finalized designs. To make room for change, in advance.
I will note that it is not the only practice out there, nor am I saying it is a best practice for you. You know best. At the very least, follow and understand the principles described and how it fits in the bigger picture of Planning.
[Note (August 2022): while researching on another matter, I came across a methodology called Adaptive Software Development, which from its description sounds very similar to the concepts about to be presented and practiced in this chapter and in The Winding Road series.]
Deliverables
Every non-final design must be divided into Deliverables.
Deliverables have expected deadlines, the one we set our customer’s expectation by, and commit to. Deliverable type can be divide to two, according who the customer is:
- User Story – a change expected and accepted by an external customer, such as end users, customers, API consumers, etc.
- Technical Task – a change expected and accepted by an internal customer such as other team members, other R&D teams, Customer Success, etc. In Jira terminology it is plainly called Task.
Notice the border varies between internal values and external ones. One team’s external customer may be another team. For another team, the external customer could be the end user.
Deliverables should be short enough to be delivered within a single Sprint. A Deliverable’s effort must be less than the Sprint’s length. We put such a time constraint to make sure we’d be getting feedback sooner than later. If a Sprint’s length is two weeks, at most we must get Feedback on the work done within two weeks.
Be wary of committing to more than one Deliverable per Sprint, as it may leave no time to get Feedback. It is critical because Feedback prevents us from going down the wrong rabbit hole. As it may take time to get it, Plan for Feedback.
A Deliverable must provide a value to a customer. If we delivered no value, we’ve done nothing of value. Be wary of Deliverables that might end up with long fruition processes, or uncertain value or without value at all. Both have the potential to be a time waste, which has dire motivational consequences on the team and the company.
By definition, Technical Tasks do not have external customer value. Some of them are a prerequisite for a User Story, an indirect enabler for a customer value. For example, some new feature (User Story) would require an entire new database with 20 schemas (a prerequisite Technical Task). Both should fit into a single Sprint. If it really isn’t possible, no more than two consecutive Sprints. Because Feedback is a must.
Phase 1: Dividing Deliverables
Now, let’s take our “scalpel” and divide our design into Deliverables by value and feedback. This is mostly done by a product manager, hopefully with an engineer’s aid. But engineers can and should know how to do this on their own.
A design or an already divided Deliverable should be further divided, as long as one the following applies:
- It helps someone in more than one way
- It helps more than one person/actor
- Provides more than one value
- Enables more than one thing
- Feedback/outcome in not certain enough
- Feedback might save work
Yes, it’s a recursion! My apologies, but let’s practice this with an example.
Our imaginary application currently allows a customer to browse (paging) an alphabetically sorted list of 10k items. Our design adds a search box to do a free-text search, and then filter the search results by category.
Our imaginary application currently allows a customer to browse an alphabetically sorted list of 10k items, by pagination. Our User Story is to add a search box to do a free-text search, and then filter the search results by category.
It’s easy to notice that the User Story helps a customer to find an item in more than one way, by search and by filter. There is a clear division to be made, to at least two Deliverables. As they preferably should be independent, it suggests that filtering should be available even when searching isn’t. We ended up with not two, but three Deliverables. Each with a single external customer value.
| Deliverables | Sub-tasks |
| (1) Search by free-text | |
| (2) Filter by category | |
| (3) Filter search results by category |
This division allows us to choose whether to deliver (1) or (2) first. We may deliver (2) only to find out that nobody filters by category. It may occur because division created an opening for Feedback. We created the option to maybe stop and rethink the whole thing, to save time and not go down the wrong rabbit hole. And that would be sooner than after executing all 3 User Stories combined. A very beneficial outcome!
We may deliver (1) and find out we have helped our customers to find an item, more than enough. It may turn out that (2) and (3) are not as valuable as we thought and shouldn’t be worked on, for the time being.
These are the results, insights, timing and flexibility we’ll be getting with effectively divided Deliverables.
The outcome could probably be more than one Deliverable. If multiple ones share a mutual goal, Deliverables can be aggregated into an Epic. The first Deliverable should be certain enough. Once delivered, we’d get Feedback and Change would follow. Meaning, the rest of the Deliverables would Change, which is why currently they can not be certain enough.
An Epic Journey
A solution/design will most likely have more than one Deliverable. If multiple ones share a mutual goal, Deliverables can be aggregated into an Epic.
Be wary, we may have found out we have a Roadmap in our hands. Will deeply dissect those in the next series on The Winding Road.
For now, we only need to make sure only the first Deliverable is certain enough for execution. And the rest should retain some uncertainty. That is because once the first is the delivered, a Feedback would follow. And Change follows Feedback, meaning the second and third and the rest of our Deliverables would soon change as well. Putting too much effort into removing uncertainty at this stage would be non-beneficial.
Sub-Tasks
Deliverables should consist of Sub-Tasks, correctly sized executable units. It would make the execution progress far more measurable and trackable. It would also create a sense of advancement and achievement for the team.
On the contrary, A User Story may already be correctly sized and executable, such as a to minutes effort to changes a CSS color. There’s no need to divide those into Sub-Tasks.
The smaller the Sub-task is:
- The less uncertain it is, because it is short and well defined.
- The smaller the mean and variance is. Thus the Estimation’s buffer would be more certain.
- Entail shorter and focused Code Reviews, which eases up the development workflow.
A correctly sized Sub-task must be independently deployed to production. If we have three sub-tasks for a single application there would be three deployments. Once after each Sub-task is done.
If we need to change three applications there would be at least three Sub-tasks, one per application. Such as one change to the database, one change to the frontend application and one change to the backend application.
It is a technical hands-on matter. We cannot assume multiple application can be deployed together or sequentially. Not doing so, would also make reverting harder to do and decrease our Velocity.Design to Fail.
A correctly sized Sub-task once deployed must make progress. It must provide an internal or external value, preferably minimal. Or must eventually enable an indirect external value.
A correctly sized Sub-task must be complete, ready for usage and consumption in production. Or at the very least, it should not cause harm to the state when the code is executed, such as data corruption. Do not blindly count on flags to merge or deploy unfinished or untested code. I’ve seen flags turned on by mistake in production.
Phase 2: Dividing Sub-tasks
Now, let’s take our “scalpel” again and divide our first Deliverable to Sub-tasks. Starting with the first User Story of “Search by free-text”. It is deeply technical, so it should be done by engineers with a product manager’s aid and availability for continuous input and design changes.
At least two engineers should take part in this. One who is the owner, the deliverer. As it’s her hands coding, it should be her hands defining these Sub-Tasks. The other should be one who is highly familiarized with the code (domain lead, tech lead, architect, etc.) to provide necessary thoughts, insights and alternatives.
On the contrary, hands-on coding of a Deliverable done by more than one engineer may create a communication overhead and delay delivery. One engineer may not be capable of doing it entirely on his own, yet. Use this opportunity for teaching and growth, to postpone the inevitability of an engineer being eventually gone.
Let’s bring everyone on board for an initial internal feedback process. Start with the product manager or the technical design owner, explaining what’s behind it. What are the customer and company’s needs, goals and expected outcome. Getting everyone’s feedback and input is how we reduce uncertainty, how we make sure that the Task and value are certain enough.
Next, have all the engineers open their computers and have all the relevant code and applications right before their eyes, either in their IDEs or Github.
Ask the owner-engineer “what is the first thing you need to do?”. His answer would be the name and content of the first Sub-task. “Okay, what’s the next thing you should do?”. Validate with him the Sub-task is still correctly sized as we defined above – makes progress, independently deployable and complete. If it’s too big, divide it to another Sub-task and validate that both of them are correctly sized.
While they do so, it is beneficial and necessary for everyone, engineers and others, to ask for clarifications and validations. To Google and look for answers. That’s what changes the non-final design and the Deliverables, reducing their uncertainty. It may even lead to further division into more Deliverables.
An engineer might know what needs to be done, but lacks the knowledge of how to get it done. As the requirement of learning is 100% predictable and time consuming, add a Sub-Task to it. Same goes to adding a “Product Change Request” Sub-task, because we Plan for Change.
Continue with “Okay, what’s the next thing you should do?” over and over again. The process of uncovering works ends when everyone agrees that they know what and how the Deliverable gets done. Eventually, we would end up with the following collection:
| Deliverables | Sub-tasks |
| Search by free-text | A |
| B | |
| C | |
| D | |
| (Another deliverable) | |
| (Another deliverable) |
Should we continue dividing the next Deliverable? If they are tightly coupled, one enables the other or executed immediately after, then we should consider doing so. It may further reduce the uncertainty of the first one.
With a Deliverable correctly divided into correctly sized Sub-tasks, it is ready for Estimation. The summation of uncovering work is uncovering the effort required to get it done. We’ll learn the practice of doing so in the next chapter.