41686Re: Sprint planning using team capacity and detailed tasks vs.story-level estimates
- Oct 2, 2009Reading your blog, I almost thought it was me who wrote it... spooky!!!
So many similarities. I tend to believe we will end up following a
similar plan but might stop short with just assigning hours to tasks but
not assigning resources. Letting the team "work it out" sounds like the
right plan - we just need to gradually mature in our process and get
there. The team really needs to start thinking about how they get stuff
done together to pump out completed stories together. I see signs of
that already starting to gel. Thanks for you insights..
--- In firstname.lastname@example.org, Alan Dayley <alandd@...> wrote:
> We had a team that started out doing estimates similarly to what you
> describe, for much of the same reasons. It worked better than the old
> way and I still think it was a good starting point. After more than
> 10, 2-week sprints, team recently shifted to story points. I
> documented the reasoning in my blog at:
> The biggest reason for our shift was our tendency to think it terms of
> MY tasks vs. HIS tasks instead of OUR tasks. Maybe that will be a
> problem for you, maybe not. Or maybe it will not be your biggest
> problem so starting out this way will be good for you so you can get
> started and work the bigger issues.
> Inspect and adapt. It's great you are seeking more knowledge, too!
> On Thu, Oct 1, 2009 at 9:23 PM, markpetronic markpetronic@... wrote:
> > 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...
- << Previous post in topic Next post in topic >>