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

Re: [scrumdevelopment] Re: Stable Velocity?

Expand Messages
  • Alan Dayley
    - We ve been working for 18 months and no release to.production yet - 7 of 30 points done in a sprint and the team feels it was a good sprint. Do you think
    Message 1 of 3 , Dec 2, 2011
    • 0 Attachment
      - "We've been working for 18 months and no release to.production yet"

      - 7 of 30 points done in a sprint and the team feels it was a good sprint.

      Do you think there may be a correlation between the above two points?

      Is velocity the problem or is it just a side discussion distracting from the real issue?

      Alan


      ----- Reply message -----
      From: "Sten" <steoj@...>
      To: <scrumdevelopment@yahoogroups.com>
      Subject: [scrumdevelopment] Re: Stable Velocity?
      Date: Fri, Dec 2, 2011 12:21 am


      The last sprint was probably more or less typical - at least they seem not to be particularly worried about it:
      Sprint 36 (Yes, two week sprints) the team took on Story1, Story2, Story4, Story6, Story7, Story8, Story9, Story10, Story11, Story12 and Story13, totalling 30 storypoints.
      In addition they were spiking Story 3 and Story 5.

      The PO needed some help from the team (!) to clarify what userstories was actually done and the PO and the team conlcuded only Story7, Story9 and Story11 was done, totalling 7 story points.
      The team all agreed it was a good sprint thoug, because they did get a lot of work done.

      During sprint planning part I Story12 was postponed to a later sprint but other than that all unfinished stories from sprint 36 was continued to sprint 37.

      For sprint 37, the team added Stories 14 through 26, the spiked stories from 36 (Story3 and Story5) in addition to the uncompleted ones from sprint 36, totalling 56 storypoints.
      As I'm writing this, (end of sprint on Wednesday next week) Story3, Story4, Story5, Story6 and Story8 is done (13 sp). The rest (all of them) is ongoing - a handful of them waiting for QA to pick up.

      The team has 9 members, two scripters, two QA and five Business Analysts in addition to full-time SM and PO.

      The project is high profile within the company. We've been working for 18 months and no release to production yet. We are not writing much code, more configuring an off-the-shelf product (that is not a result of Agile development - average bug fix time on core product is 105 days) to suit the business. The product is core business and quality is essential.
      Up to this sprint, the project has asked the PO's to report progress in terms of percent of target scope (!). For some time during the project my team has felt as the bad apple in the project (there are 4 other teams) where velocity has been an issue.

      I have taken over the SM responsibilities of this team since roughly 5-6 sprints ago. My predecessor - an experienced SM - was literally sacked from the team after beeing very pushy on agile practices. It seems they perceived almost every suggestion he shared as critisism to the way they worked.

      I have decided to lay low (remember: A dead SM is a bad SM) and stroke them by the hairs for a while. I believe they behave like this for several reasons, amongst them the way the project is structured. In addition no-one in the team are really experienced in agile practices and quickly concludes that "it is not possible" beeing finishing small user stories quicker within a sprint, splitting them in a user-oriented way or pairing to learn of eachother.

      My point in the original post was that keeping the estimate of the stories bleeding over from the previous sprint might "hide" the issues a little. I'm thinking the unfinished should be re-estimated prior to the sprint they are taken into so the PO will have a fair chance at doing the ordering properly. It would mean that the total storypoints taken into this sprint is a little lower - maybe a little over 40? -  but at least it would be more obvious to the team (I hope) that changing the way they work might be a good idea.

      We are a good team of SM's focusing a lot on how the project organisation - not to mention the obvious lack of releases to production - is affecting the teams performance and the overall progress.

      This became a little longer than I had anticipated, but hope it clarifies my situation a little.

      /Sten

      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
      >
      > Another thing that would be interesting to know is how many stories usually "bleed" over.  It should rarely be more than 1.
      >
      > The overall tone of what Sten describes is that of a group of individuals, not a team.  The way this seems to be accepted as "business as usual" by the dev team smacks of a different dysfunction, like the individuals reporting to a manager who thinks the "parallel silo" thing is totally ok and doesn't give a flip about true teamwork.  Further, you have a QA sub-team which is also a no-no according to the Scrum Guide(though I realize many teams struggle with that).  On top of that, we have the throw it over the wall to QA at end of sprint thing which smells like Scrummerfall.
      >
      > Hard to know where to start here, but the biggest smell of them all is of the team working in parallel silos.  
      >
      > Other interesting questions:  How many devs?  Roughly how many (non bleed over)stories are usually brought into the Sprint at Sprint Planning?
      >
      >  
      > -------
      > Charles Bradley, CSM, PSM I
      > Experienced Scrum Coach
      > My blog: http://scrumcrazy.wordpress.com/
      >
      >
      > >________________________________
      > > From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
      > >To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      > >Sent: Wednes
    • RonJeffries
      Is the system fully integrated, running, demonstrable? R ... Ron Jeffries www.XProgramming.com I try to Zen through it and keep my voice very mellow and low.
      Message 2 of 3 , Dec 2, 2011
      • 0 Attachment
        Is the system fully integrated, running, demonstrable?
        R
        On Dec 2, 2011, at 4:08 PM, Alan Dayley wrote:

        - "We've been working for 18 months and no release to.production yet"

        - 7 of 30 points done in a sprint and the team feels it was a good sprint.

        Do you think there may be a correlation between the above two points?

        Is velocity the problem or is it just a side discussion distracting from the real issue?


        Ron Jeffries
        www.XProgramming.com
        I try to Zen through it and keep my voice very mellow and low.
        Inside I am screaming and have a machine gun.
        Yin and Yang I figure.
          -- Tom Jeffries

      • Sten Otto Johnsen
        You are hitting the nail on the head here! Incidentally they finished almost everything they took on in this sprint, one user story was blocked due to a defect
        Message 3 of 3 , Dec 9, 2011
        • 0 Attachment

          You are hitting the nail on the head here!

          Incidentally they finished almost everything they took on in this sprint, one user story was blocked due to a defect that will not be resolved until the next update from the vendor, and that will not happen until after the current sprint.

           

          They did, and have not really, seen the point in finishing the user stories within the sprint, because they could just continue working on them the next sprint. This is soon to end, as the current sprint is the last one before the whole thing goes into production (at last!). Unfortunately we are looking forward to a testing and debugging period, an even longer User Acceptance Test before the product goes live a few months from now.

           

          I suspect the attitude will change when we have frequent releases (monthly we hope) and the consequences of not completing something according to the Definition of Done is more obvious.

          Also, I am deliberately not pushing for improvement at the moment. Unless they see or feel they need to adjust something, I’m hands off.

           

          As Wouter suggested, I think they have been feeling a pressure to increase their velocity. Still working to let that wear off from them.

          During the planning session, one team member noted that this sprint, everything we take on must be completed. One other team member replied that if he HAD to complete everything he committed to, he’d rather not commit to anything.

          I sense there is fear of judgment from the management here.

           

          Thanks for all good advice and comments.

           

           

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan Dayley
          Sent: 2. desember 2011 22:09
          To: scrumdevelopment@yahoogroups.com; scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Stable Velocity?

           

           

          - "We've been working for 18 months and no release to.production yet"

          - 7 of 30 points done in a sprint and the team feels it was a good sprint.

          Do you think there may be a correlation between the above two points?

          Is velocity the problem or is it just a side discussion distracting from the real issue?

          Alan


          ----- Reply message -----
          From: "Sten" <steoj@...>
          To: <scrumdevelopment@yahoogroups.com>
          Subject: [scrumdevelopment] Re: Stable Velocity?
          Date: Fri, Dec 2, 2011 12:21 am


          The last sprint was probably more or less typical - at least they seem not to be particularly worried about it:
          Sprint 36 (Yes, two week sprints) the team took on Story1, Story2, Story4, Story6, Story7, Story8, Story9, Story10, Story11, Story12 and Story13, totalling 30 storypoints.
          In addition they were spiking Story 3 and Story 5.

          The PO needed some help from the team (!) to clarify what userstories was actually done and the PO and the team conlcuded only Story7, Story9 and Story11 was done, totalling 7 story points.
          The team all agreed it was a good sprint thoug, because they did get a lot of work done.

          During sprint planning part I Story12 was postponed to a later sprint but other than that all unfinished stories from sprint 36 was continued to sprint 37.

          For sprint 37, the team added Stories 14 through 26, the spiked stories from 36 (Story3 and Story5) in addition to the uncompleted ones from sprint 36, totalling 56 storypoints.
          As I'm writing this, (end of sprint on Wednesday next week) Story3, Story4, Story5, Story6 and Story8 is done (13 sp). The rest (all of them) is ongoing - a handful of them waiting for QA to pick up.

          The team has 9 members, two scripters, two QA and five Business Analysts in addition to full-time SM and PO.

          The project is high profile within the company. We've been working for 18 months and no release to production yet. We are not writing much code, more configuring an off-the-shelf product (that is not a result of Agile development - average bug fix time on core product is 105 days) to suit the business. The product is core business and quality is essential.
          Up to this sprint, the project has asked the PO's to report progress in terms of percent of target scope (!). For some time during the project my team has felt as the bad apple in the project (there are 4 other teams) where velocity has been an issue.

          I have taken over the SM responsibilities of this team since roughly 5-6 sprints ago. My predecessor - an experienced SM - was literally sacked from the team after beeing very pushy on agile practices. It seems they perceived almost every suggestion he shared as critisism to the way they worked.

          I have decided to lay low (remember: A dead SM is a bad SM) and stroke them by the hairs for a while. I believe they behave like this for several reasons, amongst them the way the project is structured. In addition no-one in the team are really experienced in agile practices and quickly concludes that "it is not possible" beeing finishing small user stories quicker within a sprint, splitting them in a user-oriented way or pairing to learn of eachother.

          My point in the original post was that keeping the estimate of the stories bleeding over from the previous sprint might "hide" the issues a little. I'm thinking the unfinished should be re-estimated prior to the sprint they are taken into so the PO will have a fair chance at doing the ordering properly. It would mean that the total storypoints taken into this sprint is a little lower - maybe a little over 40? -  but at least it would be more obvious to the team (I hope) that changing the way they work might be a good idea.

          We are a good team of SM's focusing a lot on how the project organisation - not to mention the obvious lack of releases to production - is affecting the teams performance and the overall progress.

          This became a little longer than I had anticipated, but hope it clarifies my situation a little.

          /Sten

          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
          >
          > Another thing that would be interesting to know is how many stories usually "bleed" over.  It should rarely be more than 1.
          >
          > The overall tone of what Sten describes is that of a group of individuals, not a team.  The way this seems to be accepted as "business as usual" by the dev team smacks of a different dysfunction, like the individuals reporting to a manager who thinks the "parallel silo" thing is totally ok and doesn't give a flip about true teamwork.  Further, you have a QA sub-team which is also a no-no according to the Scrum Guide(though I realize many teams struggle with that).  On top of that, we have the throw it over the wall to QA at end of sprint thing which smells like Scrummerfall.
          >
          > Hard to know where to start here, but the biggest smell of them all is of the team working in parallel silos.  
          >
          > Other interesting questions:  How many devs?  Roughly how many (non bleed over)stories are usually brought into the Sprint at Sprint Planning?
          >
          >  
          > -------
          > Charles Bradley, CSM, PSM I
          > Experienced Scrum Coach
          > My blog: http://scrumcrazy.wordpress.com/
          >
          >
          > >________________________________
          > > From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
          > >To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
          > >Sent: Wednes


          -------------------------------------------------------------------
          The information contained in this message may be CONFIDENTIAL and is
          intended for the addressee only. Any unauthorised use, dissemination of the
          information or copying of this message is prohibited. If you are not the
          addressee, please notify the sender immediately by return e-mail and delete
          this message.
          Thank you
        Your message has been successfully submitted and would be delivered to recipients shortly.