Suppose your car is broken and you take it to a mechanic. The mechanic runs some diagnostic tests and identifies several issues. She asks you to leave the car with her for repairs. Your immediate response perhaps will be "how long it will take and how much it will cost?". What you don't want to hear is "it'll be ready when it's ready and it'll cost what it'll cost".
As a software developer you too will be in a position to estimate the cost and time for developing a software.
- Your project estimate is the sum of the estimates for your User Stories.
- You should add an estimate to each User Story for how long you think it will take to develop (that is, design, code, test, and deliver) that functionality.
It is hard to estimate the time it will take to develop a user story. As someone who is starting this, it may seem impossible to get it right. This is difficult (and prone to error) even for experienced developers due to a phenomenon known as the Planning Fallacy.
In agile software development, practitioners combat the Planning Fallacy by
- Getting estimates from multiple people
- Estimating "effort required" in terms of "ideal days" or "Story Points"
- Using relative estimates (e.g. this feature requires twice the effort we put for that feature)
"A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions, and all resources necessary to complete the work were immediately available."1
In your estimation, you should factor in the time you will spend researching or learning about developing a feature.
More experience software engineers estimate the effort required as a combination of the complexity of the work and the risk & uncertainty involved in it. They call this estimate "Story Points".
Story estimates larger than 13 (ideal days) cannot fit into an iteration. You may want to try to break that story into several smaller, more easily estimated stories.
If the total estimate of all User Stories in the "Must have" category is much larger than the duration of five iterations, you must make changes (including dropping the project in favor of a smaller one).