I'm coming back to a topic I've been talking about when prioritizing tasks, which is how to estimate the complexity of tasks.

This week, we'll go into more detail about how to make a realistic estimate that makes sense for the team.

It is not always common in construction to accurately estimate the time spent designing as an architect, engineer, or BIM manager.

This is probably due to the way of invoicing a project as a project manager, which is often lump sum and therefore does not require proving the time spent to its client.

Nevertheless, it is important to estimate the time or at least the complexity of a task. This is to be able to work in agile iterations and to avoid the tunnel effect.

That is to say, the fact of being stuck on a task without the customer or the other participants seeing any results and being able to influence the project in one direction or another.

Tunnel effect in the design process for image

Why estimate?

But first, we have to ask ourselves why it is essential to have a number that gives us an idea of the complexity or the time spent working on a subject.

Because outside the context of agile, one might think that estimating is ultimately using a method that is a bit "old school". That it is also constraining us towards our superiors or customers. Indeed, if we announce an estimated time, our project managers will remember it. And if things do not go as planned, which in the building industry is common, it must be admitted, it may work against us!

Firstly, if you don't take the time to estimate the complexity of a subject, you can end up with a task that is too long and enter a "tunnel". From which you will not be able to get out until well after the current iteration. Taking the time to estimate also means taking the time to define priorities. It means taking the time to understand what needs to be done. And it's also about reducing the unknown by cutting, comparing and discussing with the team.

Points, rather than hours

We will see that agile approaches propose several ways of estimating, all of which have in common that they do not use a precise count (hours, man-days) but points or other units of measurement. Arbitrary points then, either by using a mathematical sequence (Fibonacci sequence), or a size scale used in the textile industry (XS, S, M) or whatever you prefer!

So, nothing that would allow a manager in theory to take this number as an assurance, that the work must be done in X hours. Indeed, the problem with estimates is that they introduce a rigidity that, by definition, we don't want in Agile. But conversely, not estimating is just moving forward into the unknown and making last minute choices to prioritize what can be delivered and not what is most important!

This is why Agile estimation methods often use point systems to avoid falling into the trap of precision, which does not exist in reality.

Agile estimation methods

There are many estimation methods in Agile approaches, but I'll introduce you to the main ones. I'll go into more depth on this in my upcoming Agile BIM training currently in preparation!

Pocker planning, or how to turn estimation into a game

A typical game of pocker planning

The pocker planning is the best known of the estimation methods, as it is the one commonly used in Scrum. The pocker planning allows you to make the estimation meeting fun by turning it into a game.

So, you can propose to your team to make a pocker game, with some special cards. This game consists of cards with numbers, which correspond to the Fibonacci sequence, a sequence of increasing numbers clearly separated from each other such as 1, 3, 5, 8, 13..... As well as special cards, when you can't estimate.

The principle is that after a description of the task (or user story), the team members give an estimate in points without consulting each other and therefore without influencing each other. If the score differs, a discussion follows to clarify why one person voted less or more. And the team chooses one of the versions or finally votes again.

It is therefore, beyond the simple estimation of tasks, a way to clarify everyone's understanding and to better define what needs to be done.

Le T-shirt Sizing, the gut feeling estimation

T-shirt sizes

When you want to have a medium-term vision of the workload needed to accomplish a part of the project. It is sometimes impossible to list all the tasks in detail. Indeed, by definition, some tasks are too vague, and we don't know precisely how to break them down. Nevertheless, either we do nothing, and we remain in the unknown. Which is of course possible!

Or, we adopt a more coarse approach than the previous one, by choosing a unit of measurement in the image of our uncertainty, the t-shirt, and more exactly its size.

The idea of this estimation is to measure the level of uncertainty of the team members and to see if it converges or not.

For example, if all members are vague about what to do on a task, they can decide to estimate it in XL. Whether the task is complex and long, or simply ill-defined and therefore too vague, is ultimately the same.

All tasks with T-shirt size XS, S, M are kept. Those with high sizes are intended to be re-cut to simpler tasks, and therefore can be finished more quickly.

L'Extreme quotation, the great means to overcome the unknown

The estimation of the extreme, the extreme quotation

Perhaps the name of this Agile estimation method is a bit exaggerated! But it is related to the Agile method called "Extreme programming", from where we also get the notion of test-driven development.

What is extreme here is not any danger, as in extreme sports, but rather the time allocated to the decision. Each task or user story submitted for estimation is only allowed five minutes, divided between a very brief presentation, 1 or 2 questions maximum from the audience and finally a team vote in the same way as in pocker planning.

So what is the purpose of this practice? It is rather adapted to get a first estimation, to force the difficulty of some people to express themselves even with very little information, to gather the team's intuition. It forces the person explaining to be very synthetic, without getting lost in the details.

As in T-shirt sizing, this practice is rather adapted to a rough estimation upstream to have an order of complexity and to make choices between several solutions according to their development cost.

No-estimates, and if we don't estimate after all?

caption for image

And yes, it may seem paradoxical, after having detailed the advantages of estimating in Agile mode, rather than estimating nothing and starting directly to work. To finish, as it were, at the starting point!

However, a movement is developing, led by agile coaches using Scrum, who believe that, in the end, estimation work is problematic. Because it introduces expectations in the customer or the person who asked for this work. And that very often the estimates remain too approximate, i.e. they are not worth the time spent to produce them.

Nevertheless, one thing is not questioned in this approach, and this is why it is necessary to distinguish it from the total absence of estimation. It is the organization of work in sprint or iteration. The reasoning is as follows: the purpose of estimates in Scrum is to be able to choose work items that can be completed in a sprint. And to do this, eliminate the topics that are too important by overlapping them. In the no-estimate, only one question is asked. Does this topic fit into a sprint? No subtlety to know if it is small, medium or large. If the whole team answers yes, then we take it on board.

Finally, it can also be a way to start with the estimates in a very simple way. Indeed, one of the fundamental points of Agile estimating is to learn how to break down the tasks to finish them regularly in order to receive feedback from the customer and other project stakeholders.

This brings us to the penultimate chapter of this agile training for architecture professionals, why it is essential to show the project regularly.

But until then, I've got you covered with a little to-do list as usual to get into action with agile BIM and agile estimating!

📅 En practice : Organize a pocker planning session

I advise you to start with this approach which is the most common one to give you an idea of what it is about.

✅ Prepare a list of tasks or user stories, which you think are priorities for the next sprint, limit their number for a first session

✅ Check that the tasks are detailed enough or at least that you can explain them clearly

✅ Buy a set of pocker planning cards, or sign up for one of the many online services that allow you to do sessions, even remotely

✅ Plan a one-hour meeting to explain the principle of pocker planning and take action, invite the whole team to have the different points of views

✅ Once the estimation is done, transfer the result to your favourite agile task management tool, for example Bricks specialized for architecture or JIRA, a classic agile tool that is a bit complex though

In conclusion

It's not very complicated, and I think the team will like it. Because it is also a moment of relaxation and conviviality, which is the occasion to talk about the project instead of "unrolling" without thinking.

So I'll see you next week, when we'll talk about the most effective way to show the project in progress during regular meetings with the client. Why it's important to do this, and why the client should be included in the design team to provide feedback.

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.

I'm coming back to a topic I've been talking about when prioritizing tasks, which is how to estimate the complexity of tasks.

This week, we'll go into more detail about how to make a realistic estimate that makes sense for the team.

It is not always common in construction to accurately estimate the time spent designing as an architect, engineer, or BIM manager.

This is probably due to the way of invoicing a project as a project manager, which is often lump sum and therefore does not require proving the time spent to its client.

Nevertheless, it is important to estimate the time or at least the complexity of a task. This is to be able to work in agile iterations and to avoid the tunnel effect.

That is to say, the fact of being stuck on a task without the customer or the other participants seeing any results and being able to influence the project in one direction or another.

Tunnel effect in the design process for image

Why estimate?

But first, we have to ask ourselves why it is essential to have a number that gives us an idea of the complexity or the time spent working on a subject.

Because outside the context of agile, one might think that estimating is ultimately using a method that is a bit "old school". That it is also constraining us towards our superiors or customers. Indeed, if we announce an estimated time, our project managers will remember it. And if things do not go as planned, which in the building industry is common, it must be admitted, it may work against us!

Firstly, if you don't take the time to estimate the complexity of a subject, you can end up with a task that is too long and enter a "tunnel". From which you will not be able to get out until well after the current iteration. Taking the time to estimate also means taking the time to define priorities. It means taking the time to understand what needs to be done. And it's also about reducing the unknown by cutting, comparing and discussing with the team.

Points, rather than hours

We will see that agile approaches propose several ways of estimating, all of which have in common that they do not use a precise count (hours, man-days) but points or other units of measurement. Arbitrary points then, either by using a mathematical sequence (Fibonacci sequence), or a size scale used in the textile industry (XS, S, M) or whatever you prefer!

So, nothing that would allow a manager in theory to take this number as an assurance, that the work must be done in X hours. Indeed, the problem with estimates is that they introduce a rigidity that, by definition, we don't want in Agile. But conversely, not estimating is just moving forward into the unknown and making last minute choices to prioritize what can be delivered and not what is most important!

This is why Agile estimation methods often use point systems to avoid falling into the trap of precision, which does not exist in reality.

Agile estimation methods

There are many estimation methods in Agile approaches, but I'll introduce you to the main ones. I'll go into more depth on this in my upcoming Agile BIM training currently in preparation!

Pocker planning, or how to turn estimation into a game

A typical game of pocker planning

The pocker planning is the best known of the estimation methods, as it is the one commonly used in Scrum. The pocker planning allows you to make the estimation meeting fun by turning it into a game.

So, you can propose to your team to make a pocker game, with some special cards. This game consists of cards with numbers, which correspond to the Fibonacci sequence, a sequence of increasing numbers clearly separated from each other such as 1, 3, 5, 8, 13..... As well as special cards, when you can't estimate.

The principle is that after a description of the task (or user story), the team members give an estimate in points without consulting each other and therefore without influencing each other. If the score differs, a discussion follows to clarify why one person voted less or more. And the team chooses one of the versions or finally votes again.

It is therefore, beyond the simple estimation of tasks, a way to clarify everyone's understanding and to better define what needs to be done.

Le T-shirt Sizing, the gut feeling estimation

T-shirt sizes

When you want to have a medium-term vision of the workload needed to accomplish a part of the project. It is sometimes impossible to list all the tasks in detail. Indeed, by definition, some tasks are too vague, and we don't know precisely how to break them down. Nevertheless, either we do nothing, and we remain in the unknown. Which is of course possible!

Or, we adopt a more coarse approach than the previous one, by choosing a unit of measurement in the image of our uncertainty, the t-shirt, and more exactly its size.

The idea of this estimation is to measure the level of uncertainty of the team members and to see if it converges or not.

For example, if all members are vague about what to do on a task, they can decide to estimate it in XL. Whether the task is complex and long, or simply ill-defined and therefore too vague, is ultimately the same.

All tasks with T-shirt size XS, S, M are kept. Those with high sizes are intended to be re-cut to simpler tasks, and therefore can be finished more quickly.

L'Extreme quotation, the great means to overcome the unknown

The estimation of the extreme, the extreme quotation

Perhaps the name of this Agile estimation method is a bit exaggerated! But it is related to the Agile method called "Extreme programming", from where we also get the notion of test-driven development.

What is extreme here is not any danger, as in extreme sports, but rather the time allocated to the decision. Each task or user story submitted for estimation is only allowed five minutes, divided between a very brief presentation, 1 or 2 questions maximum from the audience and finally a team vote in the same way as in pocker planning.

So what is the purpose of this practice? It is rather adapted to get a first estimation, to force the difficulty of some people to express themselves even with very little information, to gather the team's intuition. It forces the person explaining to be very synthetic, without getting lost in the details.

As in T-shirt sizing, this practice is rather adapted to a rough estimation upstream to have an order of complexity and to make choices between several solutions according to their development cost.

No-estimates, and if we don't estimate after all?

caption for image

And yes, it may seem paradoxical, after having detailed the advantages of estimating in Agile mode, rather than estimating nothing and starting directly to work. To finish, as it were, at the starting point!

However, a movement is developing, led by agile coaches using Scrum, who believe that, in the end, estimation work is problematic. Because it introduces expectations in the customer or the person who asked for this work. And that very often the estimates remain too approximate, i.e. they are not worth the time spent to produce them.

Nevertheless, one thing is not questioned in this approach, and this is why it is necessary to distinguish it from the total absence of estimation. It is the organization of work in sprint or iteration. The reasoning is as follows: the purpose of estimates in Scrum is to be able to choose work items that can be completed in a sprint. And to do this, eliminate the topics that are too important by overlapping them. In the no-estimate, only one question is asked. Does this topic fit into a sprint? No subtlety to know if it is small, medium or large. If the whole team answers yes, then we take it on board.

Finally, it can also be a way to start with the estimates in a very simple way. Indeed, one of the fundamental points of Agile estimating is to learn how to break down the tasks to finish them regularly in order to receive feedback from the customer and other project stakeholders.

This brings us to the penultimate chapter of this agile training for architecture professionals, why it is essential to show the project regularly.

But until then, I've got you covered with a little to-do list as usual to get into action with agile BIM and agile estimating!

📅 En practice : Organize a pocker planning session

I advise you to start with this approach which is the most common one to give you an idea of what it is about.

✅ Prepare a list of tasks or user stories, which you think are priorities for the next sprint, limit their number for a first session

✅ Check that the tasks are detailed enough or at least that you can explain them clearly

✅ Buy a set of pocker planning cards, or sign up for one of the many online services that allow you to do sessions, even remotely

✅ Plan a one-hour meeting to explain the principle of pocker planning and take action, invite the whole team to have the different points of views

✅ Once the estimation is done, transfer the result to your favourite agile task management tool, for example Bricks specialized for architecture or JIRA, a classic agile tool that is a bit complex though

In conclusion

It's not very complicated, and I think the team will like it. Because it is also a moment of relaxation and conviviality, which is the occasion to talk about the project instead of "unrolling" without thinking.

So I'll see you next week, when we'll talk about the most effective way to show the project in progress during regular meetings with the client. Why it's important to do this, and why the client should be included in the design team to provide feedback.

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.