“For every complex problem there is an answer that is short, simple, and wrong!” To estimate the complexity and the size of the project we’re about to develop is definitely a complex problem. It doesn't matter if it is a simple app for buying cat food or a very elaborated banking system. Usually, we’re using different estimation approaches to deal with this problem, but it’s pretty easy to fall into various traps. The results of your fall-downs may be really painful, such as an unhappy client or a frustrated team. In this presentation we’re speaking about different situations and mistakes we’ve made (or have observed in other teams) and we’ll try to give some tips how to avoid them.

1. Estimation
Tricks & Traps
Katarzyna Korona, Marta Kossowska
25.02.2016, STX Next 2016
#AgileLightingTalks

2. About us
Katarzyna Korona
After a few years of working in IT she discovered that the way how teamwork is
organized helps to bring out the best in other people. She took up the challenge and
became a Scrum Master. Currently she’s focused on developing the appreciation
culture within the teams, between teams and clients and on the company level.
Marta Kossowska
Playing different roles in software projects, she discovered agility and since then she
has adhered to it as a Product Owner. Her main focus is the value delivery in the
shortest time possible. She also tries to improve communication between business
and development.

3. Agenda
➢ Why estimate?
➢ What traps we can fall into?
➢ How not to estimate?
➢ What to do to avoid some traps?
➢ What about not estimating at all...

4. Why estimate?
...because our
PO/SM/management/client
tells us to do this!

5. Why estimate?
“Product Backlog items have the
attributes of a description, order,
estimate and value.”
“Product Backlog refinement is the act
of adding detail, estimates and order
to items in the Product Backlog.”

6. Why estimate?
To know if you can afford it

7. Why estimate?
To know if it is worth doing

8. Why estimate?
To enable planning

9. Why estimate?
To have possibility to prioritize

10. Why estimate?
To limit business risk by delivering incrementally

11. Why estimate?
To assess whether the team is skilled
enough*

12. Why estimate?
To foster discussion about user story/requirement

13. Why estimate?
To identify
weaknesses and
improve process or
develop needed skills

14. What traps we can fall into?
Finger in the air estimate

15. Not taking into consideration all required work i.e. DoD
What traps we can fall into?

16. Client takes estimation
for granted
What traps we can fall into?

17. Predictability over quality
What traps we can fall into?

18. Wasting time for too
detailed estimation
What traps we can fall into?

19. Are Story Points
objective?
What traps we can fall into?

20. 1 Story Point
- what does it mean?
What traps we can fall into?

21. 1 Story Point
- what does it mean?
What traps we can fall into?

22. Estimation as a
method for evaluating
quality of the team
What traps we can fall into?

23. Comparing
different teams
What traps we can fall into?

24. Relating Story Points
to hours/days of work
What traps we can fall into?

25. Story Point inflation
What traps we can fall into?

26. Story Points as KPIs
What traps we can fall into?

27. How not to estimate?
Without sufficient knowledge about
requirements, product and system
It’s impossible to estimate
something that is being built for
the first time.

28. How not to estimate?
Making too optimistic or
too pessimistic
assumptions in case we
don’t have enough
knowledge

29. How not to estimate?
Following the opinion of
senior/most experienced
developer from the team

30. How not to estimate?
Excluding non-developers from estimation process

31. How not to estimate?
To make PO/client/manager happy
(or quite the opposite)

32. How not to estimate?
To have always even number
of story points for every sprint
or for each team

33. What to do to avoid some traps?
Splitting user stories

34. Higher estimation
(taking into consideration
risks and lack of knowledge)
What to do to avoid some traps?

35. What to do to avoid some traps?

36. Adding bugs &
maintenance tasks
to the planning
What to do to avoid some traps?

37. Planning on
physical board
What to do to avoid some traps?

38. Adding subtasks for
frontend & backend
work
What to do to avoid some traps?

39. Other team members
are responsible for
frontend tasks
What to do to avoid some traps?

40. Include in the
planning learning
JS/REACT by one
developer per sprint
What to do to avoid some traps?

41. More frequent
mini-refinements
sessions
What to do to avoid some traps?

42. Fruits estimation
What to do to avoid some traps?

43. Animals
estimation
What to do to avoid some traps?

44. What to do to avoid some traps?

45. What about not estimating at all...
“It’s impossible to estimate
something that is being built for the
first time.”
...but
in software development every
new feature is being done
for the first time :(

46. What about not estimating at all...
Can be any alternative* for decision making based
on estimates?
*satisfying for both suppliers of
software products and for their
customers?
#noestimates

47. What about not estimating at all...
Don’t size at all, but...
… fix the delivery date
… plan interim releases
… iterate over the product
… let the scope emerge and reassess it
How to size the project?
#noestimates

48. What about not estimating at all...
You can still discuss stories with the team and
break them down if necessary, even without
estimating it.
Will the team discuss stories without estimating?
#noestimates

49. What about not estimating at all...
Break down stories at the Sprint Planning so they’
re all roughly the same size
How to assess ROI without knowing how big the
story is?
#noestimates

50. What about not estimating at all...
Measure velocity based on the story count instead
of accumulated velocity
How we can know if team’s velocity improves?
#noestimates

51. What about not estimating at all...
- average: 13
stories
- deviation: 3
#noestimates

52. Thank you!
Do you want to share your thoughts?
contact us @
www.linkedin.com/in/martakossowska
www.linkedin.com/in/katarzyna-korona