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

Sprint Review vs Serial Report

Expand Messages
  • Thierry Thelliez
    I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends
    Message 1 of 12 , Feb 28, 2006
    • 0 Attachment

      I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a ‘Serial Report’ meeting where some individuals seem to be loosing their time.

       

      We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.

       

      It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.

       

      Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?

       

       

      Thierry Thelliez

       

       

    • Jeff Heinen
      We typically only have one or two team members actively participating in the review, and the rest of the team is there largely to answer questions that the
      Message 2 of 12 , Feb 28, 2006
      • 0 Attachment
        We typically only have one or two team members actively participating in the review, and the rest of the team is there largely to answer questions that the product owner might have. We don't see this as a problem. It tends to go more smoothly when the Team designates someone to "drive" the review.
         
        I would ask how long are your reviews typically? We tend to keep ours to an hour or less, and I haven't heard a complaint that anyone fells like time is being wasted. In fact, since the next sprint has not been planned yet when we conduct the review, they don't actually have anything else to work on :)
         
        As for tasks, how do people end up doing a particular task? Do people sign up for all of them at the beginning of a sprint or do they do it as the work is about to be done?  The way we've handled this is by a) having people sign up for work when it's time to do it - that tends to keep people flexible about what they potentially will work on, and b) emphasizing that the goals of the sprint are what's important and that the entire team is responsible, not "Joe is responsible for these tasks, and Jane is responsible for those tasks."
         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Thierry Thelliez
        Sent: Tuesday, February 28, 2006 3:33 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Sprint Review vs Serial Report

        I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a ‘Serial Report’ meeting where some individuals seem to be loosing their time.

         

        We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.

         

        It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.

         

        Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?

         

         

        Thierry Thelliez

         

         

      • mpkirby@frontiernet.net
        ... Our review format is pretty straight forward. Agenda: 10 minutes -- Review improvements made since the last retrospective. This is the We listened part
        Message 3 of 12 , Feb 28, 2006
        • 0 Attachment
          On 28 Feb 2006 at 16:33, Thierry Thelliez wrote:

          >
          > I am looking for ideas to improve our Sprint reviews. The main issue I
          > see is that not all the team members are engaged in the review. The
          > Sprint Review ends up being like a `Serial Report´ meeting where
          > some individuals seem to be loosing their time.

          Our review format is pretty straight forward.

          Agenda:

          10 minutes -- Review improvements made since the last retrospective. This is the "We
          listened" part of the meeting. If there isn't at least one thing there, then what was the point of
          the last retrospective (or you are executing perfectly -- This hasn't happened yet).


          30 minutes -- I go around the room asking each person for a constructive observation about
          the previous iteration. It's key to get everyone to provide input. If they can't think of
          something constructive to say, then say something positive (something that went well, that
          you'd like to see us continue doing). During this period, I allow some discussion. It's not a
          traditional brainstorming format.

          15 minutes - I go through the list of items, and I ask folks to silently "vote" for those things
          that they feel "impacted" them the most. I put in place the "silent" rule because I found a few
          louder individuals were "talking up" points in prior retrospectives.

          I make a quick "High / Medium / Low / none" estimation based on the number of hands. I
          circle the Highs, and we talk a bit about what we might do in the upcoming iteration to
          alleviate some of the concerns.

          We've made a number of changes to our process, and this seems to work well for what I
          would generally feel is one of the most intraverted teams I've ever seen. Even the strong
          silent types, still manage to provide meaningful input.

          > We have many tasks and many different skill sets. It seems that some
          > team members are so much focused into their own tasks that they pay
          > little attention to the other tasks. There is also a (perceived)
          > technical gap that seems to create boundaries. For example a backend
          > developer does not seem to pay much attention to the UI work.

          We've got t his as well. I'm trying to use Scrum to break down those barriers. A team
          doesn't really come together until people realize that their teammates will pull them out of the
          weeds if they get in trouble. If people's perspective is that their deliverable is "just my piece",
          then any work by the others is not valued. But if the deliverable is "end-to-end" suddenly they
          all need to come together to deliver the product.

          Mike

          ---
          mpkirby@...
        • Steven Gordon
          One way to get the shyer people more involved is to rotate the few people who will present the team s work each sprint. Steven Gordon
          Message 4 of 12 , Feb 28, 2006
          • 0 Attachment
            One way to get the shyer people more involved is to rotate the few people who will present the team's work each sprint.
             
            Steven Gordon

             
            On 2/28/06, Thierry Thelliez <thierry@...> wrote:

            I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a 'Serial Report' meeting where some individuals seem to be loosing their time.

             

            We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.

             

            It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.

             

            Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?

             

             

            Thierry Thelliez

             
             

             
          • Alex Pukinskis
            Are you doing demos of working software in your Review? Don¹t UI and backend people have to come together to make these demos actually work? I frequently see
            Message 5 of 12 , Feb 28, 2006
            • 0 Attachment
              Re: [scrumdevelopment] Sprint Review vs Serial Report Are you doing demos of working software in your Review?  Don’t UI and backend people have to come together to make these demos actually work?

              I frequently see teams spending 30 minutes to 1 hour on Sprint demos, 5 to 20 minutes on Sprint Review (usually the ScrumMaster just listing stats – work done vs. committed, defects, test coverage, build success, etc) and 30 minutes to 4 hours on the retrospective.  Is your meeting wildly different than these ranges?  Which part of the meeting are you struggling with?

              -Alex

              On 02 28 2006 4:33 PM, "Thierry Thelliez" <thierry@...> wrote:

              I am looking for ideas to improve our Sprint reviews. The main issue I see is that not all the team members are engaged in the review. The Sprint Review ends up being like a ‘Serial Report’ meeting where some individuals seem to be loosing their time.
               
              We have many tasks and many different skill sets. It seems that some team members are so much focused into their own tasks that they pay little attention to the other tasks. There is also a (perceived) technical gap that seems to create boundaries. For example a backend developer does not seem to pay much attention to the UI work.
               
              It does not seem to be so much an issue during the daily meetings since the meetings are short, although I see some of this attitude.
               
              Should the team members be coached in listening more to the others? Should the tasks be designed to push more for larger participation?
               
               
              Thierry Thelliez
               
               


              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


                

               
               
              SPONSORED LINKS
                        
                
              Scrum <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>         
               
               

              YAHOO! GROUPS LINKS


               




              --
              Alex Pukinskis - Agile Coach
              Rally Software Development
              http://rallydev.com/
                  
            • kittys shu
              My current research is to conduct an empirical study on the effect of Scrum. After several months effort, the PM I work with finally agreed to try scrum in
              Message 6 of 12 , Feb 28, 2006
              • 0 Attachment
                My current research is to conduct an empirical study on the effect of Scrum.
                 
                After several months' effort, the PM I work with finally agreed to try scrum in his project.
                 
                Since everything just started, there are some questions and issues appearing.
                 
                One of his questions is why do we do sub tasking, why don't we just end with selecting user stories for current iteration? I gave him two points as the answer: 1. sub tasking and time estimation force developers to think thoroughly what they are going to do with the user stories. So, they may find out that some stories that are originally thought feasible become not feasible so that they cannot go into the current iteration. This is good for iteration planning and results.
                 
                2. when we move the tasks to the "completed" list, healthy peer pressure can be achieved.
                 
                However, he thought these two points are more likely for management purpose.
                 
                How can we persuade developers to do this? Or, in other words, what are the big and obvious benefits for them to show their private working steps?
                 
                 


                Find your next car at Yahoo! Canada Autos
              • Ron Jeffries
                ... I like to see the team brainstorm the technical tasks that are to be done, but to see user stories signed up for, not tasks. (By the way user story is,
                Message 7 of 12 , Mar 1, 2006
                • 0 Attachment
                  On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:

                  > How can we persuade developers to do this? Or, in other words, what are the big and obvious
                  > benefits for them to show their private working steps?

                  I like to see the team brainstorm the technical tasks that are to be
                  done, but to see user stories signed up for, not tasks. (By the way
                  "user story" is, as far as I know, an XP term, not a Scrum term.)

                  Brainstorming the technical tasks is an explicit albeit small design
                  step and therefore it benefits the team by keeping everyone aware of
                  the intended design of each story, and allowing everyone to
                  contribute.

                  Signing up for stories rather than tasks keeps the team focused on
                  story completion, not task completion. Thus, I prefer it.

                  Ron Jeffries
                  www.XProgramming.com
                  It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
                • Deb
                  Hello Kitty1 (guess you hear that a lot? :-) Your reasons are sensible, and I d add one more: with more granular units of work the burndown can be easier to
                  Message 8 of 12 , Mar 1, 2006
                  • 0 Attachment
                    Hello Kitty1 (guess you hear that a lot? :-)

                    Your reasons are sensible, and I'd add one more: with more granular
                    units of work the burndown can be easier to update. Sometimes a big
                    item with lots of uncertainty burns down like 10-10-7-7-0, you have
                    flatlining and sudden drops. Burndown is easier to update and guage,
                    in my opinion, when stories or task are <= 10% of sprint length. The
                    burndown is very much a developer tool, not just for the SM. The
                    developers are on the hook to deliver, not the SM.

                    > these two points are more likely for management purpose

                    Yes, and amazingly, Agile management can have benefits for developers,
                    too! :-D

                    > How can we persuade developers to do this?

                    I'd say, wait till there is a problem, and if they don't suggest it
                    themselves, you might ask them what they think. Best way to get more
                    agile, in my book, is to apply the practice "where it hurts". I
                    believe that some XP teams do estimate at the story level, and that's
                    fine.

                    Where might this practice (small estimation units) help? Using the
                    burndown but still not making the target may be one. Idle people may
                    be another (smaller units can be more easily shared). Bottlenecks
                    could be a third. Anyone else have ideas on this?

                    I find that more granularity at the beginning can help the team learn
                    to estimate, once they have learned this the best granularity is
                    whatever works for them. Still, <=10% reduces risk, when unknowns crop
                    up, which they will.

                    best of luck
                    deb


                    --- In scrumdevelopment@yahoogroups.com, kittys shu
                    <kittyscalgary@...> wrote:
                    >
                    > My current research is to conduct an empirical study on the effect
                    of Scrum.
                    >
                    > After several months' effort, the PM I work with finally agreed to
                    try scrum in his project.
                    >
                    > Since everything just started, there are some questions and issues
                    appearing.
                    >
                    > One of his questions is why do we do sub tasking, why don't we
                    just end with selecting user stories for current iteration? I gave him
                    two points as the answer: 1. sub tasking and time estimation force
                    developers to think thoroughly what they are going to do with the user
                    stories. So, they may find out that some stories that are originally
                    thought feasible become not feasible so that they cannot go into the
                    current iteration. This is good for iteration planning and results.
                    >
                    > 2. when we move the tasks to the "completed" list, healthy peer
                    pressure can be achieved.
                    >
                    > However, he thought these two points are more likely for
                    management purpose.
                    >
                    > How can we persuade developers to do this? Or, in other words,
                    what are the big and obvious benefits for them to show their private
                    working steps?
                    >
                    >
                    >
                    >
                    > ---------------------------------
                    > Find your next car at Yahoo! Canada Autos
                    >
                  • Deb
                    Yes, ideally the tasks could be noted on the story card, at the beginning when they are learning their environment etc. and you could estimate at story level.
                    Message 9 of 12 , Mar 1, 2006
                    • 0 Attachment
                      Yes, ideally the tasks could be noted on the story card, at the
                      beginning when they are learning their environment etc. and you could
                      estimate at story level.

                      But in teams with (gasp!) specialization, units smaller than stories
                      may be needed. When 'experts' show up in this way in the process, use
                      it as a chance to cross train! Then you won't need a separate task in
                      future.

                      deb

                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                      <ronjeffries@...> wrote:
                      >
                      > On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:
                      >
                      > > How can we persuade developers to do this? Or, in other words,
                      what are the big and obvious
                      > > benefits for them to show their private working steps?
                      >
                      > I like to see the team brainstorm the technical tasks that are to be
                      > done, but to see user stories signed up for, not tasks. (By the way
                      > "user story" is, as far as I know, an XP term, not a Scrum term.)
                      >
                      > Brainstorming the technical tasks is an explicit albeit small design
                      > step and therefore it benefits the team by keeping everyone aware of
                      > the intended design of each story, and allowing everyone to
                      > contribute.
                      >
                      > Signing up for stories rather than tasks keeps the team focused on
                      > story completion, not task completion. Thus, I prefer it.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > It is a bad plan that admits of no modifications. -- Publius Syrus
                      (ca. 42 BCE)
                      >
                    • Jeff Heinen
                      What if a story requires effort from more than just one person?
                      Message 10 of 12 , Mar 1, 2006
                      • 0 Attachment
                        What if a story requires effort from more than just one person?

                        > -----Original Message-----
                        > From: scrumdevelopment@yahoogroups.com
                        > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                        > Sent: Wednesday, March 01, 2006 1:44 AM
                        > To: scrumdevelopment@yahoogroups.com
                        > Subject: Re: [scrumdevelopment] what benefits can sub tasking
                        > bring to developers?
                        >
                        > On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:
                        >
                        > > How can we persuade developers to do this? Or, in other
                        > words, what
                        > > are the big and obvious benefits for them to show their
                        > private working steps?
                        >
                        > I like to see the team brainstorm the technical tasks that
                        > are to be done, but to see user stories signed up for, not
                        > tasks. (By the way "user story" is, as far as I know, an XP
                        > term, not a Scrum term.)
                        >
                        > Brainstorming the technical tasks is an explicit albeit small
                        > design step and therefore it benefits the team by keeping
                        > everyone aware of the intended design of each story, and
                        > allowing everyone to contribute.
                        >
                        > Signing up for stories rather than tasks keeps the team
                        > focused on story completion, not task completion. Thus, I prefer it.
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > It is a bad plan that admits of no modifications. -- Publius
                        > Syrus (ca. 42 BCE)
                        >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@...
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                      • Ron Jeffries
                        ... Pair programming? Ron Jeffries www.XProgramming.com I could be wrong. I frequently am.
                        Message 11 of 12 , Mar 1, 2006
                        • 0 Attachment
                          On Wednesday, March 1, 2006, at 9:56:43 AM, Jeff Heinen wrote:

                          > What if a story requires effort from more than just one person?

                          Pair programming?

                          Ron Jeffries
                          www.XProgramming.com
                          I could be wrong. I frequently am.
                        • Thierry Thelliez
                          Here is what we usually do: 1- Sprint Review with everybody around the table (dev team, support, marketing,...) 1a- 5 minutes overview of the Sprint. A copy of
                          Message 12 of 12 , Mar 2, 2006
                          • 0 Attachment
                            Here is what we usually do:

                            1- Sprint Review with everybody around the table (dev team, support,
                            marketing,...)
                            1a- 5 minutes overview of the Sprint. A copy of the burndown chart
                            is used to show the main events of the Sprint. Picks due to bug, support,
                            sick leave,... The high level obstacles are discussed.
                            1b- About 1hour: demos. This part is driven by a simple digital
                            picture of a white board we have in our 'team room' during the Sprint. We go
                            through everything we can demo. This is where we have some 'serial-report'
                            type of attitude. For the items we cannot demo we also briefly discuss what
                            happened (obstacles, issues,...).
                            1c- About 5 to 30 minutes: We discuss what should be on the next
                            Sprint. In general the top of the product backlog has already been well
                            discussed in another forum. We usually have some last minute support request
                            that we negotiate against the other backlog items.

                            2- Sprint Retrospective and Planning: (dev team)
                            2a- Introspection for 5 minutes: What can we do different? We have 2
                            week Sprints and I rarely get any inputs here... (I will use some of the
                            ideas I have seen in this thread to improve here).
                            2b- Planning for about 30 minutes: From Sprint Review Inputs we
                            update our Team white board. Because we have different skills and expertise,
                            we always have the same people signing for the same task types. The UI will
                            be done by the UI developer... This is probably where having heterogeneous
                            team members is not helping people seeing outside their tasks.



                            Thierry Thelliez


                            ________________________________________
                            From: scrumdevelopment@yahoogroups.com
                            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alex Pukinskis
                            Sent: Tuesday, February 28, 2006 9:38 PM
                            To: scrumdevelopment@yahoogroups.com
                            Subject: Re: [scrumdevelopment] Sprint Review vs Serial Report

                            Are you doing demos of working software in your Review?  Don’t UI and
                            backend people have to come together to make these demos actually work?

                            I frequently see teams spending 30 minutes to 1 hour on Sprint demos, 5 to
                            20 minutes on Sprint Review (usually the ScrumMaster just listing stats –
                            work done vs. committed, defects, test coverage, build success, etc) and 30
                            minutes to 4 hours on the retrospective.  Is your meeting wildly different
                            than these ranges?  Which part of the meeting are you struggling with?

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