🧩 The art of splitting long tasks in construction

I hope your Agile organization is starting to bear fruit. After priorities, and working in iterations, we will see how to practically break down tasks, which seem long and complex, into simpler ones.

Breaking down a complex task into smaller, simpler tasks

How to do this task splitting practically so that at each iteration :

👉 Value is delivered to your client or project users

👉 Ideally, the tasks are "finished" at each iteration

Working in iteration or the art of cutting

In the design of a building or an urban planning project, some tasks can seem very long and almost endless. At least until the construction site, where a decision has to be made. But often too late and in a hurry.

It is however possible to do otherwise and to cut the tasks into smaller ones. Those smaller tasks can then be completed and submitted to the client for validation "as we go along" and not at the end of a long process like a phase.

The advantage of this approach is multiple:

👉 Frequent validations from your client are confirmations that secure your work

👉 "Finishing" and making visible even partially a task allows your client to make remarks and enrich the project

👉 Each iteration requires a prioritization. As a result, there is less risk that you will waste time working on tasks that won't be useful.

Yes, but how to break down the tasks efficiently: The INVEST method

In scrum, there is a method, which is very popular to check that the split of tasks is the right one. It is the INVEST method.

INVEsT is in fact an acronym that I will explain to you now.

I for independent

In order for iterations to work, the tasks (user stories in Scrum) must be independent of other tasks. Indeed, if this is not the case, they might not be finished at the end of the iteration. Sometimes, there are unavoidable dependencies between tasks, but it is important to know them in advance.

N for Negotiable

In Scrum and agile approaches, it is important to have a constructive dialogue between the client and the project team. It is less a customer-supplier relationship, but a more collaborative relationship that should be sought after. Sometimes the client, who does not realize all the implications of his choices, can unnecessarily complicate the work of the project management. If there is a simpler and equally effective way to do the job, it should always be possible to "negotiate" and do a task differently or even not do it at all if it is not unnecessary in the end.

V for Valuable

In Scrum, it is important to focus on the value brought iteration after iteration to the customer. It is obvious that some tasks have no direct value for the customer, like "cleaning up the Revit model". But it is still crucial to do it regularly. However, it is best to mix tasks, which have direct customer value, with those that have less value when possible. For example, "clean up the BIM model on the occasion of the new floor plan" allows combining a technical task with a task that has a high added value for the client.

In addition, for all tasks that have customer value, it is possible to specify how much. For example, defining the facades of the building can be very valuable, as it facilitates the sales process.  Practically, in your agile task management platform, you can create a "business value" or "customer value" field, in which you estimate the customer value to have it in mind and be able to prioritize the tasks according to it.

Es as in Estimable

One of the goals of Scrum is to improve the predictability of the team's work. If you don't estimate the time spent or the difficulty, you can't be sure that the tasks will fit in the iteration time. In Scrum, we generally use a point system (1-3-5-8-13-21) rather than estimated hours. This avoids the need to be precise and the risk that the client will take the count literally. Even less, that he will use this information to pay you!

No, the goal is not to be liable for an estimate, but rather to evaluate if the task is feasible in this iteration. And to allow, during the meeting, to estimate the tasks, to better understand what needs to be done and to ask all the questions that will allow to better define the work to be done.

The sum of the estimates of each task gives a figure, which is compared with the performance of previous iterations, to know if it is realistic to finish this task in the iteration.

T for Testable

This criterion is very important in software development, because it is about testing that the delivered code works. Either manually by reproducing a given scenario, or automatically with automatic tests. In the field of architecture and with BIM, the concept of automated testing has started to emerge, and this is a good thing!

The idea is that a software will execute a series of automatic tests to check the rules of construction, the consistency of the model... So a task that is testable is a task that produces a result that can be evaluated in one way or another.

Let's take the example of a bridge. Let's suppose that the goal of the iteration is to define the profile of a bridge, and that the bridge must meet a certain number of constraints: height under the deck, resistance to a specific traffic... It must be possible to test either manually or automatically that the new iteration allows the structure to meet the previously defined standards.

📅 In practice: organize your next iterations with the INVEST method

Okay, the INVEST method is interesting, but now you need to put it into practice. If you're already working with iterations, maybe you plan these iterations in meetings? In Scrum, these meetings are called "Sprint planning". If you don't already organize this type of meeting, I strongly encourage you to start doing so.

To prioritize the tasks to be included in the sprint, you now have 2 tools:

👉 priority management with the Eisenhower matrix (which we saw in the previous email)

👉 the art of splitting tasks with the INVEST method

So it's up to you to include them, and here's what you can do:

✅ On each task you want to include in the next iteration

✅ Ask your team if this task is in line with the INVEST principles

✅ Try to solve the problems that may arise if the task does not meet them

To help you a bit with problem-solving, here are some possible answers:

❌ Task not independent

✅ Cut it out so that it is

✅ Or manage the dependencies by starting with the task that will unblock the other

❌ Task not estimable

✅ Specifies the job and its description to make it so

✅ Or cut it out, too big a task is hard to estimate

❌ Task with no customer value

✅ Combine tasks without direct values with tasks with customer value

✅ Make sure enough tasks with strong user value will be chosen in the next iteration

Finally, don't forget that the sum of the task estimates must go into an iteration. At the end of this iteration, most of the tasks that are planned to be finished must be finished. If this is not the case, you have to think about improving the list of tasks for the next iteration.

Learn how to use Agile methods for construction projects thanks to our free training by email. You will receive emails like this to move forward with agile.