Improve your planning...by not estimating.

Marcin CzenkoRedGreenRefactor.eu

Eindhoven

Who you are ?• Developers/Testers

• Scrum Masters

• Product Owners

• Coaches/Mentors/Trainers

• Non-scrum monsters

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

My reference...

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.

Estimating User Stories...

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 ?

Alice Bob

Kate Mr. T.

Yes ! Why do you want to estimate tasks ?

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.

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...

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...)

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.

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).

Finally...

• Does it take us any closer to the next successful release ?

• Is the team velocity not sufficient to tell where we really are ?

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 ?

That’s why I am going to use average.

Is our average velocity not enough for you to know where

we are ?

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.

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..

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.

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.

Cool, finally this session will take half an hour not

half a day :).

Right.

Maybe you are right guys..

Let’s try it then.

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.

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).

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

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 !

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. !

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

User Stories

• What if we apply the same rule to the user stories ?

• What do you think ?

Conclusions

• Vote: Hot-or-not ?