The document discusses the debate around estimating in software development. It presents arguments for and against estimating, as well as different approaches to estimating such as using story points, t-shirt sizes, and the #NoEstimates method. The document also explores reasons for estimating like planning, forecasting, and facilitating meaningful discussions, as well as techniques for estimating like planning poker, decomposition into subtasks, and using the Fibonacci sequence. Overall, it examines the tradeoffs of different estimating approaches and emphasizes focusing on complexity and uncertainty over precise hours or dates.

1. To Estimate Or Not To
Estimate?
Startit, 4. april 2019
MeetUp #6

2. Šta se krije iza ove dileme?
● Procene su nam neophodne
● Tačne procene nisu moguće
“A predictable outcome is one of the most sought-after goals in any business or
initiative.”

3. Estimates vs #NoEstimates
If we must estimate, what are the best ways to do so?
What are ways to provide information that management wants, with reasonable
accuracy and in a way that leads them to discover that they can live without
conventional estimates? Can they?

4. Šta procenjujemo?
● the amount of work we can do in a given time
● the amount of time we need to accomplish something

5. Time for what? Big goals? Value? Scope?

6. Time for what? Strategic goals? Action plans?
A predictable outcome is one of the most
sought-after goals in any business or
initiative. It’s easy to see why.

7. Why? To make better decisions?
● fixed scope?
○ fidelity?
○ quality?
○ business value?
● fixed delivery date
● fixed budget

8. Matt’s NoEstimates Manifesto

9. Poređajte knjige po veličini
Poređajte knjige po veličini:
1) Rat i mir
2) Andrić - Sabrana dela (20 knjiga)
3) Enciklopedija Britanika
4) Moja velika knjiga
5) Hari Poter i kamen mudrosti (245)
6) Rečnik Matice srpske
7) Ginisova knjiga rekorda (256)
8) 501 destinacija koju morate posetiti (546)

22. Triangulacija

24. 1/2/3 5/8/13

27. Estimating, Planning, Forcasting

29. The Traditional Way

30. The Agile Way

31. Backlog Refinement = Gold Refinement
Izdvajanje zlata iz šljake
Odvajanje žita od kukulja

32. Story Funnel

33. Kada?
● Backlog Refinement: fokus na
razumevanje i konsenzus
○ Estimates u funkciji
○ POJAŠNJENJA (Koliko
je jasno?)
○ SITNJENJA (Koliko je
veliko?)
● Mini rokovi: fokus na vrednost

34. Measuring the progress
● How much we can do in a given timebox?
● How much time we need for the given scope?

35. Estimation by effort
● SYSTEM 1:
○ Fast, automatic, frequent,
emotional, stereotypic,
subconscious
○ Estimation by Effort
● SYSTEM 2:
○ Slow, effortful, infrequent,
logical, calculating, conscious
○ Estimation by Time

36. System 1

37. How the mind works | Daniel Kahneman
@Google Presents: Daniel Kahneman

38. Fast Lines
Poređajte se po:
● visini
● broju cipela
● dužini kose
● datumu rođenja

39. A piece of advice
If simple or complicated - analyse & calculate
If complex - predict by intuition, decompose, clarify, then
calculate
If chaotic - don’t bother :)

40. Cynefin Model

41. Šta procenjujemo?
Effort?
Complexity?
Time?

42. Planning Poker

43. The discussion in the estimation round is a great
source of knowledge as estimated tasks are
more detailed and easier to be understood by
team members. Combine such estimation with
breakage of the backlog items into subtasks.
12 angry men

44. Why estimate? Meaningful conversations?

45. Estimation by hours?

46. Fibonacci

47. Why Do We Use
Fibonacci Numbers
to Estimate User
Stories?

48. T-shirt sizes

49. Lunar logic: Estimate to sort out and clarify
So here it is. The no bullshit estimation deck that
sustains valuable conversations about the complexity
and uncertainty whilst at the same time renders
discussions on whether something is worth 8 or 5 story
points utterly irrelevant.
https://estimation.lunarlogic.io

50. Less is more
Given that it takes time and it is tiring
● estimate quickly and talk
● quickly talk and estimate, repete
If small and clear - do it
If bigger than small - ask for further
clarification and decomposition

51. Accurate Estimates vs. Actual Time
● Hours (Just for Tasks/Repetitive tasks)
● Relative estimates (Just for User Stories)
○ Story Points
○ T-Shirt Sizes
● #NoEstimates
● Time tracking
● Velocity in Story Points
● Number of tickets done

52. You can't step twice into the same river
Velocity?
“The main idea behind velocity is to help teams estimate how
much work they can complete in a given time period based
on how quickly similar work was previously completed”.
Hours?
When estimating in hours you focus on answering the
question "How long it may take us?". So basically it's more or
less guessing, based on your previous experience.
Points?
When estimating in points you focus on relative sizes or
complexity of estimated tasks/stories/whatever. So you
usually take some of your tasks and apply one of the point
values to them, and later, for each other task, you try to
answer the question "How big is it in relation to those I've
already estimated".
NoEstimates?
The key thing about points estimation is that you need
to actually measure how the estimates relate to time.
After some initial time in the project (especially when
you start with point estimations) you learn how many
points you are able to deliver in each iteration or fixed
period of time. This gives you the basis for planning the
future releases.

53. Why estimate? Why track?
● Planning
● Forecasting
● Meaningful discussion
● Learn
● Show evidence for time and material
projects (i.e. get paid)
● Internal operational efficiency

54. How long vs. How much

55. Agile is about How much
Rough estimates in Story Points
One can suffice with a draft estimated
timeframe.
Keep in mind the waste-value balance, though.

56. Mike Cohn, Agile Estimating and Planning

57. Further Reading

58. Preporuka za čitanje
Steve McConnel, Software Estimation: Demystifying the Black Art

59. To Estimte or Not to Estimate

60. Živa istina