Understand Customer Requirement:
Giving an ETA without understanding the task is like "Not knowing the destination of the ship and you estimates how long the trip takes". So in first place understanding the customer's requirement is most important.
Order Your Activities:
At this stage, you don't need to add in how long you think activities are going to take. However, you might want to note any important deadlines. For example, you might need to get documentation of another component of the system before starting integration.
Breakdown Your Estimates (into):
Known knowns:
How long will it take to do what you know how to do.
Known unknowns:
How long do you think it will take to do what you don't know how to do.
Unknown unknowns:
This is the real time black hole. Provide a range for the estimate with justification based on the risks you anticipate.
Offer to adjust the estimate and certain milestones along the way. Any "unknown unknowns" will become "known unknowns", the "known unknowns" should become "known knowns" as you gain experience, and the estimate of you "known knowns" can be adjusted based on progress to date. You can do an initial estimate, then re-estimate when you about 25% done, then again at 50%, then again at 85%. At each milestone your estimate should start converging on the actual time the tasks will take.
ETA Should Contains (as per the requirement from the client):
- FDD Review
- Development analysis
- Coding
- Run best practices + proper comments where needed
- Unit testing
- Quality assurance
- Documentation (FRD, FDD, TDD, Test Cases, Release notes, Deployment document)
- Code review
- Build and Sync
- Code merge or check-ins
- Deployment (creating deployable package, deploying on other environments e.g., QA, CRP, UAT, Gold)
Examples For ETA:
Example # 1 - In this example ETA is not detailed or descriptive.
Example # 2 - In this example ETA it is much detailed or descriptive.
That is all, I believe this blog will add a value in your programming.
No comments:
Post a Comment