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

53441Re: [scrumdevelopment] Re: Stable Velocity?

Expand Messages
  • Wouter Lagerweij
    Dec 2, 2011
    • 0 Attachment
      Hi Sten,

      It seems your team is not very comfortable with working in sprints, yet. 

      A Question: You say the team has felt as a 'bad apple' about their velocity? Is there any direct pressure on them to increase their velocity? This could be (one of) the underlying issue for wanting to count partially done stories.

      Does the team themselves feel that there is a problem? You say they felt they had a good sprint, but did they see not finishing many stories as an issue in the retrospective? 

      From what you say, I'd probable work first on getting the team focused on preparing the stories for each sprint (do you do grooming session or something similar?). Ensuring stories have Acceptance Criteria defined *before* you take them into the sprint will make things much clearer within the sprint. It will also get your QA guys involved more and earlier. And usually, as soon as you start defining ACs, some possibilities for splitting up stories will automatically present themselves.

      Plus, by agreeing with the team that this should be worked on, they should be more willing to take less into the sprint, as the time reserved for backlog grooming is taken into account.

      Note that this is something separate from defining a Definition of Done, which is the generic checklist for every story, while the ACs are story-specific.

      Wouter



      On Fri, Dec 2, 2011 at 9:21 AM, Sten <steoj@...> wrote:
       

      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: Wednesday, November 30, 2011 11:00 AM
      > >Subject: Re: [scrumdevelopment] Re: Stable Velocity?
      > >
      > >
      > >
      > >
      > >
      > >
      > >Sten, you've given a lot more background which has highlighted some other risky practices... but I still don't understand what this means:
      > >
      > >
      > >> Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them
      > >
      > >
      > >Is your team trying to take partial credit for stories as Mike suggests?
      > >
      > > 
      > >-------
      > >Charles Bradley, CSM, PSM I
      > >Experienced Scrum Coach
      > >My blog: http://scrumcrazy.wordpress.com/
      > >
      > >
      > >>________________________________
      > >> From: Sten <steoj@...>

      > >>To: scrumdevelopment@yahoogroups.com
      > >>Sent: Wednesday, November 30, 2011 7:32 AM
      > >>Subject: [scrumdevelopment] Re: Stable Velocity?
      > >>
      > >>Delivering value to the business is always a good thing - even if it happens at the beginning of the next sprint. I think we totally agree there.
      > >>What happens in my team is that they take on a user story during sprint planning. So far everything is good.
      > >>Then sprint is started, and so is the implementation of the user story - mostly by one team member with a few tasks at the end for the QA. Actually most of the user stories are in progress from the beginning of the sprint and usually worked on by one person, that hands it over to
      > the QA person within the team for completion. QA's have a lot of work to do at the end of the sprint - if the user story is completed in time.
      > >>If not, the story is bled over to the next sprint - because the PO still thinks it is important - and believes the team when they say it's just a few hours left of it even if it is a Medium user story originally.
      > >>Then they continue with the user story in the next sprint and starts another when they have done "their" part of it. If they finish "their" user story before the sprint end, they agree with the product owner to pick another high priority one from the Product backlog that fits their competence. That is not a bad thing, but they seem not to care if they can finish it within the sprint or if the team in total is done with all other user stories they have committed in the sprint.
      > >>
      > >>To me it is obvious that they think it is far more efficient to work on something they know, rather than help
      > someone with something the know less about. Keeping the estimates of userstories that bleeds over from one sprint ot another I do not think is helping them see how important it is for them to work together - as a team.
      > >>
      > >>Hope this sheds some more light on what I am trying to describe.
      > >>
      > >>/Sten
      > >>
      > >>--- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
      > >>>
      > >>> Sten,
      > >>>
      > >>> > I do have an issue with the average velocity concept. In my team (I'm a
      > >>> Scrum Master for one team of 9 people not including myself and the PO)
      > >>> they insist on keeping the estimate on stories the almost complete in
      > >>> one sprint to get the "correct payoff" of the whole story even though
      > >>> completing it in the sprint they are in amounts to a 1 or a 2 and the
      > >>> original estimate was a 5 or an 8.
      > >>>
      > >>> I had a heckuva time following what you're saying here... are you saying that the team carries stories over and finishes them early in the next sprint? What's so wrong with this?  A concrete example would help -- hard for me to tell whether you're doing the correct thing or not.
      > >>>
      > >>>  
      > >>> -------
      > >>> Charles Bradley, CSM, PSM I
      > >>> Experienced Scrum Coach
      > >>> My blog: http://scrumcrazy.wordpress.com/
      > >>>
      > >>>
      > >>> >________________________________
      > >>> > From: Sten <steoj@>
      > >>> >To: scrumdevelopment@yahoogroups.com
      > >>> >Sent: Tuesday, November 29, 2011 4:52 AM
      > >>> >Subject: [scrumdevelopment] Re: Stable Velocity?
      > >>> >
      > >>>
      > >I do have an issue with the average velocity concept. In my team (I'm a Scrum Master for one team of 9 people not including myself and the PO) they insist on keeping the estimate on stories the almost complete in one sprint to get the "correct payoff" of the whole story even though completing it in the sprint they are in amounts to a 1 or a 2 and the original estimate was a 5 or an 8.
      > >>> >
      > >>> >I argue that the definition of velocity is COMPLETED features per sprint - not the value of several user stories completed over several sprints.
      > >>> >
      > >>> >I think the team is viewing me as tha bad guy trying to take away their "pay" wich they believe is the velocity.
      > >>> >
      > >>> >They do have other issues as well - some having the result of US not being completed at the end of the sprint - like silo-thinking "my tasks are done, so I'm done", planning the sprint to make sure there are tasks for everyone in the team.
      > Finishing all that are finshed the last two or three days of the sprint, working on their own and so on.
      > >>> >
      > >>> >The PO is seems to be accepting the teams excuses for not completing the user stories.
      > >>> >
      > >>> >Most of my efforts to help them change their approach seems to be viewed as an attempt to tell them what to do and how to do it, rather than taken in as something to reflect on.
      > >>> >
      > >>> >When accepting average velocity I let them keep on fooling themselves by thinking not completing userstories has no real negative impact because we'll complete it next sprint anyway.
      > >>> >
      > >>> >Thoughts?
      > >>> >
      > >>> >
      > >>> >--- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
      > >>> >>
      > >>> >>
      > >>> >> We typically use a 3 month rolling
      > average when calculating velocity. Given that a team gets zero points for a story that isn't finished at the end of Sprint, it's not uncommon for the following Sprint to show a small increase in velocity, as the stories rolled over are credited to it.
      > >>> >>
      > >>> >> Averaging the velocity smooths out the bumps, and also help reduce the likelihood that someone would try to "game" the system, e.g. call a story done when it's not really ready. I'd rather have the story done-done, even if it means spending an extra day on it at the beginning of the subsequent iteration.
      > >>> >>
      > >>> >> Mark
      > >>> >>
      > >>> >>
      > >>> >> --- In scrumdevelopment@yahoogroups.com, Ashish Mahajan <agileashish@> wrote:
      > >>> >> >
      > >>> >> >  http://ashish-the-agile-guy.com/2011/11/28/stable-velocity/
      > >>> >> >
      > >>> >>
      > >>> >
      > >>> >
      > >>> >
      > >>> >
      > >>> >------------------------------------
      > >>> >
      > >>> >To Post a message, send it to:  scrumdevelopment@
      > >>> >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links

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




      --
      Wouter Lagerweij         | wouter@...
    • Show all 23 messages in this topic