Loading ...
Sorry, an error occurred while loading the content.

Re: Sprint planning using team capacity and detailed tasks vs.story-level estimates

Expand Messages
  • markpetronic
    Reading 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
    Message 1 of 19 , Oct 2, 2009
    • 0 Attachment
      Reading 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..

      Mark

      --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...> wrote:
      >
      > Hello,
      >
      > 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:
      > http://blog.dayleyagile.com/2009/09/21/work_stories_not_tasks/
      >
      > 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!
      >
      > Alan
      >
      > 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...
      >
    • Roy Morien
      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
      Message 2 of 19 , Oct 8, 2009
      • 0 Attachment
        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.
         
        Regards,
        Roy Morien
         

        To: scrumdevelopment@yahoogroups.com
        From: markpetronic@...
        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
      • Michael Yip
        Roy, 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
        Message 3 of 19 , Oct 8, 2009
        • 0 Attachment

          Roy,

          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.

          Michael


          --- 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
          To: scrumdevelopment@yahoogroups.com
          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.
           
          Regards,
          Roy Morien
           


          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
        • Ron Jeffries
          Hello, Michael. On Thursday, October 8, 2009, at 7:13:00 AM, you ... I suspect that at the beginning one needs no urgency, and no estimation or estimation
          Message 4 of 19 , Oct 8, 2009
          • 0 Attachment
            Hello, Michael. On Thursday, October 8, 2009, at 7:13:00 AM, you
            wrote:

            > 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.

            I suspect that at the beginning one needs no urgency, and no
            estimation or estimation tracking. One needs to start writing
            software and getting it done.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            Will Turner: This is either madness or brilliance.
            Captain Jack Sparrow: It's remarkable how often those two traits coincide.
          • mike.dwyer1@comcast.net
            Ron The most interesting muscle memory we break with agile and scrum is the importance a good time estimation and replacing it with a focus on steady delivery
            Message 5 of 19 , Oct 8, 2009
            • 0 Attachment
              Ron
              The most interesting muscle memory we break with agile and scrum is the importance a good time estimation and replacing it with a focus on steady delivery of value. Roy is completely on target.

              Mike Dwyer

              Sent via BlackBerry by AT&T


              From: Ron Jeffries <ronjeffries@...>
              Date: Thu, 8 Oct 2009 07:53:00 -0400
              To: <scrumdevelopment@yahoogroups.com>
              Subject: Re: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

               

              Hello, Michael. On Thursday, October 8, 2009, at 7:13:00 AM, you
              wrote:

              > 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.

              I suspect that at the beginning one needs no urgency, and no
              estimation or estimation tracking. One needs to start writing
              software and getting it done.

              Ron Jeffries
              www.XProgramming. com
              www.xprogramming. com/blog
              Will Turner: This is either madness or brilliance.
              Captain Jack Sparrow: It's remarkable how often those two traits coincide.

            • JackM
              My answers inline tagged with jm ... JM A lot of teams I work with struggle with Story Points at first. It s fine to start with 1 SP = 1 Ideal hour.
              Message 6 of 19 , Oct 8, 2009
              • 0 Attachment
                My answers inline tagged with "jm>>"

                --- In scrumdevelopment@yahoogroups.com, "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?

                JM>> A lot of teams I work with struggle with Story Points at first. It's fine to start with 1 SP = 1 Ideal hour. After a couple sprints you can switch easily to Story Points as you have a baseline to compare with.

                If you're doing things the Scrum way then yes you should break your user stories down into tasks and estimate the tasks in hours - total them and see if you're close to the capacity you have. If not you have to adjust the plan a bit i.e. remove some stuff.

                Just so you know the XP folks work strictly at the story level and don't necessarily break stories down into tasks. They also only track either story points per sprint or # of stories per sprint. THey don't bother with hours

                I personally still work with tasks and hours for the burndown But use story points for release and sprint planning.


                Another area we had some trouble with was tasks where two
                > or more team members worked together. Should we define one task per
                > person?

                jm>> If you're pairing then hope full the tasks are shared so one task or one story per pair


                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...
                >

                JM>> yes i would specify a task that reflects 8 hours. otherwise if you don't your capacity calculations will be off
              • markpetronic
                I definitely want to move away from very detailed estimates, However, being that I am introducing Agile into a very non-Agile company at the moment, I have to
                Message 7 of 19 , Oct 8, 2009
                • 0 Attachment
                  I definitely want to move away from very detailed estimates, However, being that I am introducing Agile into a very non-Agile company at the moment, I have to walk on two roads at once. First is my goal to implement Scrum and Agile using the best practices to the greatest extent possible. Our team not only has to produce a high visibility system but also will be "judged" on "oh, that's the team that tried to do Agile - so how's that working out...?" Secondly, I have execs asking for "when it will be done?". I'm pushing back and trying to get them to understand and adjust their thinking to the way Agile planning works. But, don't be naive, this is going to be a slower process of change that I would like. I don't want to fail to deliver the product successfully and I don't want to fail at introducing Agile into the company. I don't want us to be the reason why some old-school exec says, "oh ya, they tried Agile and it failed. See, told you our way was better." So, as SM, I'm trying to let the team work independently of these issues and take is as my job to shield them of this stuff so they can function as close to "preferred Agile practices" as possbile.

                  So, for me, I HAVE to strike a careful balance right now. I've already been asked for schedules for weeks - over a month - and still have not provided one because I'm trying to push the envelope and see how much the execs will take before I have to try and "fabricate" some schedule that says, ya, we will be done on April 24, 2010. We know that does not work.

                  So, I have to train and encourage my team as best I can and part of that is being able to estimate more quickly without trying to drill down into every detail. We spent some time yesterday, as an example - I bought them lunch - and we ate together and we tried to do some backlog grooming at the story level by just trying to spend 3 minutes on each story. Discussed it, and used planning poker to dial in the estimates. I needed that so I could use our velocity to project out when I think this release will be done (to satisfy the "when will it be done requests I keep getting". I believe that is a good practice. A lot of discussion came out of this concerning architecture issues that we need to plan to discuss in the future, acceptance testing, definition of done, all good stuff.

                  Once we get more comfortable with story point estimations I think the sprint planning session will go quicker and we will be able to more quickly define and estimate tasks as a way to ensure we are at least talking about all the pieces we think we need to commit to building in the iteration. If you don't understand what is expected, how can you make a commitment? Also, this is a very new development environment so we cannot build on what we already know. Doing a big Java component for the first time but we have somewhat limited experience in Java development. So, there's a learning curve. We are moving from Windows to Linux based component. Another learning curve for both the OS and using other tools (Eclipse/Linux instead of Visual Studio). So, there are a lot of obstacles to deal with.

                  That said, I appreciate your candid comments but just think you need to know that there is a lot going on here and we are only really two sprints into this with the first being consumed with nearly all development environment setup.

                  I appreciate any recommendations you all have from the perspective of doing a grass roots introduction of Agile into a company that does not use a "true" Agile process anywhere. Maybe mini-waterfall here and there, but that does not count. It will take awhile to turn this big ship but I'm confident that it can and will be done. BTW, I am getting others educated. There is another small 4 person team (+ 3 in India) trying Scrum on some small project. And I am talking to a lot of other "key" players in the company that tell me they are interested in discussing Agile. However, our team is the only one that if fully taking on a Scrum-based project from start to finish and this project is probably going to take at least 18 months to complete in multiple phases.

                  Thanks,
                  Mark

                  --- In scrumdevelopment@yahoogroups.com, Michael Yip <myip11@...> wrote:
                  >
                  >
                  > Roy,
                  >
                  > 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.
                  >
                  > Michael
                  >
                  >
                  > --- 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
                  > To: scrumdevelopment@yahoogroups.com
                  > 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.
                  >
                  >  
                  >
                  > Regards,
                  >
                  > Roy Morien
                  >  
                  >
                  >
                  > 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
                  >
                • Michael James
                  ... This is one of the best arguments I ve heard for phasing out tasks. Teams should go with their gut feeling, not try to map out every hour of the Sprint.
                  Message 8 of 19 , Oct 8, 2009
                  • 0 Attachment
                    On Oct 8, 2009, at 10:32 AM, JackM wrote:

                    > estimate the tasks in hours - total them and see if you're close to
                    > the capacity you have

                    This is one of the best arguments I've heard for phasing out tasks.
                    Teams should go with their gut feeling, not try to map out every hour
                    of the Sprint. If it's complex work, a task burndown chart is likely
                    to go up before it goes down, unless we've padded it....

                    --mj
                  • Adam Sroka
                    Hi Mike: I m actually somewhere in the middle with this one. I think that for most teams it is a progression which starts with getting good at estimating in
                    Message 9 of 19 , Oct 8, 2009
                    • 0 Attachment
                      Hi Mike:

                      I'm actually somewhere in the middle with this one. I think that for
                      most teams it is a progression which starts with getting good at
                      estimating in story points, getting stuff done, and having a
                      consistent burndown. Phase two is to get really good at breaking
                      stories down so that every story is small but has business value.
                      Finally, you arrive at what Ron is suggesting. They are all about the
                      same size and you know you can get them done in a day or two. When
                      they're any bigger than that you just break them down. No need to
                      estimate.

                      So I guess I agree with Ron, I just think it takes a while to get
                      there and estimating is a remedial practice in the meantime.

                      As for estimating tasks in hours, we know that we are statistically
                      off by +/-40%. We have the studies to prove it. That's just a tad bit
                      better than random guessing. Seems like we'd be better of using that
                      time for something more valuable.

                      What I actually like is this:
                      1) Name your tasks so that you have a clear understanding of what
                      needs to be done. Don't track tasks individually or estimate them.
                      2) Once you agree on what the task are estimate in story points.
                      3) Keep the range of story points small. I use 1, 2, and 3. Where 1 is
                      small and 2 is big but both are much smaller than an iteration
                      (probably a day or two like Ron says.) 3 is big, but I don't know how
                      to break it down smaller. Every time I see that three it is a reminder
                      to try. Still, I can do a three inside a week. Any bigger than that
                      and I'm risking my Sprint. Any bigger than that and it must be broken
                      down.

                      If you can get a team to the point where it is doing it this way and
                      is delivering value every sprint then you are probably close to being
                      able to do it Ron's way.

                      Another approach might be to measure cycle times and determine the
                      average size of a story that way. Sort of a Kanban hybrid. I like this
                      idea, but I've yet to try it.

                      Joshua Kerievsky says that his team does a kind of "Ultra Lean" where
                      they just do stories one at a time. Stories are all about the same
                      size, but there is no timebox. You just get a story and do it until
                      it's done. There is no Sprint review. Showing the implemented story to
                      the customer is part of the definition of done. I really, really like
                      the idea, but I'm not sure I've met more than a couple teams who I
                      think could pull that off. It might be a worthy place to try to get
                      once you've mastered what Ron is suggesting.

                      Anyway, my point is that it's all about continuous improvement. There
                      isn't a right way. Just levels of goodness that teams can strive for.

                      On Thu, Oct 8, 2009 at 6:04 AM, <mike.dwyer1@...> wrote:
                      >
                      >
                      >
                      > Ron
                      > The most interesting muscle memory we break with agile and scrum is the importance a good time estimation and replacing it with a focus on steady delivery of value. Roy is completely on target.
                      >
                      > Mike Dwyer
                      >
                      > Sent via BlackBerry by AT&T
                      >
                      > ________________________________
                      > From: Ron Jeffries <ronjeffries@...>
                      > Date: Thu, 8 Oct 2009 07:53:00 -0400
                      > To: <scrumdevelopment@yahoogroups.com>
                      > Subject: Re: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                      >
                      >
                      > Hello, Michael. On Thursday, October 8, 2009, at 7:13:00 AM, you
                      > wrote:
                      >
                      > > 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.
                      >
                      > I suspect that at the beginning one needs no urgency, and no
                      > estimation or estimation tracking. One needs to start writing
                      > software and getting it done.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > www.xprogramming.com/blog
                      > Will Turner: This is either madness or brilliance.
                      > Captain Jack Sparrow: It's remarkable how often those two traits coincide.
                      >
                      >
                    • Roy Morien
                      Why isn t there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn t stop myself with that ) from
                      Message 10 of 19 , Oct 8, 2009
                      • 0 Attachment
                        Why isn't there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn't stop myself with that  ) from the traditional approach surely brings with it some excitement and anticipation of success, and maybe even a little bit of fear of failure, so this will instill a sense of urgency, I would suggest (and hope).
                         
                        Timeboxing is not essentially about estimating and being accurate in estimates. The mere fact that you have a timebox, and you have undertaken to complete a certain set of tasks in that time, instills the sense of urgency. As I said before, so what if you take on too much and don't complete it. In a seriously trying team, that just means you were over-enthusiastic at the start; not a bad thing, i would suggest.
                         
                        Anyway, let's ot be controversial about this. Good idea to go agile. I applaude it (and so would everyone else who contributes to this forum). So ... Go Man! Do it, don't just talk about it! Write code, not documentation! Deliver value!
                         
                        Regards,
                        Roy Morien
                         

                        To: scrumdevelopment@yahoogroups.com
                        From: myip11@...
                        Date: Thu, 8 Oct 2009 04:13:00 -0700
                        Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

                         

                        Roy,

                        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.

                        Michael


                        --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:

                        From: Roy Morien <roymorien@hotmail. com>
                        Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                        To: scrumdevelopment@ yahoogroups. com
                        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.
                         
                        Regards,
                        Roy Morien
                         


                        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


                        Check out The Great Australian Pay Check Take a peek at other people's pay and perks
                      • Michael James
                        One thing I ll add: *too much* of a sense of urgency reduces creativity, according to outside observers grading the results (though the people in the study
                        Message 11 of 19 , Oct 8, 2009
                        • 0 Attachment
                          One thing I'll add: *too much* of a sense of urgency reduces
                          creativity, according to outside observers grading the results (though
                          the people in the study thought they were being more creative). There
                          is an optimum level of anxiety for best performance, and most of us
                          are wayyy above it already.

                          I still prefer timeboxes and iterations, just want to de-stigmatize
                          "failure" to get it all done, as the stigma can prevent learning.
                          Take a failure bow, retrospect, and move on.

                          --mj


                          On 10/8/09, Roy Morien <roymorien@...> wrote:
                          >
                          > Why isn't there a sense of urgency in what I said? Adopting a new
                          > development approach that is so RADically (sorry, I couldn't stop myself
                          > with that ) from the traditional approach surely brings with it some
                          > excitement and anticipation of success, and maybe even a little bit of fear
                          > of failure, so this will instill a sense of urgency, I would suggest (and
                          > hope).
                          >
                          >
                          >
                          > Timeboxing is not essentially about estimating and being accurate in
                          > estimates. The mere fact that you have a timebox, and you have undertaken to
                          > complete a certain set of tasks in that time, instills the sense of urgency.
                          > As I said before, so what if you take on too much and don't complete it. In
                          > a seriously trying team, that just means you were over-enthusiastic at the
                          > start; not a bad thing, i would suggest.
                          >
                          >
                          >
                          > Anyway, let's ot be controversial about this. Good idea to go agile. I
                          > applaude it (and so would everyone else who contributes to this forum). So
                          > ... Go Man! Do it, don't just talk about it! Write code, not documentation!
                          > Deliver value!
                          >
                          >
                          >
                          > Regards,
                          >
                          > Roy Morien
                          >
                          >
                          >
                          > To: scrumdevelopment@yahoogroups.com
                          > From: myip11@...
                          > Date: Thu, 8 Oct 2009 04:13:00 -0700
                          > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and
                          > detailed tasks vs.story-level estimates
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          > Roy,
                          >
                          > 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.
                          >
                          > Michael
                          >
                          >
                          > --- 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
                          > To: scrumdevelopment@yahoogroups.com
                          > 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.
                          >
                          > Regards,
                          > Roy Morien
                          >
                          >
                          >
                          >
                          > 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
                          >
                          >
                          >
                          >
                          >
                          >
                          > _________________________________________________________________
                          > Take a peek at other people's pay and perks Check out The Great Australian
                          > Pay Check
                          > http://clk.atdmt.com/NMN/go/157639755/direct/01/

                          --
                          Sent from my mobile device
                        • Michael Yip
                          Roy,   Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure
                          Message 12 of 19 , Oct 8, 2009
                          • 0 Attachment
                            Roy,
                             
                            Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure and definately not being traiditonal. Extremenly surprised and by your claim. Sorry
                             
                            Michael
                             

                            --- 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
                            To: scrumdevelopment@yahoogroups.com
                            Date: Thursday, October 8, 2009, 11:08 PM

                             
                            Why isn't there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn't stop myself with that  ) from the traditional approach surely brings with it some excitement and anticipation of success, and maybe even a little bit of fear of failure, so this will instill a sense of urgency, I would suggest (and hope).
                             
                            Timeboxing is not essentially about estimating and being accurate in estimates. The mere fact that you have a timebox, and you have undertaken to complete a certain set of tasks in that time, instills the sense of urgency. As I said before, so what if you take on too much and don't complete it. In a seriously trying team, that just means you were over-enthusiastic at the start; not a bad thing, i would suggest.
                             
                            Anyway, let's ot be controversial about this. Good idea to go agile. I applaude it (and so would everyone else who contributes to this forum). So ... Go Man! Do it, don't just talk about it! Write code, not documentation! Deliver value!
                             
                            Regards,
                            Roy Morien
                             

                            To: scrumdevelopment@ yahoogroups. com
                            From: myip11@yahoo. com
                            Date: Thu, 8 Oct 2009 04:13:00 -0700
                            Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

                             

                            Roy,

                            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.

                            Michael


                            --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:

                            From: Roy Morien <roymorien@hotmail. com>
                            Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                            To: scrumdevelopment@ yahoogroups. com
                            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.
                             
                            Regards,
                            Roy Morien
                             


                            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


                            Check out The Great Australian Pay Check Take a peek at other people's pay and perks
                          • Adam Sroka
                            Radical means Favouring fundamental change, or change at the root cause of a matter. Timeboxing isn t about creating a sense of urgency. Timeboxing is about
                            Message 13 of 19 , Oct 8, 2009
                            • 0 Attachment
                              Radical means "Favouring fundamental change, or change at the root
                              cause of a matter."

                              Timeboxing isn't about creating a sense of urgency. Timeboxing is
                              about having a shared expectation and commitment of when we will
                              perform a certain activity. In Scrum it is about when we will engage
                              in the various group ceremonies. Working from 9 to 5 is an example of
                              a timebox with a very similar purpose.

                              Having stuff done at a particular time means that we can get together
                              and review that progress. Good teams achieve some measure of "done" in
                              much less time than an iteration. For example, if you are doing TDD
                              and Continuous Integration well there is a measure of "done" that
                              occurs many times a day.

                              On Thu, Oct 8, 2009 at 9:04 PM, Michael Yip <myip11@...> wrote:
                              >
                              >
                              >
                              > Roy,
                              >
                              > Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure and definately not being traiditonal. Extremenly surprised and by your claim. Sorry
                              >
                              > Michael
                              >
                              > --- 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
                              > To: scrumdevelopment@yahoogroups.com
                              > Date: Thursday, October 8, 2009, 11:08 PM
                              >
                              >
                              > Why isn't there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn't stop myself with that  ) from the traditional approach surely brings with it some excitement and anticipation of success, and maybe even a little bit of fear of failure, so this will instill a sense of urgency, I would suggest (and hope).
                              >
                              > Timeboxing is not essentially about estimating and being accurate in estimates. The mere fact that you have a timebox, and you have undertaken to complete a certain set of tasks in that time, instills the sense of urgency. As I said before, so what if you take on too much and don't complete it. In a seriously trying team, that just means you were over-enthusiastic at the start; not a bad thing, i would suggest.
                              >
                              > Anyway, let's ot be controversial about this. Good idea to go agile. I applaude it (and so would everyone else who contributes to this forum). So ... Go Man! Do it, don't just talk about it! Write code, not documentation! Deliver value!
                              >
                              > Regards,
                              > Roy Morien
                              >
                              > ________________________________
                              > To: scrumdevelopment@ yahoogroups. com
                              > From: myip11@yahoo. com
                              > Date: Thu, 8 Oct 2009 04:13:00 -0700
                              > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                              >
                              >
                              > Roy,
                              >
                              > 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.
                              >
                              > Michael
                              >
                              >
                              > --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:
                              >
                              > From: Roy Morien <roymorien@hotmail. com>
                              > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                              > To: scrumdevelopment@ yahoogroups. com
                              > 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.
                              >
                              > Regards,
                              > Roy Morien
                              >
                              >
                              > ________________________________
                              > 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
                              >
                              > ________________________________
                              > Check out The Great Australian Pay Check Take a peek at other people's pay and perks
                              >
                              >
                            • Roy Morien
                              Whilst I really didn t want this to start a whole stream of debate I will go along with any discussion. No, I disagree, as others already have, with your view
                              Message 14 of 19 , Oct 9, 2009
                              • 0 Attachment
                                Whilst I really didn't want this to start a whole stream of debate I will go along with any discussion.
                                 
                                No, I disagree, as others already have, with your view of 'radical'. Whatever the received definition of the term is, I used it to imply a new, different, and possibly controversial situation.
                                 
                                I also stand by my statement that a fear of failure can be a driver of an attitude of urgency. However, I did not mean, in any way, that we should all have our hearts in our mouths waiting for the axe to fall level of fear.  I am thinking of 'a fear of failure' as wanting to achieve success, and being aware of the possible consequences of not succeeding. That fear may be nothing more than a concern for the cost to my reputation. I want to be seen as being competent, and able to deliver the goods, so I fear the failure to do that, and that gives me an impetus, or a sense of urgency. 
                                 
                                I believe that there has far too often, in traditional projects, been a complete absence of fear of failure, and an associated absence of a sense of urgency, because, first, we have a plan, and we are going to work the plan, so success is inevitable, and second, we have a requirements document that is 'frozen', so we can't go wrong if we just deliver that, and finally, the deadline is years away so let's not get too uptight about it. 
                                 
                                I hope this clarifies, although I don't think debating the implications of 'a fear of failure' is all that important to us.
                                 
                                Regards,
                                Roy Morien

                                To: scrumdevelopment@yahoogroups.com
                                From: myip11@...
                                Date: Thu, 8 Oct 2009 21:04:31 -0700
                                Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

                                 
                                Roy,
                                 
                                Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure and definately not being traiditonal. Extremenly surprised and by your claim. Sorry
                                 
                                Michael
                                 

                                --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:

                                From: Roy Morien <roymorien@hotmail. com>
                                Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                                To: scrumdevelopment@ yahoogroups. com
                                Date: Thursday, October 8, 2009, 11:08 PM

                                 
                                Why isn't there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn't stop myself with that  ) from the traditional approach surely brings with it some excitement and anticipation of success, and maybe even a little bit of fear of failure, so this will instill a sense of urgency, I would suggest (and hope).
                                 
                                Timeboxing is not essentially about estimating and being accurate in estimates. The mere fact that you have a timebox, and you have undertaken to complete a certain set of tasks in that time, instills the sense of urgency. As I said before, so what if you take on too much and don't complete it. In a seriously trying team, that just means you were over-enthusiastic at the start; not a bad thing, i would suggest.
                                 
                                Anyway, let's ot be controversial about this. Good idea to go agile. I applaude it (and so would everyone else who contributes to this forum). So ... Go Man! Do it, don't just talk about it! Write code, not documentation! Deliver value!
                                 
                                Regards,
                                Roy Morien
                                 

                                To: scrumdevelopment@ yahoogroups. com
                                From: myip11@yahoo. com
                                Date: Thu, 8 Oct 2009 04:13:00 -0700
                                Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates

                                 

                                Roy,

                                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.

                                Michael


                                --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:

                                From: Roy Morien <roymorien@hotmail. com>
                                Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                                To: scrumdevelopment@ yahoogroups. com
                                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.
                                 
                                Regards,
                                Roy Morien
                                 


                                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


                                Check out The Great Australian Pay Check Take a peek at other people's pay and perks



                                Check out The Great Australian Pay Check Take a peek at other people's pay and perks
                              • JackM
                                I can t remember who said this so I can t give the proper attribution. But the point behind time boxing is stop starting and start finishing The point is to
                                Message 15 of 19 , Oct 9, 2009
                                • 0 Attachment
                                  I can't remember who said this so I can't give the proper attribution. But the point behind time boxing is "stop starting and start finishing"

                                  The point is to get on with it. One can get so bogged down in the minutia of things that if we don't time box, you will never get started.

                                  Jack
                                  www.agilebuddy.com
                                  twitter.com/agilebuddy (for great links to agile articles)
                                  blog.agilebuddy.com

                                  --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                                  >
                                  > Radical means "Favouring fundamental change, or change at the root
                                  > cause of a matter."
                                  >
                                  > Timeboxing isn't about creating a sense of urgency. Timeboxing is
                                  > about having a shared expectation and commitment of when we will
                                  > perform a certain activity. In Scrum it is about when we will engage
                                  > in the various group ceremonies. Working from 9 to 5 is an example of
                                  > a timebox with a very similar purpose.
                                  >
                                  > Having stuff done at a particular time means that we can get together
                                  > and review that progress. Good teams achieve some measure of "done" in
                                  > much less time than an iteration. For example, if you are doing TDD
                                  > and Continuous Integration well there is a measure of "done" that
                                  > occurs many times a day.
                                  >
                                  > On Thu, Oct 8, 2009 at 9:04 PM, Michael Yip <myip11@...> wrote:
                                  > >
                                  > >
                                  > >
                                  > > Roy,
                                  > >
                                  > > Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure and definately not being traiditonal. Extremenly surprised and by your claim. Sorry
                                  > >
                                  > > Michael
                                  > >
                                  > > --- 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
                                  > > To: scrumdevelopment@yahoogroups.com
                                  > > Date: Thursday, October 8, 2009, 11:08 PM
                                  > >
                                  > >
                                  > > Why isn't there a sense of urgency in what I said? Adopting a new development approach that is so RADically (sorry, I couldn't stop myself with that �) from the traditional approach surely brings with it some excitement and anticipation of success, and maybe even a little bit of fear of failure, so this will instill a sense of urgency, I would suggest (and hope).
                                  > >
                                  > > Timeboxing is not essentially about estimating and being accurate in estimates. The mere fact that you have a timebox, and you have undertaken to complete a certain set of tasks in that time, instills the sense of urgency. As�I said before, so what if you take on too much and don't complete it. In a seriously trying team, that just means you were over-enthusiastic at the start; not a bad thing, i would suggest.
                                  > >
                                  > > Anyway, let's ot be controversial about this. Good idea to go agile. I applaude it (and so would everyone else who contributes to this forum). So ... Go Man! Do it, don't just talk about it! Write code, not documentation! Deliver value!
                                  > >
                                  > > Regards,
                                  > > Roy Morien
                                  > >
                                  > > ________________________________
                                  > > To: scrumdevelopment@ yahoogroups. com
                                  > > From: myip11@yahoo. com
                                  > > Date: Thu, 8 Oct 2009 04:13:00 -0700
                                  > > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                                  > >
                                  > >
                                  > > Roy,
                                  > >
                                  > > 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.
                                  > >
                                  > > Michael
                                  > >
                                  > >
                                  > > --- On Thu, 10/8/09, Roy Morien <roymorien@hotmail. com> wrote:
                                  > >
                                  > > From: Roy Morien <roymorien@hotmail. com>
                                  > > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and detailed tasks vs.story-level estimates
                                  > > To: scrumdevelopment@ yahoogroups. com
                                  > > 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.
                                  > >
                                  > > Regards,
                                  > > Roy Morien
                                  > >
                                  > >
                                  > > ________________________________
                                  > > 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
                                  > >
                                  > > ________________________________
                                  > > Check out The Great Australian Pay Check Take a peek at other people's pay and perks
                                  > >
                                  > >
                                  >
                                Your message has been successfully submitted and would be delivered to recipients shortly.