There are some guidelines but they depend on your methodology of development.
I take the time to design and build template forms that have pre-built components for adding, updating, and deleting records. They have events set up for all the controls that need them. They have other things behind the scenes as needed for event logging, error trapping, and other programming ills & necessities. Then I estimate how much of the "typical" form is covered by the contents of the template. Then multiply the number of forms by the time it takes to do one from the template. For my biggest project, that took about two days per form with template starting points.
Since the code wizards are ready to help you for all events, that kind of code almost doesn't need separate estimation. However, when you step out of the normal event cases, you might need to break down each function well enough to name it and place it in the simple, moderate, or complex cases, and allow 1, 2, or 3 days per function.
Invariably, the thing that trips up every new designer is integration of the parts into a cohesive whole. (Which is one reason I used templates - made integration a snap.) You also need testing time. The more forms you need, the more integration you will need. And the more integration that you require, the more complex the test design has to be.
When I was a project lead programmer early in my career, the marketeering guys were after us to "sharpen our pencils" so we could cut costs and "buy the job." However, I asked the president of the company if that meant "buy it for a loss." He said "No." The job would have had new graphics devices, new types of telemetry, new printers and printing requirements, and several other new features, so I added up the numbers for my estimate and told them the systems integration total. They said "No, too high." I said, "Actually, this is already razor thin. Can't cut any more." The argument lasted an hour.
To make the long story short, I stood ground on an estimate with some built-in time to fix errors because we knew they were going to happen. We didn't get the job. Two weeks later, the same customer called us and said that the original winning bidder revoked their bid because they said it would be too expensive. So we got the job on the rebound. The moral of the story is that if you undercut yourself on the integration estimates, you screw yourself.
My approach was always to allow a fixed unit of time per specific test, and then count up the number of interactions for the new stuff. Then add up the FACTORIAL of the number of components interacting in a given section. (Since it was usually only two to four elements, not that bad a number.) I think my usual scheduling units were 2 hour chunks for s/w integration and testing of a single factor. 'cause after all, you not only have to device the test, you have to execute it. And THEN you have to document it so that it will be in your readiness report.
I know it seems intimidating. (And the first time I had to make an estimate, it WAS.) Because estimation is a skill like programming or graphics design. You have to learn by doing. And the first few estimates will be woefully wrong no matter what you do.
