Agile Zone is brought to you in partnership with:

George Dinwiddie is an independent software development coach who helps organizations, large and small, to increase the effectiveness of their software development efforts. He provides guidance over a broad range, at the organizational, process, team, interpersonal, and technical levels. He is currently crusading to break down the barriers that hinder effective collaboration between the business, the programmers, and the testers. George is a frequent speaker at Agile conferences. George is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

The Date Question

07.02.2013
| 2666 views |
  • submit to reddit

A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.

Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. I’ll grant them that this is a fine strategy for building software, but It doesn’t give an answer the question.

Should you give an answer to the question? Often people worry that their estimate will be treated as a commitment, and they’ll be found at fault if the date is not met. Too often this is the case. In such an environment, refusing to give an estimate will likely not enhance your reputation, either.

Assuming that the question is actually asking for an estimate, telling the questioner that they don’t need an answer seems a bit presumptuous and disrespectful. Who are we to decide that their question is of no value? It seems to have value to them. Maybe it would be better for us to learn why it has value to them.

With two options, we find ourselves between a rock and a hard place. We either make a lot of assumptions and do a lot of work for a date that may have little value, or we take an opposing stance to the expressed needs of the questioner. But what really are those needs?

If I’m feeling comfortably safe, I might answer the the Date Question with “42.”

“42? What kind of date is that? What do you mean?”

“What do you mean by ‘when will the software be done?’ What will you do with the answer?”

When we ask the Date Question, “When will this software be done?,” we have more in mind than a simple date. Perhaps we thought it should be done by now, and we’re expressing our impatience. Perhaps we’re getting ready to start, and we want to put time pressure on the development team so they’ll work as fast as they can. Neither of these thoughts have much to do with an estimate, though the request may be formatted as if it were asking for one.

We might, however, be trying to make a decision. Perhaps we want to know if we’ll have a viable product by the Christmas season, or in time for an industry conference. Do we have time to undertake this project? Or perhaps we want a rough idea of how much the project will cost, multiplying the duration by the cost of the development team. If we compare this cost with the expected value of the developed software, is the project worth the investment? Maybe we need to produce packaging, or training courses, in parallel. When will these things will be needed? There are many perfectly valid reasons for estimating the end date of the project.

Published at DZone with permission of George Dinwiddie, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ian Mitchell replied on Wed, 2013/07/03 - 4:35am

"Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. I’ll grant them that this is a fine strategy for building software, but It doesn’t give an answer the question."

OK, but is the question going in the right direction? Stakeholders such as the Product Owner should decide when a project is done (business value satisfied), while development teams provide that value iteratively and incrementally.

On that basis, it seems quite reasonable for teams to throw the question back. 

George Dinwiddie replied on Wed, 2013/07/03 - 2:38pm in response to: Ian Mitchell

Ian, how does the Product Owner know when the project is done? Should they not look ahead, into the foreseeable future? If the Product Owner looks ahead, should they do that without collaborating with the development team? Should they make their own assumptions about the potential development cost of things they want in the future?

Ian Mitchell replied on Wed, 2013/07/03 - 3:40pm in response to: George Dinwiddie

Hi George

Only the Product Owner can decide when the project is done (i.e. when the product will be complete). The ability of the Development Team to make a forecast is limited to the currently planned Sprint. The Sprint Backlog, and the associated Sprint Goal, are representative of that forecast.

It's certainly fair for the Product Owner to collaborate with the team on what "done" means for each Sprint (i.e. on the Definition of Done). It's also fair for the Product Owner to expect metrics which would enable a longer term forecast to be made. However, it would not be fair to hold the Development Team accountable for something that is beyond their remit, such as when the product will have delivered sufficient business value for the project itself to be considered "done". That's what Product Ownership is about...and that's why the question would be a fairer one if the team were to ask it of the Product Owner.

George Dinwiddie replied on Sun, 2013/07/07 - 6:42pm in response to: Ian Mitchell

In Scrum, the Product Owner says whether or not the product is complete. That is a different question from when it will be complete. In practice, the Whole Team will be involved in both questions.

It would be silly to say the development team is limited to forecasting the current sprint. They can forecast anything they want, given their current knowledge.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.