41774RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
- Oct 8, 2009
Some people work better when there is a sense of urgency when work are time boxed. This may have nothing to do with " PROPHECY" or wanting to be correct in estimating.
--- On Thu, 10/8/09, Roy Morien <roymorien@...> wrote:
From: Roy Morien <roymorien@...>
Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
Date: Thursday, October 8, 2009, 5:36 AM
Why do you, like so many others, place such first-up importance on estimating? Frankly, my suggestion would be to concentrate on getting into the swing of things with an iterative approach, having your reviews, producing stuff that works, making the user happy by taking their change requests seriously and dealing with them in a timely fashion, and settle into this scheme of things.
More ACTION, Less PROPHECY! It is more important to demonstrate the fast-lane production of working software components than struggling with the question of how long it might take, and how correct you are in that estimate.
If you take on too much in a sprint, then that'll be a lesson for you. If you take on too little, then there is nothing that says you can't grab another story to develop. You'll soon get the hang of it.
To: scrumdevelopment@ yahoogroups. com
From: markpetronic@ gmail.com
Date: Fri, 2 Oct 2009 04:23:35 +0000
Subject: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
I'm trying to introduce Scrum and Agile practices into my company which is very waterfall based. I have done a lot of reading on Agile practices and attended a certified SM training course recently. I have a team of 6 plus me as SM. We are all trying to be productive and learn how to do this at the same time. It's fun and challenging at the same time. My basic question revolves around how accurately a team should try to estimate their time during sprint planning? We started with 2 4-week sprints and decided we needed to move to 2-week sprints so we can have more frequent opportunities for feedback and adjustments. We just planned our first 2-week sprint this week. In doing so, we started by pulling the top ranked stories and adding tasks and tests. We tried to estimate each task so that each team member's ideal hours for the sprint were accounted for using 6 hours/day as each person's ideal hours. Historically, I know that is probably optimistic and we can adjust as we see how this goes over time. Since we don't know what our velocity is yet it's hard to judge what we can do at this point based on story points. We estimated the stories by trying to use ideal days instead of story points because we are all having trouble getting our minds around story points. Should we really be concerned with trying to account for everyones total capacity during detailed planning of tasks? Is this going too far? Another area we had some trouble with was tasks where two or more team members worked together. Should we define one task per person? Seems like overkill and I think is coming from the MS Project past where you assign resources to tasks and get a total man-hours that represents the product of N resource times X hours for that task.Here's a very specific question regarding this topic: Let's say we decide to plan a spike to look into something like, "Do we need a OS abstraction layer framework or not for our product and if so, how should it be designed?" We time box it for 2 hours but 4 members of the team are going to participate. That's 8 hours. Should I just specify a story that reflects 8 hours or create a design spike story and assign four tasks (one for each person) and reflect each will spend 2 hours?Thanks in advance for your wisdom and insights...
Check out The Great Australian Pay Check Take a peek at other people's pay and perks
- << Previous post in topic Next post in topic >>