No more time based estimates

We recently switched from a mix of velocity and timebased estimations to pure velocity based planning.

How did we work in the past?
The product owner selects a number of user stories, which are sorted by priority.
She uses the velocity of the previous sprints to know how many story points worth of user stories she can select.
During the sprint planning meeting, the team discusses the user stories and creates tasks which they give a realistic time estimate.
They make sure every task is less than one dev day.
When every user story is tackled, we compare the total time of all tasks to the available time of the team (which they each wrote down on a flipchart in the beginning of the meeting).
If the total time of tasks exceeds the available time of the team, we remove the lowest priority user story.  And so on until the total time of tasks fits into the available time of the team.

Is this even a usefull effort?  Even on task level, it it still guessing in most cases.

During the sprint, the team maintains the burndown by counting the remaining tasks versus the total tasks. 
They don’t count the hours or subtract time from the task estimates.
The general feeling is, since the tasks are so small, the effort to maintain and update the time estimates doesn’t provide additional value.
We get an accurate enough view of our progress by just looking at the number of tasks.

So we decided to leave out the time estimates on task level during sprint planning as well.  We commit to our velocity, and not to estimated hours versus available hours.
Quite scary and it may sounds crazy to people working in a more traditional approach.
But hey, you can’t predict the future, so why pretend to?  Instead we work every week on our story point estimations.
This means we get better at it and our commitment versus velocity should improve every sprint.
I strongly believe in this approach.  We know the past, so why not learn from it and use it in our benefit?

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: