No matter how utopian your agile working environment, if you're building a commercial product, at some stage you will be asked the inevitable question - When will it be done? This talk will provide you with tools and techniques to use when you hear your manager say "We just need to get better at estimating". If you have ever wished for a crystal ball to help you predict the team's future, this talk is for you!

1. IS IT DONE YET?
… HOW ABOUT NOW?
MICHELE PLAYFAIR
DDD PERTH 2019
Hi Perth!
This talk will give you some ideas about tools and techniques to use when you hear
your manager say "We just need to get better at estimating". If you have ever wished
for a crystal ball to help you predict the team's future, this talk is for you!
1

2. Many thanks to all the wonderful sponsors that make this event affordable –
including YOW!... YOW! Perth coming up in September, come and see us ☺
I would also like to give some love to all the organisers who have ONCE AGAIN done a
fantastic job crafting DDD Perth. THANK YOU!!!
2

3. micheleplayfair#DDDPerth
REAL AGILE WORKPLACES
DON’T HAVE DEADLINES
Once upon a time, when Agile and I were young… I was working in a Agile-ish
company, which still had projects, deadlines, and the associated overtime and
weekend-free death marches.
I figured that if we ONLY did this Agile thing PROPERLY then we wouldn’t have these
stupid deadlines and life would be beautiful....
Then I started working for a company that had pretty mature product development,
people were experienced and understood agile ways of working and YET we still had
some deadlines and end dates!!
What is going on???
3

4. micheleplayfair#DDDPerth
In my case there were government legislation related dates that need to be met, and
compliance is not optional if you want to stay in business
- I worked on teams that were creating solutions for two of these
4

5. micheleplayfair#DDDPerth
Maybe you’re working to meet another kind of event-related immovable date
5

6. micheleplayfair#DDDPerth
Photo by Pixabay
Maybe there’s a race against your competition to get a product to market first – we
had that as well!
6

7. micheleplayfair#DDDPerth
Photo by Pixabay
Maybe there’s some kind of staffing dependency and you’re going to lose people on a
certain date
Maybe you announced features to your user base - made a public commitment to
customers that you will deliver something.
If you do this too often without living up to it, you get….
7

8. micheleplayfair#DDDPerth
https://www.elonmusk.today/
Elon Musk Today – a site entirely dedicated to tracking Elon’s promises made on
Twitter!!
Hell hath no fury like a customer scorned.
8

9. micheleplayfair#DDDPerth
REAL AGILE WORKPLACES
DON’T HAVE DEADLINES
… said nobody ever
So where did this impression come from?? It’s not in the Agile Manifesto… it says
“sustainable pace” but nothing says “we value not having deadlines”
I figure there are a couple of factors at play here… First, companies that we’re told
have the “best agile working” - like Facebook, Google, Spotify, Twitter, Netflix – I have
never seen them make a public commitment to producing a feature by a certain time.
The updates just "appear" whether we like it or not. Sometimes in the case of Google
products you can go back to the previous version - for a short a/b period, before
you're forced to take the latest.
And sometimes you just get…
9

10. micheleplayfair#DDDPerthMing Johanson on LinkedIn 17 Jul 19
This.
Cheers Ming for this timely observation!!
Does your company work this way or more to the point, is it even possible for them
to do this to their customers and stay in business?
10

11. micheleplayfair#DDDPerth
If you could come in
on Sunday too, that
would be great.
Yeah, I’m going to
need you to go
ahead and come
in on Saturday…
Second issue is that so many people associate “deadlines” – even the word DEADLINE
- with the big push at the date looms closer, where your weekends and your life
disappears along with your sleep
And like I did, they hope that in a better, more AGILE work environment, this
deadline-induced misery would disappear… where’s my sustainable pace?!
11

12. micheleplayfair#DDDPerth
DOES IT HAVE TO BE LIKE THIS?
Joshua Partogi on LinkedIn 16 Jul 19
Manifesto for Deadline Driven
Development
We are uncovering bitter ways of developing
software by doing lots of overtime and helping
others do it…
Manifesto for Deadline Driven Development - We are uncovering bitter ways of
developing software by doing lots of overtime and helping others do it…
Does it have to be like this?
If we take as a given that deadlines – or milestones, or whatever you want to call
them – WILL happen….
We need to cope with the idea that sometimes you do need to know WHEN WILL IT
BE DONE and IS IT DONE YET? – while avoiding the mini-waterfall death march
12

13. OBVIOUSLY THE ANSWER IS….
Or is it?
Because if we only did this part RIGHT then we would *know* when we would finish!
Easy peasy.
13

14. micheleplayfair#DDDPerth
We need to
get better at
estimating!
To many managers, the existence of an estimate implies the existence of an “actual”,
and means that you should compare estimates to actuals, and make sure that
estimates and actuals match up. When they don’t, that means people should learn to
estimate better. (Ron Jeffries)
I have heard senior people say this!!
Do you really want to spend time getting better at estimating??
14

15. micheleplayfair#DDDPerth
“
”
WASTE IS ANYTHING THAT DOES
NOT ADD VALUE TO A PRODUCT,
VALUE AS PERCEIVED BY THE
CUSTOMER.
Poppendieck – “Lean Software Development”
In “Lean Software Development” Mary & Tom Poppendieck wrote that “Waste is
anything that does not add value to a product, value as perceived by the customer.”
By this definition, time spent estimating is waste and should be minimised with the
view to eliminating it. I’m not gonna say NOESTIMATES because that summons trolls
– what I will say is that you should spend LESS time on estimating, not MORE.
BUT we still need a way to know WHEN WILL IT BE DONE? So what is the
alternative??
15

16. micheleplayfair#DDDPerth
SIMPLE, TRANSPARENT AND PREDICTABLE
First goal: We want to make the work as simple, transparent and predictable as
possible
16

17. micheleplayfair#DDDPerth
“
”
PREDICTABILITY IS IMPROVED BY
BEHAVING AND DELIVERING MORE
PREDICTABLY, NOT BY MAKING
PREDICTIONS.
- Neil Killlick
Neil Killick has observed that “Predictability is improved by behaving and delivering
more predictably, not by making predictions.”
We want to put something valuable into the hands of users sooner rather than later,
then iterate on it in a rhythm.
Getting regular feedback along the way.
17

18. micheleplayfair#DDDPerth
I’m sure many of you have seen this drawing by Henrik Kniberg before.
Assuming in this case what I am trying to do is “get somewhere faster than
walking.” I can quickly deliver a skateboard and then get feedback from users which
might have been, “I like the wheels idea but I am afraid of falling off and it’s still hard
work” - then you next produce a scooter.
NONE of these is The Perfect Solution but each is better than the previous.
If we only made it to step 3 by the “Deadline” - are we OK? I say yes we are!
Note that if we were in a waterfall project, our “requirements” would have most
likely been to build the car!! And look where we are at step 3, we can’t use it.
Sounds good in theory but how do we actually DO this fast, predictable delivery
thing??
18

19. micheleplayfair#DDDPerth
STORY MAPPING – JEFF PATTON
First recommendation, use Story Mapping – this is some real secret sauce and if you
haven’t read User Story Mapping I suggest you get your hands on a copy, you won’t
regret it.
The story map describes what users will do to reach a goal, over time going left to
right the same way you would tell a story to someone else.
The backbone across the top is made of higher-level activities that represent groups
of tasks done at similar times to reach the goal
Below that in the body of yellow stickies are the user tasks – short verb phrases –
that are a breakdown of the higher level above. Using one of the examples from
Jeff’s book, you might have a summary task of “get cleaned up in the morning” and
the user tasks might be “have a shower”, “do my hair”, “shave”, “put makeup on” etc
What you have now is something that is simple – story to explain what users want to
achieve – and transparent – if its on a wall where anyone can see it!
19

20. micheleplayfair#DDDPerth
STORY MAPPING – JEFF PATTON
Once you have your map laid out you can identify a set of tasks that could form a goal
and literally draw a line under them to form a “slice” – something you could release
to a customer to get their feedback
Summary – go for GOOD ENOUGH then BETTER then BEST. If you have a deadline
work towards getting the GOOD ENOUGH version into your users hands as soon as
you possibly can and iterate from there.
20

21. micheleplayfair#DDDPerth
Here’s one from Real Life!!
You can see the first major release slice was the “compliance goal” – we used goal
instead of deadline as it’s less scary - this was the Minimum Viable Product – the
skateboard from Henrik Knieberg’s drawing
Next release would have made it nicer for users and added some extra functions –
and you get the bicycle
Third one was the really awesome bells and whistles one – the car, if you will. We
also had smaller slices of bits of it along the way that we gave to users for feedback
which was very helpful
21

22. micheleplayfair#DDDPerth
“EASY AGILE STORY MAP FOR JIRA”
This is a 3rd party add on called “Easy Agile Story Map for JIRA” - I assume there are
people here using JIRA? (if anyone boos – you don’t hate JIRA, you hate whoever
configured it at your workplace and maybe the managers who think it’s magical!)
Physical boards are awesome for planning but if you use JIRA I really recommend
getting this little add-on to storymap inside JIRA eg for remote teams or places where
the dang board is too big for the wall or to match JIRA to your physical board.
It Just. Makes. Things. Easier.
22

23. micheleplayfair#DDDPerth
STORY POINTS
Crisp.se
So now we’ve got our map of user tasks / stories to work with. I was really bothered
about all the time spent in meetings arguing about whether a story is a 3 or a 5 – and
don’t even get me started on the constant conversions to and from points and time
“umm so if that takes a week it will be a 3”, “we’ve got a total of 9 points so that’s..
What, 2 weeks? 3?”
It just seemed like a waste! But you NEED story points if you’re going to be agile,
right?
23

24. micheleplayfair#DDDPerth
STORY POINTS - ?
Then I saw this from Ron Jeffries talking about how to size stories: 1, 2, too big – days
not points. And I thought – yeah that sounds better
Who’s Ron Jeffries?
24

25. micheleplayfair#DDDPerth
STORY COUNTS NOT STORY POINTS
He’s the guy who may have invented Story points and has been apologising since for
how they are misused.
Break the work down into stories as small and uniform as possible, try for consistent
sizing – 1 or 2 days - and just get on with it. It won’t be perfect but it will be good
enough! Rule of thumb from Neil Killick is for each story to fulfil a single acceptance
criterion.
Once you have started the habit of working on small stories and each story is close to
the same size, you can COUNT them instead, and being predictable is much easier…
And YES! You can configure JIRA to use card counts instead of story points or time.
25

26. micheleplayfair#DDDPerth
THROUGHPUT & CYCLE TIME
Work Started Work Completed
(In Production)
Throughput = Number Stories Completed per Iteration
Sprint 1:
Sprint 2:
Sprint 3:
Cycle Time
hotpmo.com/blog/the-definitive-list-of-agile-metrics
Cycle time – this is the average time that it takes something to get from the start to
the end of a process. In development it’s often the time that something moved to “In
Progress” up until it’s “Done Done” or Released.
Throughput = units of work per unit of time. In this case, Throughput is the number
of DONE stories completed by a team per week or per sprint.
According to the theory of constraints, the best way to optimise is to focus on
throughput.
Teams with shorter cycle times are likely to have higher throughput, and teams
with consistent cycle times across many issues are more predictable. So that’s the
aim.
26

27. micheleplayfair#DDDPerth
CYCLE TIME (CONTROL CHART)
For those of you in JIRA land this is the Control Chart where you can check on your
team’s cycle time. This particular specimen is not great (1 week average!)
When your cycle time is consistent the green dots will be closer together and the
shaded area will be thinner… also you probably want to make your cycle time lower!
27

28. micheleplayfair#DDDPerth
FORECASTING
Forecasting - Once we’ve started to become predictable, we can more safely assume
that our past performance is a reasonable indicator of how things will go in the
future. So for example in Brisbane in summer you can reasonably safely say that
tomorrow’s weather will be “hot, chance of rain” – but in Melbourne, not so much.
Bearing in mind of course that this is all a model and all models are wrong, but some
are useful.
Now there are a number of ways to do this – here is an example of a burndown chart
from our friend JIRA where it has predicted based on your team’s previous velocity,
that there are 6 sprints remaining.
This is OK but we can do better.
28

29. micheleplayfair#DDDPerth
PROBABILISTIC FORECASTING
focusedobjective.com/forecasting-techniques-effort-versus-reward/
Probabilistic forecasting for weather might be “what is the chance of rain
tomorrow?”. In the forecasting software world, this is normally “what is the chance
of finishing on or before date x.”
In a probabilistic forecast we look at what percentage of the possible results were
actually “on or before date x.” This allows us to say things like, “We are 85% certain to
deliver by 7th August.”
Good news is that probabilistic forecasting relies upon the input parameters being
non-exact.
29

30. micheleplayfair#DDDPerthPhoto by Tumisu
http://bit.ly/SimResources
Using Arthur C Clarke’s 3rd law – any sufficiently advanced technology is
indistinguishable from magic – this brings me to the crystal ball I promised you!! This
link will take you to a github repository full of amazing resources related to
forecasting and modelling from Troy Magennis of Focused Objective
The tool I used from this treasure trove for PROGNOSTICATION is the Throughput
Forecaster.
This sheet has a lot of features that duplicate some of the things you can get directly
out of JIRA so even less work for you – yay
I set up filters on the JIRA board that let you easily see the story counts per release so
we could track to complete for each milestone/goal/deadline and then you can just
add them to the sheet.
30

31. micheleplayfair#DDDPerth
TEAM 1
It’s also pretty flexible, I used it with 2 teams that were working in different ways – so
here’s some data input for team 1
Team 1
- we did a Tshirt sizing (Small, Medium, Large) on future stories which will give us
the max-min number to use in “How many stories remaining to be
completed”. For the min we assume that a Large/Spike will eventually break up
into 3 stories, a Med into 2 and a small = 1. For the max, Large/Spike = 5, Med = 3,
small = 1
- Therefore the low and high on splitting is the same at 1 – because we already
included the variance in the stories to complete.
- used kanban not sprints so we did this per week
- Used historical Data – I got the number of completed stories from the “Created vs
Resolved” issues report and just entered them into another sheet.
- If you didn’t have that you could put a low-high guess in the fields at the bottom
AND YOU GET… drumroll
31

32. micheleplayfair#DDDPerth
What is this witchcraft?? It’s a Monte Carlo simulator – using statistics and
probability to help visualise potential outcomes.
In this case the simulator will forecast how long it will take to complete features
based on the data entered - Using this information it hypothetically completes the
work 500 times and shows you the likelihood of success by date.
For us this was such a valuable output for such little work to create. Essentially we’re
estimating CONFIDENCE as well as TIME
32

33. micheleplayfair#DDDPerth
Simple, transparent and provides an indicator of our predictability!! Thanks Troy!
33

34. micheleplayfair#DDDPerth
THE TL;DR
1. Deadlines happen
2. Spend less time estimating, not more
3. Use storymapping (even in JIRA) to break up and visualise the work
4. Story counts, not story points
5. Focus more on throughput & cycle time
6. Try the Throughput Forecaster – estimate confidence as well as time
1. Deadlines happen
2. Spend less time estimating, not more
3. Use storymapping (even in JIRA) to break up and visualise the work
4. Story counts, not story points
5. Focus more on throughput & cycle time
6. Try the Throughput Forecaster - estimate confidence as well as time.
34

35. micheleplayfair#DDDPerth
THE DISCLAIMER
These are things that we tried and they worked for us – please don’t do the SPOTIFY
MODEL thing and think this is what you HAVE to do!
I hope I have given you some ideas and a starting point - Do a bit more research,
experiment, tweak – INSPECT AND ADAPT
35

36. micheleplayfair#DDDPerth
FOR MORE INFO – SEE THE WORKS OF:
➢ Jeff Patton
➢ Troy Magennis
➢ Ron Jeffries
➢ Neil Killick
➢ Mary & Tom Poppendieck
➢ Gojko Adzic
➢ Johanna Rothman
If you want to know more about how to manage your work in an agile way while still
dealing with the reality of WHEN WILL IT BE DONE?? and IS IT DONE YET??
Look into the books and posts done by
Jeff Patton, Troy Magennis, Ron Jeffries, Neil Killick, Mary & Tom Poppendieck, Gojko
Adzic and Johanna Rothman
36

37. IS IT DONE YET?
… YEP
37