Agile, Agile Estimating

Why I Like #Estimates #NoEstimates #Visualization

There I said it. I like estimates. I like estimating. I think they provide value to my team and the customers. I will attempt to explain why is this Blog post.

1) Estimates make me think through a solution

I liken estimating to the visualization successful sport athletes do. It is the visualization and mental practice of what is likely to happen. Great athletes use this practice to anticipate issues and try to make every game as successful as possible.

When I estimate I am forced to examine project details and technology and think through the deliverables at a detail level and how we would build them. This helps to identify issues early and give the team and client lead time to decide on a resolution. When you discover issues late in the game, your options are limited and client anger usually follows.

If we just start building without doing detailed design and planning, the chance of project issues increase. I agree that you can do that detailed design and planning without estimating, but due to how estimates are used traditionally they result in people doing more detailed design and planning. This is because people know they are used for financial decisions and require some level of certainty. Estimates matter.

Now I don’t subscribe to estimates being used as promises and never being able to update the estimates. In fact, project estimates need to be updated weekly as new facts are encountered. This frequent updating of estimates needs to be discussed and agreed to before the project starts. Clients need to agree estimates are estimates, not promises or actuals.

2) Estimates create a shared understanding

One may disagree on the value of estimates. But I think everyone agrees that the discussions that occur while estimating are invaluable. These discussions create a shared understanding throughout the entire team. Yes I am assuming you are estimating with your entire team. If you are creating estimates for others then you have bigger problems than just estimates.

3) Estimates allow the clients to validate Minimum Viable Product before we start

Although the No Estimates approach and Story Slicing will allow the clients to have input and control over the work as it proceeds, it is still possible to start a project without the ability to complete a Minimum Viable Product with the available budget. Once you discover you can not deliver the required functionality, you may have wasted considerable budget. It is recommended that projects should not be started that have such a small profit margin. The reality is that most Information Technology projects have a small profit margin.

Will estimating Minimum Viable Product provide a iron-clad solution to this? Definitely no, we will estimate incorrectly at times. But as stated in point 1. The process of thinking through the problem does increase the chances of success.

4) Estimates allow Clients to allocate post Minimum Viable Product budget to other initiatives

In addition, the clients may want to allocate some of the post Minimum Viable Product budget to other initiatives and not to wait to see how a project goes just in case the project needs it. Clients are not going to reserve large budgets just in case an Information Technology project need it. Clients have a very limited budget and there are always more initiatives than budget. Allowing clients just to stop projects at any point does not recognize the lost opportunity cost by not starting additional initiatives that could have placed them ahead of their competitors.

One can even say that while No Estimates works well for one project, it doesn’t allow for the discussions and trade-offs required to manage a large portfolio of projects where the clients need to maximize the number of Minimum Viable Products delivered each quarter.

Summary

These are my reasons as to why I like estimates. It should be noted that I don’t recommend doing detailed estimates in any way shape or form. These estimates should be higher-level estimates that are:

1) At a deliverable level

2) Can be updated every week

3) Are created by the developers and clients

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: