Agile Estimating¶
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)
Ideal Day
"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
Tip
In your estimation, you should factor in the time you will spend researching or learning about developing a feature.
Story Points
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".
Playing the Planning Poker¶
Planning poker (also called Scrum poker) is a gamified technique for estimating the effort (or relative size) of development goals in software development.
You need a deck of several cards (usually 13). Each card has an estimate written on one side (usually, estimates are the numbers in the Fibonacci series).
- Select a User Story.
- Each team member privately chooses a card representing the relative effort of the story.
- Everyone calls their cards simultaneously by turning them over.
- People with high/low estimates are given an opportunity to ask questions and discuss to clarify assumptions and risks.
- Repeat the estimation process until a consensus is reached.
Warning
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.
Danger
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).