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.
8
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…
Is there a better estimation/technical specification model that cater
for this kind of environment?
-
Try using Steps of the Scientific Method
-
Try Evidence Based Scheduling