The slides from the Amsterdam Scrum Gathering Idea Camp on "Improve your planning by *NOT* estimating. Check http://RedGreenRefactor.eu/blog for more ! [This is slightly updated version from 23-04-2011]

1. Improve your planning...
by not estimating.
Marcin Czenko
RedGreenRefactor.eu
Eindhoven

2. Who you are ?
• Developers/Testers
• Scrum Masters
• Product Owners
• Coaches/Mentors/
Trainers
• Non-scrum monsters

3. Believe me there is a lot I can say about it...

4. My reference...

5. So how does it work ?
• Story points for User
Stories and Epics.
• Hours for tasks.
• THIS IS THE MOST
COMMON WAY,
BUT I AM GOING
TO CHALLENGE
THAT.

6. Estimating User Stories...

7. Estimating tasks
•ideal hours - not real hours.
•you are introducing time, so expect the
question like: is the time estimate per
person ? HINT: estimate like you where
doing it alone.
What about Pair Programming ?

8. Alice Bob
Kate Mr.T.

9. Yes ! Why do you want to
estimate tasks ?

10. Why would like to know
that ????
Because I want to know the
difference between the
estimate and the actual time
needed to finish a task.

11. Hmm, uhh, aff, ehh,...
If I know that I can find out how
much time in average costs me one
story point.
Well...
I thought that the team
commits to User Stories and
not to Tasks...

12. And if you guys additionally log the
time for different activities I will
actually know what cost me most of
my money. (Read: do less testing
please, or limit refactoring slightly...)

13. Time Logging for different
activities
• Developers don’t like it. It is not exiting and
lowers productivity because it has to be
done continuously - otherwise the data are
worth nothing. Developers often do not do
it carefully.
• Developers are quite intelligent - they know
how to fill the bill to give the manager what
she wants.

14. And beside that
• What about self-standing, self-organizing teams ?
• Is increasing the control really the only way ?
• The team has retrospectives to find out the most
appropriate correcting actions. Come to listen...
• Does anybody actually do any analysis of the logged
time data (these must be those super-natural statistical
skills mentioned during every 6-sigma training).

15. Finally...
• Does it take us any closer to the next
successful release ?
• Is the team velocity not sufficient to tell
where we really are ?

16. Don’t you know that the same
task on Monday can take twice as
long as the same task on Friday ?
We even do not know who will
be working on the task...
My ideal day is not your ideal day !!!
Hmm... Ok, forget about logging
time for different activities. Let’s just
estimate tasks, oke ?

17. That’s why I am going to use
average.
Is our average velocity not
enough for you to know where
we are ?

18. I think you should trust us a little
bit more...And how do you want
to estimate tasks so that it makes
sense for you ?
Well, yeah, but I have to wait the whole
SPRINT to see what’s going on ! I can’t wait
that long ! I would like to have a little bit more
control over what you are actually doing.

19. Let’s use our planning poker
cards. We can use the same
“intervals” as we use for story
points in our user stories.
Do you mean 1,2,3,5,8,13,... ?
Yep..

20. Different ?
Sounds logical, but aren’t
tasks somehow different
from stories ?
Let me explain. It is said
that for the best focus
your tasks should be
small, right ?
Yeah, but what does
it mean small ?
Well, small means that
you know well what work
has to be done. Still, it is
quite hard to say how
long will it take. It should
not take long that’s all.
Fine, let’s make them
small than, 1-2h
should do.

21. I think that such a small
granularity during the
planning session would
be an overkill. It looks
almost like an up-front
design to me. I am pretty
sure that half of these
tasks will be wrong or not
needed anyway.
What do you
propose, wise girl ?
I would say, lets make our tasks open. As we do with user
stories. Later when we work on them we can still split them
into smaller tasks, so that we can keep focused. For now,
let’s create tasks only for things we know that they must
happen in this or other form. If thinking about time really
helps you, I would propose that we try to make most of our
tasks around half-day long. We will not waste time to
estimate them though.

22. Cool, finally this
session will take
half an hour not
half a day :).
Right.
Maybe you are
right guys..

23. Let’s try it then.

24. If you got lost...
• Follow the don’t repeat
yourself rule: DRY. (Ruby
people there ?)
• During the planning stay
open. Don’t go for
precision.You just got rid
of fake precision by doing
Scrum, right ?
• If you need to be more
concrete during planning,
do not do it at the very
end. Many people start to
hurry at the end and
some of them want to
leave sooner. If it is hard
to make it right, you most
certainly will have to
rethink it later.

25. Remark
I used to estimate tasks in order to check that their sum
does not deviate significantly from the the time the team
actually has. Later I realized that it actually does not say
anything (the tasks were wrong, not needed, and some of
them were left open).

26. How are we going to track the
progress within the sprint then ?

30. Do you remember when I said
that the same task on Monday can
take twice as long as the same
task on Friday ?
Yes...?
Sure, we
did !
Ehh ...?!!
Together !

31. What about user stories than ?
It is easy: one story point today can take
twice as long to implement that the same
one story point another time ?
You got it, Mr T. !

32. Hold on guys ! Let’s begin with
tasks first.

33. User Stories
• What if we apply the same rule to the user
stories ?
• What do you think ?

34. Conclusions
• Vote: Hot-or-not ?