41681Re: Sprint planning using team capacity and detailed tasks vs.story-level estima
- Oct 2, 2009--- In firstname.lastname@example.org, "Gert Wallis" <pragmatic.gert@...> wrote:
> you cover a lot of ground in this posting.
> > My basic question revolves around how accurately a team should try to estimate their time during sprint planning?
> As accurately as the time allocated allow you to do. In other words - this activity must be time boxed. You are looking for that magic point of "just enough time" to give you a reasonably good estimate. Time-box the planning session - if it is too long you will start to get into too much detail. If too little you won't cover enough time. As team lead -step out of the room and let the team sort it out.Good idea on time boxing the meeting. I'm trying to be diligent to minimizing the meetings. Stepping out is a good idea...
> > 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.
> This type of confusion arises because you think of trying to estimate the story in a unit of time. You should think of it as a size estimate. How big is this story in relation to the rest. Choose one story that everybody agrees on the size and extrapolate and generate it from there. I would recommend Mike Cohn's book to help you work through this concept.I am reading "Agile Planning and Estimating". It's still hard to get the hang of this but, intuitively, my gut says this is the way to go... using size not time. It's especially hard being this is our first time and we don't have a reference point. No matter how hard we try, we keep finding the time still creeps in as the underlying measure - even when we tried to use size. Will keep plugging away at it. :)
> > Should we really be concerned with trying to account for everyones total capacity during detailed planning of tasks? Is this going too far?
> This is what Alan was trying to say. There is no "me" in "team". Stories are given to the team to implement.Agree. We have been talking about shifting our thinking to "group think" and "group do".
> > Another area we had some trouble with was tasks where two or more team members worked together. Should we define one task per person?
> No - definitely not, what you are trying to do is get the whole team involved to execute all the tasks. You have to break the cycle of I'm the UI or database guy. If the sprint only involves UI priorities - everybody is working on UI.Gotcha
> > 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?
> In my experience these research type problems were the only time where I would have a time / story point correlation. The warning sign was if everything you do is estimated like this. You are dealing with an unknown - if you knew the answer you would be able to estimate it. Make sure that you place boundaries and a fixed time box around it. Without it this could develop into a boundary less task.I would not try to break it down into hours and a per person correlation but rather as a size / "how big" estimate.Ok, makes sense. Have the team solve the spike in maybe a real small story of say 1 point or less even with the understanding that there is some pre-agreed to time box on the whole thing and let the team figure out how to best manage their time and who should participate.Thanks for your comments, Gert!!!
- << Previous post in topic Next post in topic >>