[charls_Aws]

Have been doing this for about 8 years. As others have mentioned here is something you can follow:

1: Break tasks into as small as you can, say a few hours to a day.

2: Add time estimates for writing the main code, writing tests, doing integration test and code reviews separately.

3: Also take into the account the time which might be wasted to unknowns, things which you know needs to be done but do not have much idea on how you would do that. One way to refine this would to be to talk to other developers who might have some experience doing this part of the task.

4: Account for 'unknown unknowns' these are the tasks which will show up but you can't really predict these upfront. Any software developer who has done commercial software can tell you that for every project 10-20% time is used in this which we did not even anticipate. These things always show up.

Now if you break down tasks into these parts, add up the time and then add a 'buffer' say 10-20% on it and give your estimate. I am sure you will face pressure to reduce estimates, but having a break up allows you to provide some support to the numbers you come up with.

Hope this helps.

[blooo]

This approach seems very time consuming at first, but the first step itself starts to show you the ROI on the invested time.

When I start breaking down a task into smaller pieces, I often come across things I had not thought of when just thinking about the monolith. "Oh, I'm using X here, but where am I getting X from? That's another task."