Efficient way to create a code estimation/technical specification in a fast-moving environment

Question

To better understand my question, let me elaborate the background of the subject matter.

I work in a financial institution where the business module (credit finance) is constantly changing. In the IT world, however, the developers have a 6 week cycle taking list of projects/enhancements, put it in a timeline and business expect delivery on those projects.

During each cycle, each developer gets assigned work that needs to be completed by a certain date. That date is already finalized by IT Change Managers and codes must be done by then. The code will then be synced, built to create a package and deployed to the test environment for QC (Quality Centre) team to test.

The problem, however, is that developers get given the code 3 weeks before the code cycle ends. We are then told to do a technical specification and work estimation for each project/enhancements/bug fixes we are going to do. I have constantly talked to my managers that that is a backward mentality having to do estimations knowing when we need to deliver the finished code.

My challenge: Is there a better estimation/technical specification model that cater for this kind of environment? If not, how can I tackle this issue such that it doesn't conflict with the deadline.

Thanks.

PS: I totally disagree in providing a business requirement to developers and expecting them to do a technical specification document as well as estimations during a code cycle. I do believe that technical specification document should be done before-hand and completed as well with functional/non-functional document and signed off by business. This is not happening currently.

If the deadlines are strict, than the only way is to exclude some features to be able to deliver the project on time. And also, your management should be aware that writing specs and estimating also takes time, which you could spend on development otherwise. — superM, Mar 30 '13 at 20:19
@SuperM, unfortunately, failure to do these specs and estimations affect our Key Performance Appraisal extensively. — Buhake Sindi, Mar 30 '13 at 21:02
+1 for "I do believe that technical specification document should be done and completed as well with functional/non-functional document and signed off by business." — Md Mahbubur Rahman, Mar 31 '13 at 13:38
You may wish to look into [Software Estimation: Demystifying the Black Art](http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351) — , Mar 31 '13 at 15:20
possible duplicate of [Real world Agile practices and estimates](http://programmers.stackexchange.com/questions/63429/real-world-agile-practices-and-estimates) and of [How to explain that it's hard to estimate the time required for a bigger software project?](http://programmers.stackexchange.com/questions/102856) See also: [Getting non-programmers to understand the development process](http://programmers.stackexchange.com/questions/4), [How to learn to make better estimates?](http://programmers.stackexchange.com/questions/16326) — gnat, May 22 '13 at 10:27
In looking at what you do, it seems to me that most of your enhancements would just be variations on a theme. In this case, keeping historical metrics are one of those rare true silver bullets. The trick is in picking the right metrics and categorizations. Picking categories will take some trial and error, but as history builds over time most of your estimates will be able to come from knowing that enhancements in "Category A" have historically taken between 3 to 5 days. Estimates can become fairly quick to do and reasonably accurate. But it does require the discipline to collect metrics. — Dunk, May 23 '13 at 14:36
Just estimate every item as `AvailableRessourceTillDeadline/NumberOfWorkItems`, which is quick to do and just as useful as any other estimate given your circumstances. — Patrick, May 24 '13 at 11:09
An estimate answers the question, "How long will it take to build X?" Your actual job seems to be trying to answer the question, "What do we need to do to deliver X by target date Y?" They're not quite the same thing. — Mike Sherrill 'Cat Recall', Sep 17 '13 at 14:20

score 1 · Answer 1 · edited May 24 '13 at 08:51

The idea of doing a schedule estimate at the phase of the cycle where you get to do it is ludicrous.

Since you are time-boxed from the outset, you should look at an Agile methodology like SCRUM which tries to provide visibility and transparency for project progress in hopes of simple forecasting based on prior code deliveries.

See article When to Use Scrum for software projects?

Scrum is often contrasted with the so-called “Waterfall” approach, which emphasizes up-front planning and scheduling of activities, followed by execution. Both approaches require careful planning, followed by execution and tracking, but the details of how these steps are accomplished are different...

Why Choose Scrum versus Waterfall for Software Projects?

The two approaches make different assumptions about the priorities and practicalities of the work to be accomplished...

In general, if you have to figure out how to do a significant amount of the work in the project because you haven’t done it before, so you cannot estimate accurately, go with a Scrum process. If you’ve done it many times before, and know how to do it again, go with a waterfall process...