|
|
|
|
|
by drojas
1178 days ago
|
|
Estimations are useful for developers and management. It helps developers prioritize their time and propose more efficient approaches. It helps management track projects and make decisions more efficiently. Even an open-ended problem has to be scoped into a time-boxed "spike" first that would result into concrete stories which would be sized in story points. Nobody likes to give estimates because it feels like an unfair commitment. These are the rules I follow myself based on my own learnings and advise from others. 1. If I can't feel sure about an estimate in story points then I prepend a time-boxed "spike" to solve that first. 2. Always consider "extra" tasks like tests, data migrations, etc. in the estimate. 3. If my estimate looks bigger than what I can do in half of a sprint if you do scrum then I break it down to smaller stories so I have less risk to have the story rolling over. 4. Add about 20% of padding to all estimations. 5. If you take notes in the story/tickets about all the things adding to the estimation besides common discussions about the work, then you'll get more and more comfortable with your estimations over time. |
|