If you're fed up with endless arguments, over whether a story should be 3 points or 5 points? Irritated with having to provide estimates to your management that you know are probably going to be wrong? We investigated that there's a BETTER WAY. Can we make the unpredictable world of product development a little more predictable?

1. Darren Aitcheson - Agile Lithuania
How to make forecasts that are
actually correct
(hopefully)

2. •From Northern
Ireland
•I do Agile stuff
•Professional Kanban
Trainer with
ProKanban.org
About me

3. • Estimates are a fact of life
(unfortunately)
• “It will be done when it’s done”
generally isn’t a business strategy
• Your teams are always being put
under pressure to deliver on time
based on guessing
• They (usually) get blamed if they
are late
Why you should care

4. https://app.sli.do/even
t/bpjmwajn
Or go to slido.com
and enter 100284

5. Lesson 1:
All estimates are guesses
(Please remind your management of
this fact)

6. So how do we make our guesses
more accurate?

7. Story points?

8. Orange = 3 points
Blue = 5 points
Yellow = 8 points
Purple = 13 points

9. Use story points in your team for
capacity planning if you want to
But they don’t
answer “when
will it be done?”

10. If story points aren’t the answer,
what do we do?

11. We build jigsaws (obviously 😉)

12. Jigsaw = epic/feature/story/item of
work

13. Do we have anything that can help
us make a more accurate guess
about future items?

14. Lesson 2:
The best way to forecast the future
is to look at the past

15. One data point isn’t going to help us
- we need more

16. We’ve now completed 5 “epics”.
Forecast how long it will take to
complete the next one.

17. How close were you to being
correct?

18. To be even more accurate, what
should we do?

19. You guessed it - get more data

20. We’ve now completed 10 “epics”.
Let’s learn how to be always “right”.

21. Lesson 3:
A forecast must consist of:
* A range
* A probability

22. We do this by using percentiles

23. Let’s build two more to test our
theory

24. So why wasn’t that last jigsaw done
on time?

26. In what ways do our work
items resemble the jigsaws
we just built?

27. None of them are identical

28. We have no idea how
complex they’ll be before
we start

29. Numerous other things can
happen while we’re working
on them

30. …but yet, we can still
provide a forecast that is
accurate and achievable

31. Lesson 4:
Your historical data is important - if
you’re not collecting it, start now!

32. So how do we apply this in real life?

33. “When will x be done?”

34. 1. Set a Service Level Expectation

35. “Once we begin work on an item,
we complete it within 10 days or
less, with an 85% probability”

36. 2. Size your items to give them a
reasonable chance of meeting your
SLA

37. If an item looks too big, split it

38. The 15% will probably cover you for
when you get it wrong

39. Why is this approach good for
everyone?

40. Everyone knows what to expect

41. We don’t have to agonise over story
points or person-days, etc.

42. Your team isn’t under pressure to
meet unrealistic timescales

43. You can use it for any process, not
just software development

44. Visualising the data allows you to
see the variation and to begin to
address the causes of it

45. You can easily use a similar process
to forecast multiple items
“I have a backlog of 20 items; when
will they be done?”

46. Our final lesson, which trumps all
the others…

47. Lesson 5:
If you are not delivering value, it
doesn’t matter how accurate your
forecasts are, or how quickly you
get things done!

48. Further reading / listening

49. Questions?