Agile, Agile Estimating, Project Management, Survey

Agile Project Estimate Guarantee

Over the last few days I’ve noticed more discussion around the concepts on whether Agile teams should estimate or not. This includes my latest Blog on the subject:

User Story Points versus User Story Hours

Yesterday I read the following Blog post on the 5 reasons you should stop estimating User Stories:

5 Reasons why you should stop estimating

Given the amount of attention this blog has garnered, I felt I needed to provide an opposing viewpoint. The Blog post was very interesting and compelled me to write as I think these discussion points are missing one crucial factor. To summarize, the blog post proposed that these were the 5 reasons why we should stop estimating User Stories:

1)      Estimating User Stories is a waste and the time can be better spent elsewhere

2)      The estimates will be used for blame and cause the team to focus solely on the deadline

3)      Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

4)      Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline. (similar to #2)

5)      The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

What struck me was what was missing from these reasons for not estimating, namely the client. None of the reasons explained why estimating User Stories created less value for the client. And really isn’t that why the project exists?

Estimates, who gets to decide?

The Client does. Sometimes when reading about Agile principles, I fear we are losing that perspective and we are deciding for the client what has value. The reason I believe in Lean so profoundly is that it provides the focus on why we are doing Agile practices. It helps to ensure that we understand the why of what we are doing at all times.

Let’s review the Blog points:

1) Estimating User Stories is a waste and the time can be better spent elsewhere

Whether estimating is a waste is something that only the client can best decide. Estimating is just another project activity that the client will determine if it is required.

So far every client I have worked with have required estimates at some level or another. Whether or not we think the time is best spent elsewhere is immaterial. The client defines value and the value in their value stream. So far, every client I have worked with has found value in estimates as they need to decide whether the initiative satisfies the business case and whether they can acquire the required budget.

2)  The estimates will be used for blame and cause the team to focus solely on the deadline

The fact that estimates can be or may be used for blame is more a comment on a dysfunctional system than a comment on estimates. If estimates can be used in this manner, I would imagine any other deliverable could also be used in this manner. I believe it is the role of a good project leadership team to ensure this doesn’t happen. Not producing estimates is treating a symptom, not the problem.

3) Don’t give estimates as these are promises that are hard to keep. In the end they are going to be incorrect anyway.

Estimates are hard, so let’s not do them. They are going to be incorrect anyway. Let’s just wait until they are actuals and then we can report them and we will have eliminated our risk. But whose risk are we referring to? We have just transferred all of the risk from the project team to the client.  If we are professionals in our craft of Software Development, shouldn’t we be able to provide our expert assessment on the situation? If not, why should the client trust us?

4) Don’t put additional pressure on the development team and cause them to compromise quality to make the deadline.

My opinion on this one is similar to #2. This is more a comment on a dysfunctional system than a comment on estimates.  The comment implies that the team will sacrifice quality to meet an estimate.

This sounds like another instance of treating the symptom and not the problem. If a project manager is holding the team to estimates and not engaging the client with new ideas, then the Project Manager is probably not the right fit. If the client is doing this, well that is certainly the client’s call. It is after all their solution. Quality for the client may be meeting the deadline.

5) The estimates may cause a shift in the project’s priorities due to the fear and uncertainty of large items.

Valid point. But I think this is the correct behaviour. Large stories will shift the priorities because of the perceived large risk they entail. This I believe is consistent with the principles of Agile to take on these large tasks early to minimize risk and learn fast/fail fast. I don’t think this is necessarily related to estimating. In fact, this is a reason why we need to do estimates. Estimates will ensure we identify the large epics as high risk items and address them early. This will help us to fail fast. If we do not estimate, we may leave these this stories as a lower priority and they will be done later and possibly cause project rework.

Next Steps

One critical benefit about providing an estimate to the client is that it completes the commitment cycle. Typically clients commit budget and teams commit to an estimated solution vision. This estimated solution vision is at a very high level that identifies the features and interactions between the features. It is not big requirements or design up front. But the team should have an understanding of the solution vision before starting or the potential is that excessive rework may be required after a considerable amount of work has already been completed.

In short, preparing that estimates forces the project team to understand and envision the entire solution because we are now committed.

Typically Planning Poker sessions produce estimates, but the real by-product is the consolidated solution vision that the entire team, including the client, has after the session. (In addition to the prioritized User Stories) That is the real value. Not producing estimates leaves the project in much poorer state.

The Guarantee

Why do we believe so strongly in this? Because we focus on the end state or the ultimate Solution. By focusing just on the Software Development process and activities you can Sub-optimize and although the Software Development process can be better (however you define better), the overall value of the project can be diminished or possibly no longer apply. Not producing estimates is one example of potentially many where having a focus just on the Software Development process may adversely affect the raison d’etre of the overall initiative.

Just like outsourcing the act of Software Coding can result in less than optimal solution elsewhere in Software Development, not estimating a Software Development projects can create a less than optimal solution for the entire initiative or business.

Protegra believes so strongly that Agile projects can be successfully estimated that we have an offering to guarantee scope and budget with our clients when we are able to execute Custom Software Development Projects in our Lean and Agile Methodology. It is something we have been doing now for over 10 years.

Re-posted from http://bornagainagilist.wordpress.com

About Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Discussion

Trackbacks/Pingbacks

  1. Pingback: The debate about estimating « Protegra - May 20, 2011

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: