I’m going to skip right over explaining what planning poker is and how it works - especially since there are so many simple and effective explanations out there - and assume that you’ve at least given it a bash.
What I want to address is the spirit in which group estimation happens.
Every potential task owner (read: qualified opinion) estimates each relevant task as it comes up, but the reason for this is commonly misinterpreted. The purpose is not to force the eventual task owner to reduce his or her estimate, or to adopt an estimate that others in the group ‘prefer’ and nor is it a criteria for selecting an owner for a task, based on the estimate the product owner or scrum master likes the most.
The purpose is to draw out knowledge from the outliers, so that the whole team can benefit from their experience. When someone in the group pulls a card miles away from the rest (assuming a consistent understanding of the task) that’s something to explore. You might have a much higher estimate – perhaps that person has been burnt before by that same inconspicuous looking requirement masking significant complexity. You might have a much lower estimate – perhaps that person knows a good work saving shortcut or pattern uncovered during a previous project.
If you take the time to ask those questions and consider that information, the group learns from one another and everyone gets better at estimating.
And whose estimate is used in the sprint? The person who is going to be doing the work...
Having just got out of our team planning meeting (with estimation on the brain) this article caught my attention.
In our case, no-one owns a task, we don't know who will be doing the work. This means the whole team must come to an agreement on the estimated story points for a story.
If there is a disagreement (which their often is) we get those with the highest estimate and the lowest to put forward their case, then after deliberation and explanation we re-estimate as a team. Should it not always be a team decision?
If it were down to opinion of one person doing the work, what would be the use of the cards, and for that matter allowing the team to contribute?
I totally agree that it is about 'drawing out knowledge' but if the knowledge of the task has truly been shared properly then the team should know enough to estimate the task accurately and come to a team agreement of SP to be used in the sprint, should it not?
thanks for leaving a comment - always appreciate them, especially when they come with a question.
I'd suggest that your tasks do have owners (because surely your whole team don't all develop against all stories?) you just aren't identifying them in your sprint planning - which does make me worry about your definition of "sprint planning" but that's another whole issue...
If it takes me an hour to run 10K, and it takes you 45 mins, then how is the organisation served by us choosing anything other than one of those numbers based on which one of us puts on our trainers? Either I'll go into cardiac arrest before crossing the finish line or you'll have to walk the last kilometer. Furthermore, does it matter what the team think or what they'd like to decide? I'm always going to take an hour regardless...
You will always have different levels of experience, different approaches, and different personalities in your team, and those individuals will take a different amount of time to complete a task. The time it takes from a project management perspective will always be the time the person doing the work needs, rather than your best or worst or median estimate.
It is always worthwhile involving every potential task owner because it draws out experience, promotes discussion and thought. The team should be kicking around different approaches and designs and should come to an agreement on that side of it, however once that agreement is reached, you're setting yourself up for a [potentially] nasty surprise using any estimate other than the person who is going to do the work.
ty, your posts are opening additional perspective about how to deal with tasks estimations on sprint planning.
Sometimes we seem to be so close to a good understanding about this as way of working...then after some days of sprint, well, the burndown chart starts looking different and watchers start panic.
What means for you (from the agile perspective) a deviation of 40% of a sprint estimation? What does it mean a 20% deviation? What could I identify/learn from there, as developer in the sprint?
thanks for the question Cristina
if your burndown charts are getting that far out of whack then either your estimates are out or your tasks are not tightly enough defined (and grow in scope during a sprint).
I would suggest that your first point of reference should be your retrospective. You should have one after each sprint and you should tackle this head on with the whole team. Ask yourselves if you really included everything in your estimate (not just coding time but time to write tests and integrate etc) and ask if you broke down the tasks into granular enough blocks and if they were understood well enough before being locked into a sprint.
From a PM perspective you might also want to make sure that holidays and meetings and other known activities the team must engage in are considered - anywhere that you might leak time on things other than in-sprint tasks must also be accounted for.
Wherever you're coming unstuck, regular, honest, and blame free retrospectives after each sprint will be the best way to learn from it and change future outcomes.
Post a Comment