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

Re: [scrumdevelopment] Re: Daily Scrum and my bad memory

Expand Messages
  • Hans Brattberg
    ... How many hours someone has worked on an item i find uninteresting. The question is how many hours someone think there are left! We update our sprint chart
    Message 1 of 27 , Dec 27, 2007
    • 0 Attachment
      Tom Mellor wrote:
      > We don't track hours, but we do track To Do, In Progress, and Done.
      > Our Burn Down is based upon Done. Some people and firms do track hours
      > but we have no way of determining how many hours someone has worked on
      > a task (at least our time reporting tool does not provide for this
      > without becoming unduly cumbersome.

      How many hours someone has worked on an item i find uninteresting.
      The question is how many hours someone think there are left!
      We update our sprint chart before the daily scrum meeting, in hours, what we
      think is left on the tasks in progress. Sometimes that number is larger than the
      initial estimate, and thus gives as a warning signal in time.

      /Hans


      --
      Hans Brattberg
      hans.brattberg@...
      070-575 31 32
      www.crisp.se
    • Sarath Kummamuru
      Bring it up in the Retrospective :-) and let the team discuss it. Sarath.
      Message 2 of 27 , Dec 27, 2007
      • 0 Attachment
        Bring it up in the Retrospective :-) and let the team discuss it.

        Sarath.

        On Dec 26, 2007 3:05 PM, banshee858 <cnett858@...> wrote:

        >
        > 2. If more tasks than the number of members in the team are in the
        > INPROGRESS section at any time, it shows that the members are multi
        > tasking and this is a very strong anti pattern that needs to be
        > avoided.
        >
        How might you break the multitasking anti-pattern?

        Carlton


      • Sarath Kummamuru
        Hi Jane, I do agree that there is no point maintaining multiple tools. Normally what we do in our teams is that when the tasks are identified during the sprint
        Message 3 of 27 , Dec 27, 2007
        • 0 Attachment
          Hi Jane,
               I do agree that there is no point maintaining multiple tools. Normally what we do in our teams is that when the tasks are identified during the sprint planning, each task is estimated with number of hours. This is not by a specific person nor with a specific person in context. Just an estimate for a very small granularity task the team is comfortable with.

               Once this is done, we have the total number of task hours, (not actual hours) that need to be traversed and completed to complete all tasks of the sprint.

                Each daily scrum the team gets together and when any member moves a task into the DONE column, we just add that up to the burn down and we do this every day and plot the burn down on the same task board beside the tasks.

                Again having the burn down beside the tasks on the task board is a very strong information disseminator and highlights the current status very clearly without the SM or any one else having to go to each individual and capture daily status reports and all such other typical project management tasks.

                So with no extra time spent by any one, just during a quick 10 min daily scrum all status tracking (not by an individual) but by the whole team is completed. The whole team gets on the same page about where we stand with respect to the sprint goal. This allows for course corrections.

          Sarath.

          On Dec 26, 2007 5:51 PM, Jane Sherman <janes@...> wrote:

          Thanks Sarath (and to everyone else who provided feedback as well. )  

           

          I also found http://www.mountaingoatsoftware.com/task_boards .   Nice.

           

          How do you calculate burn down each day?  Or do you?   Does someone just total it up at the beginning/end of each day or maybe the daily scrum meeting?      I had been thinking we'd actually do a Schwaber Sprint Backlog – columns include Task Description, Responsible, and a column for each day of the Sprint containing hours remaining for the task – in Excel.       Does your task board replace this?  I can't imagine asking the developers to keep two tools up to date.

           

          Jane Sherman

           

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sarath Kummamuru
          Sent: Wednesday, December 26, 2007 10:01 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Daily Scrum and my bad memory

           

          Hi Jane,
              One of the very effective tools for ensuring we are on track and to avoid these kinds of problems is to use the task board. Normally as coaches we would suggest that the team do the daily scrum near the board.

              The way it works is that each team member picks up a task from the TODO column of the task board, Moves it to the INPROGRESS column and signs it with their initials. This ensures that the team member and every one else also know what is being picked up and what is being done by each team member.

              So next day when they come back to the daily scrum they would typically be telling the team that they finished with the task that they picked up and move it to the DONE column.

               In case they finished the task before the next daily scrum (say it was a 2 or 3 hour task) the team member would have gone back to the task board before the daily scrum (may be with a few other team members) moved the completed task to the DONE column and sign up for a new task.

               Some very important aspects that we can note from the TASK Board include:

          1. If people are picking up saying that they will do TASK X, but going ahead and working on TASK Y. This is very quickly evident and using the task board avoids this situation. The scrum master or any other team member participating  in the daily scurm could/would ask why TASK X was committed and TASK Y was done! (In fact the developer him/her self would be formed to mention that! ;-)  )

          2. If more tasks than the number of members in the team are in the INPROGRESS section at any time, it shows that the members are multi tasking and this is a very strong anti pattern that needs to be avoided.

          There are many more such advantages like this. I believe using the Task board will solve a lot of such scenarios.

          thanks,
          Sarath.
          PS: A very important thing that we want to learn with Scrum or Agile is that if there is some thing that is being done only by one person, we might be doing it wrong. So if you are having to keep track of status, we are doing it wrong. There are tools in Scrum or Agile for each of these scenarios and we should try some of them out.

          On Dec 26, 2007 11:10 AM, jane_sherman2001 <janes@...> wrote:

          We're gearing up to implement scrum at our company - I'm one of the
          big evangelists for it and I'll likely be the scrum master. I'm
          wondering how to realistically handle the daily scrum and comparing
          what people said they are going to do vs. what they actually got
          done. I know we'll likely see this in general in our burn down
          chart, but what prevents someone from coming to the meeting day after
          day, saying they're going to do task X, and then actually doing task Y
          (which could mean they did less total work)? They're honest people -
          the next day they say they did task Y, but they don't say "But I had
          thought I was going to do X". I've only partipated in a scrum in
          one other company and the team was so large, there was no way you
          could remember what each person committed to doing. I was the
          Product Owner, so I didn't feel it was my responsiblity to worry
          about it. At my new job, we'll have a much smaller team and as scrum
          master, it seems I need to pay attention to this. So that's where
          my bad memory comes into play - I have to write everything down -
          just so I can remember it. Would it be horrible if I marked down
          what part of the Sprint backlog folks said they were going to
          accomplish each day so I could monitor the general trend of folks
          doing what they said? The literature seems to say writing down
          impediments on the white board is ok but what do I do about "what I
          did" vs. "what I'm going to do"? I have a feeling the answer is
          that the team should be monitoring this as part of their self-
          management, but I know I'm going to struggle supporting this if I
          can't write it down.

          Jane Sherman

           


        • banshee858
          ... Interesting. I want to dig into this a little more since I am not convinced this quick answer is all you really wanted to say. What if people have ALWAYS
          Message 4 of 27 , Dec 27, 2007
          • 0 Attachment
            >
            > Bring it up in the Retrospective :-) and let the team discuss it.
            >
            Interesting. I want to dig into this a little more since I am not
            convinced this quick answer is all you really wanted to say. What if
            people have ALWAYS multitasked over their entire career and do not
            know any difference? What might I say to motivate someone to change
            their behavior?

            Carlton
          • Mike Dwyer
            Interesting thread as you have hit upon at least three gotcha s . Should the ScrumMaster keep notes (and distribute them??), What needs to be reported and
            Message 5 of 27 , Dec 27, 2007
            • 0 Attachment

              Interesting thread as you have hit upon at least three “gotcha’s”.  Should the ScrumMaster keep notes (and distribute them??),  What needs to be reported and by whom? And is all of this a part of a tool set.

               

              First, I have a lot of positive and negative associations with daily meeting notes.  On the plus side they are critical for teams that are distributed, particularly if you are more than 50 feet away.  On the negative side they tend to be viewed as part of the ‘me boss – you peon’ mindset.  But most of all they allow the team to fend off the most frequent interruption they get – the dreaded “How’s it going?” question followed quickly by, can ya fit this little tiny itsie bitsie mod in for me.  Post the notes so that the question askers can be easily steered to it and then to the ScrumMaster.  So all in all notes serve teams well.  Now the question is who should take them.

               

              First it should not be the ScrumMaster, they are the herder of cats, the sheepdog and the school teacher dragging the team to do its daily lesson.  Some times there is a team member that is a born note taker.  These people do exist but are hard to find as we all have demonized them since kindergarten as they have always had their notes, documentation, outlines, code structure, and probably closets better organized than the rest of us.  So make amends and ask for their help – it is a good political move too as they will probably be your boss someday.  Organized people do that.  If that doesn’t work then make it a rotating job.  If that doesn’t work then live without.

               

              Finally make the notes a living part of the information radiators in your life.

               

              Happy New Year

               

              Michael F. Dwyer

               

              "Planning constantly peers into the future for indications as to where a solution may emerge."

              "A Plan is a complex situation, adapting to an emerging solution." 

              -----Original Message-----
              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sarath Kummamuru
              Sent:
              Thursday, December 27, 2007 9:02 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Daily Scrum and my bad memory

               

              Hi Jane,
                   I do agree that there is no point maintaining multiple tools. Normally what we do in our teams is that when the tasks are identified during the sprint planning, each task is estimated with number of hours. This is not by a specific person nor with a specific person in context. Just an estimate for a very small granularity task the team is comfortable with.

                   Once this is done, we have the total number of task hours, (not actual hours) that need to be traversed and completed to complete all tasks of the sprint.

                    Each daily scrum the team gets together and when any member moves a task into the DONE column, we just add that up to the burn down and we do this every day and plot the burn down on the same task board beside the tasks.

                    Again having the burn down beside the tasks on the task board is a very strong information disseminator and highlights the current status very clearly without the SM or any one else having to go to each individual and capture daily status reports and all such other typical project management tasks.

                    So with no extra time spent by any one, just during a quick 10 min daily scrum all status tracking (not by an individual) but by the whole team is completed. The whole team gets on the same page about where we stand with respect to the sprint goal. This allows for course corrections.

              Sarath.

              On Dec 26, 2007 5:51 PM, Jane Sherman <janes@alibris. net> wrote:

              Thanks Sarath (and to everyone else who provided feedback as well. )  

               

              I also found http://www.mountain goatsoftware. com/task_ boards .   Nice.

               

              How do you calculate burn down each day?  Or do you?   Does someone just total it up at the beginning/end of each day or maybe the daily scrum meeting?      I had been thinking we'd actually do a Schwaber Sprint Backlog – columns include Task Description, Responsible, and a column for each day of the Sprint containing hours remaining for the task – in Excel.       Does your task board replace this?  I can't imagine asking the developers to keep two tools up to date.

               

              Jane Sherman

               

               

              From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Sarath Kummamuru
              Sent:
              Wednesday, December 26, 2007 10:01 AM
              To: scrumdevelopment@ yahoogroups. com
              Subject: Re: [scrumdevelopment] Daily Scrum and my bad memory

               

              Hi Jane,
                  One of the very effective tools for ensuring we are on track and to avoid these kinds of problems is to use the task board. Normally as coaches we would suggest that the team do the daily scrum near the board.

                  The way it works is that each team member picks up a task from the TODO column of the task board, Moves it to the INPROGRESS column and signs it with their initials. This ensures that the team member and every one else also know what is being picked up and what is being done by each team member.

                  So next day when they come back to the daily scrum they would typically be telling the team that they finished with the task that they picked up and move it to the DONE column.

                   In case they finished the task before the next daily scrum (say it was a 2 or 3 hour task) the team member would have gone back to the task board before the daily scrum (may be with a few other team members) moved the completed task to the DONE column and sign up for a new task.

                   Some very important aspects that we can note from the TASK Board include:

              1. If people are picking up saying that they will do TASK X, but going ahead and working on TASK Y. This is very quickly evident and using the task board avoids this situation. The scrum master or any other team member participating  in the daily scurm could/would ask why TASK X was committed and TASK Y was done! (In fact the developer him/her self would be formed to mention that! ;-)  )

              2. If more tasks than the number of members in the team are in the INPROGRESS section at any time, it shows that the members are multi tasking and this is a very strong anti pattern that needs to be avoided.

              There are many more such advantages like this. I believe using the Task board will solve a lot of such scenarios.

              thanks,
              Sarath.
              PS: A very important thing that we want to learn with Scrum or Agile is that if there is some thing that is being done only by one person, we might be doing it wrong. So if you are having to keep track of status, we are doing it wrong. There are tools in Scrum or Agile for each of these scenarios and we should try some of them out.

              On Dec 26, 2007 11:10 AM, jane_sherman2001 <janes@alibris. com> wrote:

              We're gearing up to implement scrum at our company - I'm one of the
              big evangelists for it and I'll likely be the scrum master. I'm
              wondering how to realistically handle the daily scrum and comparing
              what people said they are going to do vs. what they actually got
              done. I know we'll likely see this in general in our burn down
              chart, but what prevents someone from coming to the meeting day after
              day, saying they're going to do task X, and then actually doing task Y
              (which could mean they did less total work)? They're honest people -
              the next day they say they did task Y, but they don't say "But I had
              thought I was going to do X". I've only partipated in a scrum in
              one other company and the team was so large, there was no way you
              could remember what each person committed to doing. I was the
              Product Owner, so I didn't feel it was my responsiblity to worry
              about it. At my new job, we'll have a much smaller team and as scrum
              master, it seems I need to pay attention to this. So that's where
              my bad memory comes into play - I have to write everything down -
              just so I can remember it. Would it be horrible if I marked down
              what part of the Sprint backlog folks said they were going to
              accomplish each day so I could monitor the general trend of folks
              doing what they said? The literature seems to say writing down
              impediments on the white board is ok but what do I do about "what I
              did" vs. "what I'm going to do"? I have a feeling the answer is
              that the team should be monitoring this as part of their self-
              management, but I know I'm going to struggle supporting this if I
              can't write it down.

              Jane Sherman

               

               

            • Nicholas Cancelliere
              I have introduced the use of a kanban board to my team. They like it a lot more than their web-based tool. Each team member also gets 2 little stickers they
              Message 6 of 27 , Jan 2, 2008
              • 0 Attachment
                I have introduced the use of a kanban board to my team. They like it
                a lot more than their web-based tool. Each team member also gets 2
                little stickers they can put on cards they're working on. Why two,
                you might ask? Because studies have shown that taking on more than 2
                tasks at once degrades productivity, and doing only one task can be a
                problem if you're blocked on one, so they found two to be the magic
                number.

                Anyhow -- each team member talks about what they did the day before
                and what they plan to work on today, etc. As they do so they move
                their stickers around from one card to another card based on what's
                happening. This way when they meet up at the board the next morning
                they can easily recall which two stories they were working on and or
                be questioned why they were working on a story they hadn't planned on
                working on the day before.

                It has been working out really nicely.

                Nicholas


                On Dec 26, 2007, at 11:10 AM, jane_sherman2001 wrote:

                > We're gearing up to implement scrum at our company - I'm one of the
                > big evangelists for it and I'll likely be the scrum master. I'm
                > wondering how to realistically handle the daily scrum and comparing
                > what people said they are going to do vs. what they actually got
                > done. I know we'll likely see this in general in our burn down
                > chart, but what prevents someone from coming to the meeting day after
                > day, saying they're going to do task X, and then actually doing task Y
                > (which could mean they did less total work)? They're honest people -
                > the next day they say they did task Y, but they don't say "But I had
                > thought I was going to do X". I've only partipated in a scrum in
                > one other company and the team was so large, there was no way you
                > could remember what each person committed to doing. I was the
                > Product Owner, so I didn't feel it was my responsiblity to worry
                > about it. At my new job, we'll have a much smaller team and as scrum
                > master, it seems I need to pay attention to this. So that's where
                > my bad memory comes into play - I have to write everything down -
                > just so I can remember it. Would it be horrible if I marked down
                > what part of the Sprint backlog folks said they were going to
                > accomplish each day so I could monitor the general trend of folks
                > doing what they said? The literature seems to say writing down
                > impediments on the white board is ok but what do I do about "what I
                > did" vs. "what I'm going to do"? I have a feeling the answer is
                > that the team should be monitoring this as part of their self-
                > management, but I know I'm going to struggle supporting this if I
                > can't write it down.
                >
                > Jane Sherman
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                > Yahoo! Groups Links
                >
                >
                >

                --
                Nicholas Cancelliere, CSM/CSP
                Austin, TX

                Certified Scrum Practitioner
                Certified Scrum Master

                Over 10 years of web application development experience and an Agile
                nut!
              • alfaro.david
                Definitely, physical taskboard (or kanban board) produce more effective awareness on people. In my team we have acknowledged that the following phases are
                Message 7 of 27 , Jan 3, 2008
                • 0 Attachment
                  Definitely, physical taskboard (or kanban board) produce more
                  effective awareness on people.
                  In my team we have acknowledged that the following phases are needed
                  in order to set a done criteria for the User Stories we committed:
                  * Design: Meetings to discusses architectural issues,
                  * Development: Coding
                  * Application Quality Improvement: Pair Programming and/or Code
                  Review. We prefer Pair Programming.
                  * Testing: Quality Assurance in the way of Developer or
                  Integration Tests
                  * Usability Tests
                  Additionally, a sixth kind of tasks emerged: Environment, as a mean to
                  say that it is a task that encompasses all the environment setup
                  (technology setup) to accomplish the User Story.

                  Well, in one Retrospective long time ago we pointed out that some User
                  Stories were lacking of enough quality. Why? …. Got it! one or more
                  aforementioned phases were being skipped when planning and
                  implementing features. Why? We EASILY forget to get sure we get them
                  while planning and even implementing. At the second level of "Why?" we
                  realized we needed something catchy to remember those phases and to
                  avoid the constant tendency of realizing them when the deadline is
                  looming, or even worse: never!

                  We devised a solution: Use a specific color for each kind of task when
                  doing the Sprint Planning and do a Color Distribution Assessment
                  constantly: Do we have enough of all colors for all User Stories? If
                  not, is there a unanimous and intentional awareness of it?
                  I have just made a chart that explain it visually, look at
                  http://tinyurl.com/34hyqa

                  I appreciate your opinions.
                  --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                  <nickaustin74@...> wrote:
                  >
                  >
                  > I have introduced the use of a kanban board to my team. They like it
                  > a lot more than their web-based tool. Each team member also gets 2
                  > little stickers they can put on cards they're working on. Why two,
                  > you might ask? Because studies have shown that taking on more than 2
                  > tasks at once degrades productivity, and doing only one task can be a
                  > problem if you're blocked on one, so they found two to be the magic
                  > number.
                  >
                  > Anyhow -- each team member talks about what they did the day before
                  > and what they plan to work on today, etc. As they do so they move
                  > their stickers around from one card to another card based on what's
                  > happening. This way when they meet up at the board the next morning
                  > they can easily recall which two stories they were working on and or
                  > be questioned why they were working on a story they hadn't planned on
                  > working on the day before.
                  >
                  > It has been working out really nicely.
                  >
                  > Nicholas
                  >
                  >
                  > On Dec 26, 2007, at 11:10 AM, jane_sherman2001 wrote:
                  >
                  > > We're gearing up to implement scrum at our company - I'm one of the
                  > > big evangelists for it and I'll likely be the scrum master. I'm
                  > > wondering how to realistically handle the daily scrum and comparing
                  > > what people said they are going to do vs. what they actually got
                  > > done. I know we'll likely see this in general in our burn down
                  > > chart, but what prevents someone from coming to the meeting day after
                  > > day, saying they're going to do task X, and then actually doing task Y
                  > > (which could mean they did less total work)? They're honest people -
                  > > the next day they say they did task Y, but they don't say "But I had
                  > > thought I was going to do X". I've only partipated in a scrum in
                  > > one other company and the team was so large, there was no way you
                  > > could remember what each person committed to doing. I was the
                  > > Product Owner, so I didn't feel it was my responsiblity to worry
                  > > about it. At my new job, we'll have a much smaller team and as scrum
                  > > master, it seems I need to pay attention to this. So that's where
                  > > my bad memory comes into play - I have to write everything down -
                  > > just so I can remember it. Would it be horrible if I marked down
                  > > what part of the Sprint backlog folks said they were going to
                  > > accomplish each day so I could monitor the general trend of folks
                  > > doing what they said? The literature seems to say writing down
                  > > impediments on the white board is ok but what do I do about "what I
                  > > did" vs. "what I'm going to do"? I have a feeling the answer is
                  > > that the team should be monitoring this as part of their self-
                  > > management, but I know I'm going to struggle supporting this if I
                  > > can't write it down.
                  > >
                  > > Jane Sherman
                  > >
                  > >
                  > >
                  > > To Post a message, send it to: scrumdevelopment@...
                  > > To Unsubscribe, send a blank message to:
                  scrumdevelopment-unsubscribe@...
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  >
                  > --
                  > Nicholas Cancelliere, CSM/CSP
                  > Austin, TX
                  >
                  > Certified Scrum Practitioner
                  > Certified Scrum Master
                  >
                  > Over 10 years of web application development experience and an Agile
                  > nut!
                  >
                • Nicholas Cancelliere
                  Can you post a url that isn t on facebook or require a facebook account? ... -- Nicholas Cancelliere, CSM/CSP Austin, TX Certified Scrum Practitioner Certified
                  Message 8 of 27 , Jan 8, 2008
                  • 0 Attachment
                    Can you post a url that isn't on facebook or require a facebook account?


                    On Jan 3, 2008, at 4:28 PM, alfaro.david wrote:
                    >
                    > http://tinyurl.com/34hyqa
                    >
                    > I appreciate your opinions.
                    >

                    --
                    Nicholas Cancelliere, CSM/CSP
                    Austin, TX

                    Certified Scrum Practitioner
                    Certified Scrum Master

                    Over 10 years of web application development experience and an Agile
                    nut!
                  • Jeff Martin
                    Peter, Your idea of just tracking the number of tasks sounds interesting. One of the issues our team always runs into is that some of our estimates are just
                    Message 9 of 27 , Jan 8, 2008
                    • 0 Attachment

                      Peter,

                       

                      Your idea of just tracking the number of tasks sounds interesting.  One of the issues our team always runs into is that some of our estimates are just plain wrong and it’s a pain to estimate everything all at once and re-estimate when you find out you’re wrong.  The question I have is: how do you deal with vastly different sized tasks?  We limit our tasks now to no more than a day’s work, but for every 8 hour task, we might have five 2-3 hour tasks.  How do you maintain confidence that you are on track to complete everything?  Having six 2-hour tasks remaining is a lot different than six 8-hour tasks. 

                       

                      It might make sense to roll up tasks until they make about a day’s work, just like we break large tasks down to a day.  I’ve also considered estimating in quarter-days and forgetting hours altogether. 

                       

                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Peter Hundermark
                      Sent: Thursday, December 27, 2007 6:26 AM
                      To: scrumdevelopment@yahoogroups.com
                      Subject: [scrumdevelopment] Re: Daily Scrum and my bad memory

                       


                      IMO Tom is on the right track here. Here is what I have done for more than a year with many teams and seems to work well for them:

                      • Estimate stories using relative size in story points (follow Mike Cohn's method).
                      • Create granular tasks such that each is no bigger that about 1 day's work.
                      • Flag any task remaining <In Progress> or more than a day (we just use a red marker pen). It is either impeded or too big and should be split. At least it will not escape the team's attention.
                      • Track progress in the sprint burndown simply as tasks done vs. working days. (Strictly speaking we count tasks not done (i.e. To Do + In Progress), since this represents what we must still get done in the remaining days.)

                      Why?
                      1. No vestigial dysfunctional controls like time tracking.
                      2. No wasteful practices like continual re-estimation of remaining work on tasks.
                      3. In my experience the task-based burndown is at least as accurate as remaining hours estimates when averaged over a whole sprint.

                      Regards,

                      Peter

                      --
                      Peter Hundermark
                      Certified Scrum Coach
                      SPRiNT-iT Africa
                      mobile: +27 84 261 3860
                      skype: peterhundermark
                      www.sprint-it.com

                    • jay_conne
                      Hi Peter & Jeff, Re: just tacking the number of tasks... On one project - an Agile Transformation Core team, not doing sw dev., we did just that and it was
                      Message 10 of 27 , Jan 9, 2008
                      • 0 Attachment
                        Hi Peter & Jeff,

                        Re: just tacking the number of tasks...
                        On one project - an Agile Transformation Core team, not doing sw dev.,
                        we did just that and it was what the team wanted. Due to the
                        management c&c behavior, it was as good as we could get. On the other
                        hand, with the normal state of task's time-to-complete being
                        discovered as we work, I think we are better off following the Scrum
                        standard model of crossing out obsolete estimates and replacing them
                        with current best-guesses. This provides exactly what is needed for
                        burndown charting. Which in turn, serves one purpose - informing the
                        team of their ability to meet their commitment this iteration. And
                        that informs other critical decisions for maintaining trust with the
                        sponsor. It's really quite simple.

                        Re: size of tasks...
                        I have found that the team is well served by breaking stories down
                        into the units of work that they can best understand, estimate and
                        clearly demonstrate are done. We expose 'stuck' tasks with a brightly
                        colored sticker which typically corresponds to an impediment. I
                        wouldn't want to force a task to be a certain size, but rather let the
                        team decide what serves. Often, an activity is required for each of a
                        list of items. To create a task for each may or may not be useful.
                        If they are likely to be done quickly and nearly at the same time, one
                        task should serve. If one or more list item is a problem, that can be
                        made visible as a flag on the task. (In other contexts, each list
                        item is better tracked as its own story and task list.)

                        It all depends... but keep it simple.

                        Jay Conne
                        Lean/Agile Coach, Trainer and
                        ScrumMaster-Practicing.
                        www.jconne.com jay@...
                        617-776-0339 M:617-470-5038



                        --- In scrumdevelopment@yahoogroups.com, "Jeff Martin" <jmartin@...>
                        wrote:
                        >
                        > Peter,
                        >
                        > Your idea of just tracking the number of tasks sounds interesting.
                        One of the issues our team always runs into is that some of our
                        estimates are just plain wrong and it’s a pain to estimate
                        everything all at once and re-estimate when you find out you’re
                        wrong. The question I have is: how do you deal with vastly different
                        sized tasks? We limit our tasks now to no more than a day’s work,
                        but for every 8 hour task, we might have five 2-3 hour tasks. How do
                        you maintain confidence that you are on track to complete everything?
                        Having six 2-hour tasks remaining is a lot different than six 8-hour
                        tasks.
                        >
                        > It might make sense to roll up tasks until they make about a day’s
                        work, just like we break large tasks down to a day. I’ve also
                        considered estimating in quarter-days and forgetting hours altogether.
                        >
                        >
                        > From: scrumdevelopment@yahoogroups.com
                        [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Peter Hundermark
                        > Sent: Thursday, December 27, 2007 6:26 AM
                        > To: scrumdevelopment@yahoogroups.com
                        > Subject: [scrumdevelopment] Re: Daily Scrum and my bad memory
                        >
                        > IMO Tom is on the right track here. Here is what I have done for
                        more than a year with many teams and seems to work well for them:
                        >
                        > * Estimate stories using relative size in story points (follow Mike
                        Cohn's method).
                        > * Create granular tasks such that each is no bigger that about 1
                        day's work.
                        > * Flag any task remaining <In Progress> or more than a day (we just
                        use a red marker pen). It is either impeded or too big and should be
                        split. At least it will not escape the team's attention.
                        > * Track progress in the sprint burndown simply as tasks done vs.
                        working days. (Strictly speaking we count tasks not done (i.e. To Do +
                        In Progress), since this represents what we must still get done in the
                        remaining days.)
                        >
                        > Why?
                        > 1. No vestigial dysfunctional controls like time tracking.
                        > 2. No wasteful practices like continual re-estimation of remaining
                        work on tasks.
                        > 3. In my experience the task-based burndown is at least as accurate
                        as remaining hours estimates when averaged over a whole sprint.
                        >
                        > Regards,
                        >
                        > Peter
                        >
                        > --
                        > Peter Hundermark
                        > Certified Scrum Coach
                        > SPRiNT-iT Africa
                        > mobile: +27 84 261 3860
                        > skype: peterhundermark
                        > www.sprint-it.com
                      • Peter Hundermark
                        ... One of the issues our team always runs into is that some of our estimates are just plain wrong and it’s a pain to estimate everything all at once and
                        Message 11 of 27 , Jan 15, 2008
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, "Jeff Martin" <jmartin@...>
                          wrote:
                          >
                          > Peter,
                          >
                          >
                          >
                          > Your idea of just tracking the number of tasks sounds interesting.
                          One of the issues our team always runs into is that some of our
                          estimates are just plain wrong and it’s a pain to estimate everything
                          all at once and re-estimate when you find out you’re wrong. The
                          question I have is: how do you deal with vastly different sized tasks?
                          We limit our tasks now to no more than a day’s work, but for every 8
                          hour task, we might have five 2-3 hour tasks. How do you maintain
                          confidence that you are on track to complete everything? Having six
                          2-hour tasks remaining is a lot different than six 8-hour tasks.
                          >

                          My approach is predicated on a sufficiently large number of tasks that
                          the variance in size cis accommodated in the average. We always have
                          more than 30 tasks, even with a small team (3 devs) and a short sprint
                          (2 weeks). But I'm no statistician and so I'm open to a challenge...

                          I just try to eliminate waste...including unnecessary process...where
                          possible.

                          Peter
                        • Simon Kirk
                          ... Hi Peter. How do you find that working out for inexperienced teams? By inexperienced I mean (say) a team which has never even written a line of OO code
                          Message 12 of 27 , Jan 16, 2008
                          • 0 Attachment
                            On 15 Jan 2008, at 20:13, Peter Hundermark wrote:

                            > --- In scrumdevelopment@yahoogroups.com, "Jeff Martin" <jmartin@...>
                            > wrote:
                            > >
                            > > Peter,
                            > >
                            > >
                            > >
                            > > Your idea of just tracking the number of tasks sounds interesting.
                            > One of the issues our team always runs into is that some of our
                            > estimates are just plain wrong and it’s a pain to estimate
                            > everything
                            > all at once and re-estimate when you find out you’re wrong. The
                            > question I have is: how do you deal with vastly different sized tasks?
                            > We limit our tasks now to no more than a day’s work, but for every 8
                            > hour task, we might have five 2-3 hour tasks. How do you maintain
                            > confidence that you are on track to complete everything? Having six
                            > 2-hour tasks remaining is a lot different than six 8-hour tasks.
                            > >
                            >
                            > My approach is predicated on a sufficiently large number of tasks that
                            > the variance in size cis accommodated in the average. We always have
                            > more than 30 tasks, even with a small team (3 devs) and a short sprint
                            > (2 weeks). But I'm no statistician and so I'm open to a challenge...
                            >
                            > I just try to eliminate waste...including unnecessary process...where
                            > possible.
                            >
                            > Peter
                            >
                            Hi Peter.

                            How do you find that working out for inexperienced teams? By
                            inexperienced I mean (say) a team which has never even written a line
                            of OO code before and works in (say) VB6. They're still very
                            experienced and skilled (maybe that's bad; they may have ingrained
                            habits).

                            Without the "hours remaining" show on tasks I'd worry that problems of
                            underestimation (and therefore a reduction in velocity) might not be
                            apparent on the burndown, meaning it would require an experienced team
                            who know how to feed information about the velocity reduction
                            effectively.

                            Cheers,
                            Simon
                          • Nicholas Cancelliere
                            How are you measuring velocity Simon? It sounds like you re daily computing it, rather than at the end of the sprint? After a few sprints any team should be
                            Message 13 of 27 , Jan 16, 2008
                            • 0 Attachment

                              How are you measuring velocity Simon?  It sounds like you're daily computing it, rather than at the end of the sprint?  After a few sprints any team should be able to establish a velocity, that is how many stories per sprint they're able to complete.  Velocity isn't a measure of how fast tasks are getting done day to day.

                              Nicholas


                              On Jan 16, 2008, at 11:31 AM, Simon Kirk wrote:

                              Hi Peter.

                              How do you find that working out for inexperienced teams? By  
                              inexperienced I mean (say) a team which has never even written a line  
                              of OO code before and works in (say) VB6. They're still very  
                              experienced and skilled (maybe that's bad; they may have ingrained  
                              habits).

                              Without the "hours remaining" show on tasks I'd worry that problems of  
                              underestimation (and therefore a reduction in velocity) might not be  
                              apparent on the burndown, meaning it would require an experienced team  
                              who know how to feed information about the velocity reduction  
                              effectively.

                              Cheers,
                              Simon

                              --
                              Nicholas Cancelliere
                              Austin, TX




                            • Peter Hundermark
                              ... Hi Simon, In my experience inexperienced teams don t do estimating well. They are usually over-optimistic and cannot deliver what they commit to in early
                              Message 14 of 27 , Jan 16, 2008
                              • 0 Attachment
                                --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
                                > Hi Peter.
                                >
                                > How do you find that working out for inexperienced teams? By
                                > inexperienced I mean (say) a team which has never even written a line
                                > of OO code before and works in (say) VB6. They're still very
                                > experienced and skilled (maybe that's bad; they may have ingrained
                                > habits).
                                >
                                > Without the "hours remaining" show on tasks I'd worry that problems of
                                > underestimation (and therefore a reduction in velocity) might not be
                                > apparent on the burndown, meaning it would require an experienced team
                                > who know how to feed information about the velocity reduction
                                > effectively.
                                >
                                > Cheers,
                                > Simon
                                >

                                Hi Simon,

                                In my experience inexperienced teams don't do estimating well. They are
                                usually over-optimistic and cannot deliver what they "commit" to in
                                early sprints. However this happens at the User Story (feature) level
                                and they learn after a couple of sprints to correct this (assuming they
                                are blessed a well-behaved PO and a competent SM to guide them).

                                In such a team I would have even less trust in an individual team
                                member's (or portion of the team's) ability to reliably estimate hours
                                remaining for an individual task. A task can remain in-progress
                                indefinitely and not automatically attract special attention. The sprint
                                burndown may flatten out, but the cause may not be immediately obvious.

                                Therefore I would suggest my practice of having the team flag tasks
                                in-progress for more than a day is even more helpful in such a team. The
                                whole team at the daily meeting must confront whether the task is
                                impeded or needs to be split. In either case the way forward is clear.

                                Lastly, the focus of the sprint is always to deliver done stories
                                (features). Too much attention on tasks (including estimation thereof)
                                can distract attention from the focus.

                                Regards,

                                Peter
                                CSC
                              • Simon Kirk
                                Hi again Peter; both of us beavering away on the Scrum list relatively late at night :) Comments within: ... I can see how that would normally be the case.
                                Message 15 of 27 , Jan 16, 2008
                                • 0 Attachment
                                  Hi again Peter; both of us beavering away on the Scrum list relatively
                                  late at night :)

                                  Comments within:

                                  On 16 Jan 2008, at 22:02, Peter Hundermark wrote:
                                  > In my experience inexperienced teams don't do estimating well. They
                                  > are
                                  > usually over-optimistic and cannot deliver what they "commit" to in
                                  > early sprints. However this happens at the User Story (feature) level
                                  > and they learn after a couple of sprints to correct this (assuming
                                  > they
                                  > are blessed a well-behaved PO and a competent SM to guide them).
                                  >
                                  I can see how that would normally be the case. Interestingly the
                                  grizzled heads on this team actually tend to be quite circumspect :)
                                  They are actually quite a few sprints in now, and their estimation is
                                  reasonably good. It's the communication bit that worries me, which
                                  leads me onto another of your comments.
                                  >
                                  > In such a team I would have even less trust in an individual team
                                  > member's (or portion of the team's) ability to reliably estimate hours
                                  > remaining for an individual task. A task can remain in-progress
                                  > indefinitely and not automatically attract special attention. The
                                  > sprint
                                  > burndown may flatten out, but the cause may not be immediately
                                  > obvious.
                                  >
                                  > Therefore I would suggest my practice of having the team flag tasks
                                  > in-progress for more than a day is even more helpful in such a team.
                                  > The
                                  > whole team at the daily meeting must confront whether the task is
                                  > impeded or needs to be split. In either case the way forward is clear.
                                  >
                                  Ah, I seem to remember talking to you about this at the Scrum
                                  gathering now. I'm glad my instinct that it becomes dependant on the
                                  communication of the team was on the right track. However, see my last
                                  comment.
                                  >
                                  > Lastly, the focus of the sprint is always to deliver done stories
                                  > (features). Too much attention on tasks (including estimation thereof)
                                  > can distract attention from the focus.
                                  >
                                  >
                                  I couldn't agree more, and I try to make it as clear as possible that
                                  the stories are the key. However, the behaviour that worries me is the
                                  team "proactivity", for want of a better word. Whether it be via
                                  horizontal burn-down where the tasks are either complete or not, or
                                  even a climbing one where the hours remaining are going up, both
                                  scenarios are ideally flagged and brought forward by the team.

                                  Many times now this hasn't happened (it's not that there's not
                                  acknowledgement of a problem, it's more there's no specific attack by
                                  the team on the problem to find out what's holding them up), and I'm
                                  beginning to wonder if I'm missing some kind of technique. I can't
                                  seem to get the team to take control of their own destiny here; I try
                                  my best to step back and not prompt them, I don't want to get into
                                  command and control. How then can I get the team to identify these
                                  impediments and report them both to each other and if necessary to me
                                  without having to push them to do it?

                                  Certainly your "task in progress for more than one day" rule is simple
                                  and easy to apply for the team, I just wondered if there were some
                                  other tricks up your or anybody else's sleeve.

                                  Cheers,
                                  Simon
                                • Simon Kirk
                                  Hi Nicholas No, we don t compute every day, that way madness lies :) I was implying that a number of underestimated stories (implying *initially*
                                  Message 16 of 27 , Jan 16, 2008
                                  • 0 Attachment
                                    Hi Nicholas

                                    No, we don't compute every day, that way madness lies :) I was implying that a number of underestimated stories (implying *initially* underestimated tasks) will adversely effect perceived velocity - that being the team's perspective of velocity, and thus have a bad effect on morale and/or enthusiasm for agile amount the more traditional developers on the team :) It's that old overloaded term "velocity", I apologise for using it a bit out of context, as yes it's normally the number of story points completed per sprint.

                                    I'm 100% fine with "hours left until complete" estimates going up for tasks, I think it's a useful measurement for the team to be able to know when they've underestimated the difficultly of a story, which is why I asked Peter what I did, as I can't see how if one doesn't adjust hours remaining one can see when the time to completion is growing; the best you can do is see it remains "horizontal" on the burn down (meaning tasks didn't get completed).

                                    Cheers,
                                    Simon

                                    On 16 Jan 2008, at 21:27, Nicholas Cancelliere wrote:


                                    How are you measuring velocity Simon?  It sounds like you're daily computing it, rather than at the end of the sprint?  After a few sprints any team should be able to establish a velocity, that is how many stories per sprint they're able to complete.  Velocity isn't a measure of how fast tasks are getting done day to day.

                                    Nicholas


                                    On Jan 16, 2008, at 11:31 AM, Simon Kirk wrote:

                                    Hi Peter.

                                    How do you find that working out for inexperienced teams? By  
                                    inexperienced I mean (say) a team which has never even written a line  
                                    of OO code before and works in (say) VB6. They're still very  
                                    experienced and skilled (maybe that's bad; they may have ingrained  
                                    habits).

                                    Without the "hours remaining" show on tasks I'd worry that problems of  
                                    underestimation (and therefore a reduction in velocity) might not be  
                                    apparent on the burndown, meaning it would require an experienced team  
                                    who know how to feed information about the velocity reduction  
                                    effectively.

                                    Cheers,
                                    Simon

                                    --
                                    Nicholas Cancelliere
                                    Austin, TX






                                  Your message has been successfully submitted and would be delivered to recipients shortly.