Why estimation is important?
Estimating prioritized backlog, we are making transparent to business side what (roughly) can be done in the following period. Estimations in time are dependent on may factors: experience of the developer, we need to know who will exactly work on this if we want to estimate – and this is usually not known in advance etc.
For these and many other reasons, we prefer to estimate in user story points (USP). USP is virtual unit and is based on experience and knowledge of your product backlog. The idea of USP will be learned with time and calibrated within the team.
Basic idea with USP is that this is measure of total efforts needed for delivering one user story. It is relative estimation of one user story to the other one. I will give you few hints for having better estimations.
Hints for estimate:
- Choose the smallest, but still complete (carrying business value) user story and mark it with 1;
- Choose something twice (by your sense – take an engineering approach) bigger user story and give it 2;
- Continue with relative estimations, using 1, 2, 3, 5, 8, 13, 20, 40
- If you have A=1 and B=2 and C in the middle, use your experience to estimate if C is closer to 1 (A) or 2 (B). Mistakes are allowed and even welcome in the process of learning to estimate as a team and getting more experience in this activity
- Estimation is the process, not deterministic, but rather experiential. Give the best estimation based on previous instructions, but have in mind that these estimates will be better with time.
- In my experience, it takes 3-4 sprints for the team to stabilize the estimates on team level and to get necessary experience for stable estimates and stable velocity on sprint level
- Avoid having 13+ user stories in sprint backlog, even in closer (in time) product backlog. If you have 20 USP user story insist on splitting it to several user stories (at least two). If it is not possible, plan splitting to tasks and several people working on this user story to mitigate the risk of not delivering it by the end of sprint.
- Each user story sizing should be appropriate for delivering it in one sprint, i.e. each user story should be deliverable/doable in a sprint;
- Good practice, during the second part of sprint planning, is to split each user story to the tasks. Ideally, each task should be doable in a day – this way it is easy for the team to see daily progress (on daily scrums)
At last, feel free to make a mistake, as long as you give your best estimate. You will, individually and as a team, learn and become better in time.