Downloaded 16 times
Uploaded byMagdalena Sitarek
Estimations
Estimations are important for planning, budgeting, and communicating with clients, but are difficult to do accurately. Some key tips for providing good estimates include doing thorough research, accounting for potential problems, getting input from others, and adding a buffer to allow for unexpected issues. Estimators should be careful not to provide estimates without proper information or let others estimate for them. Even with preparation, estimates may end up being wrong at times, so it's important to communicate openly with clients about potential delays.
Estimations
- 1. Estimations Małgorzata Szweda, BlazeHadzik, Magdalena Sitarek
- 2. what is anestimation? estimation noun es·ti·ma·tion ˌes-tə-ˈmā-shən : a judgment or opinion about something : the act of judging the size, amount, cost, etc., of something : the act of estimating something : a guess about the size, amount, cost, etc., of something
- 3. why estimate? there isone truth: all clients love estimations they mostly think: you have knowledge, you’ve done that before, that’s piece of cake, isn’ t it?
- 4.
- 5. so... how to doit well? is that even possible???
- 6. spoiler! estimation is awell- informed guess you’re guaranteed to do it wrong from time to time
- 7. be prepared! do yourresearch know what you want to use ask around
- 8. the golden rule FromThe Pragmatic Programmer: From Journeyman to Master: What to Say When Asked for an Estimate You say "I'll get back to you." You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
- 9. who should estimate? notthe client not a dev that isn’t you you
- 10. planning poker group estimation differentexperiences broader idea of time needed
- 11. case study Client thoughtof a new feature and asked me to estimate on the call. What do I do? never estimate unexpected things on a call! ask for some time for research
- 12. case study Client thinkshe knows better and tells me I can do it faster. What do I do? explain why you think it’s not correct work with your PM if s/he’s right you finish faster if s/he’s wrong there can be a delay
- 13. case study Lead devfrom the client’s team estimated the ticket for me and it’s wrong. What do I do? communicate it’s possible you won’t make it they insisted and you ran out of time - explain why work with your PM so you can estimate instead
- 14. how to estimatefeatures? make sure you know what needs to be done remember that you need to write tests remember about code review there WILL be problems
- 15. how to estimatefeatures? feature = planning + actual work + tests + code review + bugs-that-never-happen-but-sometimes-do
- 16. how to estimatefeatures? add some padding! the Blaze Time Tax = 1.75
- 17. DOs ok, so herewe are… 1) Gather requirements (ping pm/ client if needed) and do your research (mockups, APIs, edge cases...) 2) Ask when in doubt and explain when something’s amiss 3) There is always room to screw up and for things to go wrong - add padding 4) Track elapsed time and learn from past experiences 5) Ask around - check with others / internet / seniors / grandma / PM / 6) Use more than one method to arrive at an estimate, and look for a midpoint among all of them.
- 18. DON’Ts 1) Never estimateduring the call !! 2) Don’t let anyone estimate for you 3) Don’t estimate without checking that you have everything
- 19. why we failsometimes... 1. The presence of hidden or unknown variables that are difficult or impossible to anticipate, and sometimes even more difficult to resolve. 2. Our often-idealistic views of our own capabilities. We frequently believe that we can achieve much more than is possible in the available time. 3. A strong human desire to please other people by telling them what they want to hear. (After all, who wants to be the bearer of bad news?)
- 20. how to estimatebugs? Don’t. No, seriously - DON’T. But if you have to: some bugs can’t be estimated - they need a no-idea label if your guess was wrong - explain why you need more time
- 21. how to estimateprojects? that might surprise you, but… you usually don’t work 8h a day
- 22. how to estimateprojects? that might surprise you, but… you usually don’t work 8h a day :) how come? 9am 11am 1pm 3pm 5pm help reqlunch email checking call email checking
- 23. and finally... always thinkof the worst case scenario
- 24. and finally... always thinkof the worst case scenario … and then add even more time :)
- 25.
- 26. responsibility What am Iresponsible for?
- 27. responsibility Let your clientknow in case of delays & blockers
- 28.
- 29.
- 30. responsibility The missing feedbackloop we want to have.
- 31. Cases The API thathas just been updated. The integration no one knows about. The project you don’t know about.
- 32. Cases The client changesrequirements. The client is too cool. The client asks you how long sth would take on a call.
- 33. Questions? ask us now!:) fill in the evaluation survey and share your feedback
Editor's Notes
- #3 By definision therefore estimates cannot a treated as a contract. Nevertheless, put simply - no one wants to be the guy (or gal) who invoices for two hours of their time but ends up working five.
- #5 they mostly think: you have knowledge, you’ve done that before, that’s piece of cake, isn’t it?
- #6 One: it’s a pain in the butt. Two: nobody believes in it ; if our estimates are wrong, and most of the time they are, why should we even attempt estimating in the first place?
- #12 http://www.amazon.com/dp/020161622X/
- #14 The idea is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.
- #34 if you see you’re running out of time leave a PT comment, message on Slack, talk to your client and elaborate on a issue.
- #35 if you’re going overtime with a task or have problems it is your job as a developer to let your PM AND your client know
- #36 if you’re doing work on a ticket that somebody else’s work depends on - communicate