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?