Today was interesting… we did our first sprint planning meeting with a team of 5 people. After I’d sat with the designated Product Owner (a BA with a passion for the project) and created what I think is a sufficient product backlog, I explained the concepts of Scrum to the team (especially around estimation and effort) as I was taught and we actually managed to determine our first sprint backlog. I did have one question regarding the burndown chart though, and having researched it in “Agile Software Development with Scum” and I realized what I was taught is different (in implementation) to what they say in the book. Boris estimates using what I think are “weightings” for tasks (relative to one another), the book demonstrates the use of “hours” to measure effort, although the “hours” are not commitments but only estimations made “as a team”. This seems a little more logical to me as well. I’ll take it to the team and see what they think, afterall, in the end its only important that you have a decent burndown chart with decent tracking isn’t it?
Hi – be please very careful with the estimates.
1) Ken describes a effort estimation of TASKS for creating the Sprint Burn Down Chart
2) I described in the class the estimation / sizing technique for FEATURES in relative sizes: Story Points.
3) For the Sprint Burn Down Chart we / I uses not the Sprint Burn Down Chart described by Ken anymore. It focus on hours of tasks. That means you start estimating effort!!!!!!! That is in my view not useful.
4) I explained in the class, that I do estimate in the Sprint Planning Session 1 at all anymore because you start to based you commitment on estimates not on the willingness of the people if they believe they can do and if the want to do the work.
5) No – at the end it is not important to have “decent burndown chart with decent tracking” – at the end you need to have potential shippable product increment.
boris