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

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

Expand Messages
  • Gert Wallis
    Mark, you cover a lot of ground in this posting. ... As accurately as the time allocated allow you to do. In other words - this activity must be time boxed.
    Message 1 of 19 , Oct 2, 2009
    • 0 Attachment
      Mark,

      you cover a lot of ground in this posting.

      > My basic question revolves around how accurately a team should try to estimate their time during sprint planning?
      As accurately as the time allocated allow you to do. In other words - this activity must be time boxed. You are looking for that magic point of "just enough time" to give you a reasonably good estimate. Time-box the planning session - if it is too long you will start to get into too much detail. If too little you won't cover enough time. As team lead -step out of the room and let the team sort it out.
      >
      > Since we don't know what our velocity is yet it's hard to judge what we can do at this point based on story points. We estimated the stories by trying to use ideal days instead of story points because we are all having trouble getting our minds around story points.
      This type of confusion arises because you think of trying to estimate the story in a unit of time. You should think of it as a size estimate. How big is this story in relation to the rest. Choose one story that everybody agrees on the size and extrapolate and generate it from there. I would recommend Mike Cohn's book to help you work through this concept.

      > Should we really be concerned with trying to account for everyones total capacity during detailed planning of tasks? Is this going too far?
      This is what Alan was trying to say. There is no "me" in "team". Stories are given to the team to implement.

      > Another area we had some trouble with was tasks where two or more team members worked together. Should we define one task per person?
      No - definitely not, what you are trying to do is get the whole team involved to execute all the tasks. You have to break the cycle of I'm the UI or database guy. If the sprint only involves UI priorities - everybody is working on UI.

      > Here's a very specific question regarding this topic: Let's say we decide to plan a spike to look into something like, "Do we need a OS abstraction layer framework or not for our product and if so, how should it be designed?" We time box it for 2 hours but 4 members of the team are going to participate. That's 8 hours. Should I just specify a story that reflects 8 hours or create a design spike story and assign four tasks (one for each person) and reflect each will spend 2 hours?

      In my experience these research type problems were the only time where I would have a time / story point correlation. The warning sign was if everything you do is estimated like this. You are dealing with an unknown - if you knew the answer you would be able to estimate it. Make sure that you place boundaries and a fixed time box around it. Without it this could develop into a boundary less task.I would not try to break it down into hours and a per person correlation but rather as a size / "how big" estimate.

      Gert
    • markpetronic
      ... to estimate their time during sprint planning? ... this activity must be time boxed. You are looking for that magic point of just enough time to give you
      Message 2 of 19 , Oct 2, 2009
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Gert Wallis" <pragmatic.gert@...> wrote:
        >
        > Mark,
        >
        > you cover a lot of ground in this posting.
        >
        > > My basic question revolves around how accurately a team should try to estimate their time during sprint planning?
        > As accurately as the time allocated allow you to do. In other words - this activity must be time boxed. You are looking for that magic point of "just enough time" to give you a reasonably good estimate. Time-box the planning session - if it is too long you will start to get into too much detail. If too little you won't cover enough time. As team lead -step out of the room and let the team sort it out.

        Good idea on time boxing the meeting. I'm trying to be diligent to minimizing the meetings. Stepping out is a good idea...
        > >
        > > Since we don't know what our velocity is yet it's hard to judge what we can do at this point based on story points. We estimated the stories by trying to use ideal days instead of story points because we are all having trouble getting our minds around story points.
        > This type of confusion arises because you think of trying to estimate the story in a unit of time. You should think of it as a size estimate. How big is this story in relation to the rest. Choose one story that everybody agrees on the size and extrapolate and generate it from there. I would recommend Mike Cohn's book to help you work through this concept.

        I am reading "Agile Planning and Estimating". It's still hard to get the hang of this but, intuitively, my gut says this is the way to go... using size not time. It's especially hard being this is our first time and we don't have a reference point. No matter how hard we try, we keep finding the time still creeps in as the underlying measure - even when we tried to use size. Will keep plugging away at it. :)
        >
        > > Should we really be concerned with trying to account for everyones total capacity during detailed planning of tasks? Is this going too far?
        > This is what Alan was trying to say. There is no "me" in "team". Stories are given to the team to implement.

        Agree. We have been talking about shifting our thinking to "group think" and "group do".
        >
        > > Another area we had some trouble with was tasks where two or more team members worked together. Should we define one task per person?
        > No - definitely not, what you are trying to do is get the whole team involved to execute all the tasks. You have to break the cycle of I'm the UI or database guy. If the sprint only involves UI priorities - everybody is working on UI.

        Gotcha
        >
        > > Here's a very specific question regarding this topic: Let's say we decide to plan a spike to look into something like, "Do we need a OS abstraction layer framework or not for our product and if so, how should it be designed?" We time box it for 2 hours but 4 members of the team are going to participate. That's 8 hours. Should I just specify a story that reflects 8 hours or create a design spike story and assign four tasks (one for each person) and reflect each will spend 2 hours?
        >
        > In my experience these research type problems were the only time where I would have a time / story point correlation. The warning sign was if everything you do is estimated like this. You are dealing with an unknown - if you knew the answer you would be able to estimate it. Make sure that you place boundaries and a fixed time box around it. Without it this could develop into a boundary less task.I would not try to break it down into hours and a per person correlation but rather as a size / "how big" estimate.

        Ok, makes sense. Have the team solve the spike in maybe a real small story of say 1 point or less even with the understanding that there is some pre-agreed to time box on the whole thing and let the team figure out how to best manage their time and who should participate.

        Thanks for your comments, Gert!!!
        >
        > Gert
        >
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.