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

Re: [scrumdevelopment] Variable sprint lengths

Expand Messages
  • Emiliano Heyns
    ... That is a very good question indeed. Our project was started to automate the calculation of KPIs (Scorecarding) for units within our organization. These
    Message 1 of 10 , Oct 2, 2007
      On 10/2/07, Wolfgang Schulze Zachau <wolfgang@...> wrote:
      Well, I suppose the fundamental question really is how important is this project to the company? If it is really important, then surely they can be made to understand that a fully committed Product Owner is essential for the success of it.

      That is a very good question indeed. Our project was started to automate the calculation of KPIs (Scorecarding) for units within our organization. These KPIs have so far been done by hand, which we've already established was error prone and not even consistently wrong when the numbers indeed were off. But the bottom line is that the KPIs can be done by hand -- the pain and cost involved might not be visible enough.

      Our own PO also has other duties, but there is no doubt in anybody's mind that his PO duties come first.
      We sometimes vary the length of sprints by single days, but then we have been doing Scrum for 2 years now, with a fixed team.

      We're talking full-week deviations on 3-week sprints. We've only been doing this since May or so.

      Option 4 sounds like a good choice, expecially if you do have other work to do.

      We do.

      In the long run I would try and move towards option 1. The current PO can still be an influential stakeholder and provide input to the PO, but a fulltime PO is always better than a part-timer. Same goes for the team. Here I would raise the question whether it is worth while to put all your work into ONE big product backlog (seeing that you have ONE pool of resources) and the work off that.

      We sorta-kinda do in the team to keep an eye out to make sure each project mostly gets their allotted time. But the projects have no real common ground, and the people involved are not necessarily the same persons.

      I presume you are currently the Scrum Master?

      You presume correctly ;)

      How about training somebody else for that role and becoming PO yourself?

      A 2nd SM is going in for training in December, so it's worth consideration. I must say I'm enjoying being SM immensely.

      The problem with a part-time PO is that Scrum is based on lots of communication going on between the PO and the team. Without this, there will be misunderstandings and lack of knowledge/information and subsequently the solutions implemented by the team will be off target (Even XP asks for a customer on site full-time, for the very same reason). It's almost always better to have a fulltime PO with less domain knowledge compared to a part-time PO with full domain knowledge. The domain knowledge can be built, time cannot.

      Good point. What is clear to me is that this is indeed going to be the cause of inefficiency, so I'll raise it at the next retrospective.

      Emile
    • Petri Heiramo
      Hi, ... limited ... lengthen ... at the ... I consider these things as one of those just have to manage with situations. You should keep trying to set up a
      Message 2 of 10 , Oct 2, 2007
        Hi,


        > I'm wondering what to do about the variability of our sprint lengths. It
        > makes it a bit harder to monitor our velocity, but our PO has very
        limited
        > availability and way too much leave time, so we've had to slightly
        lengthen
        > or shorten our sprint lengths so far in order to have the PO present
        at the
        > review session. How much of an issue is this?

        I consider these things as one of those "just have to manage with"
        situations. You should keep trying to set up a regular cycle, but
        until that day happens (if it ever does), you'll have to try to set up
        each sprint as a timeboxed iteration with a predefined end date
        _at_the_start_ of the sprint. So even if each sprint is slightly of
        different length, they are all of predefined length. Try to get the PO
        committed to each sprint review session well in advance. Changing end
        date _during_ the sprint should be avoided. Then again, if you can't
        avoid that, then just replan a little based on new end date.

        I know that's not a book example but reality never is. Remember the
        purpose of iterations, never lose sight of that (i.e. clear checkpoint
        to see where the project is, a replanning and communications session
        with the product owner, and an opportunity to meet stakeholders for
        feedback). You should be fine.


        Petri Heiramo
        Senior Process Improvement Manager
        SYSOPENDIGIA Plc., Finland
      • Petri Heiramo
        Wolfgang has a very good list of why you should try to get to the regular release cycle. :) I agree with all that. Bring it to the attention of the PO. See if
        Message 3 of 10 , Oct 2, 2007
          Wolfgang has a very good list of why you should try to get to the
          regular release cycle. :)

          I agree with all that. Bring it to the attention of the PO. See if
          he/she can sort the participation. But I don't think you can just say
          "I refuse to co-operate until you agree to a fixed schedule".
          Communicate with patience and try to work out a solution.


          Petri Heiramo
          Senior Process Improvement Manager
          SYSOPENDIGIA Plc., Finland


          --- In scrumdevelopment@yahoogroups.com, "Wolfgang Schulze Zachau"
          <wolfgang@...> wrote:
          >
          > This is a wonderful example of how Scrum exposes weaknesses in an
          > organization, which now has a chance to reconsider various options
          and the
          > importance of Scrum.
          > The very simply answer is: Don't. Do not vary the length of your
          sprints. It
          > plays havoc with all sorts of things. Your velocity is never really
          quite
          > clear, people have trouble with committment, your customers cannot
          rely on a
          > regular cycle of delivery, and the list doesn't stop here. We did
          it, and
          > our troubles only stopped when we stopped modifying sprint length
          (and some
          > other things). It's one of those rules that cannot be bent or broken
          without
          > braking the whole thing.
          > The underlying problem is that your PO is not committed. If (s)he
          was, (s)he
          > would make sure to be there when needed. If someone has a
          responsibility,
          > but cannot or won't fulfil it, it shows a lack of accountability and
          > committment (or authority, but I don't think that's the case here).
          So now
          > the question is: why? Is (s)he working fulltime as a PO? Or is this
          just one
          > of a list of activites for her/him? If yes, why? Does the top brass
          believe
          > in Scrum? Do they understand how it works? Are they pulling the PO in
          > different directions? Or is it the PO herself/himself?
          > (and there are more questions to ask).
          > And yes, you are right: there is absolutely no point in closing a sprint
          > without the PO.
          >
          >
          > Regards,
          >
          > Wolfgang
          >
          >
          >
          >
          > _____
          >
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emiliano Heyns
          > Sent: 02 October 2007 10:38
          > To: scrumdevelopment@yahoogroups.com
          > Subject: [scrumdevelopment] Variable sprint lengths
          >
          >
          >
          > Hi,
          >
          > I'm wondering what to do about the variability of our sprint lengths. It
          > makes it a bit harder to monitor our velocity, but our PO has very
          limited
          > availability and way too much leave time, so we've had to slightly
          lengthen
          > or shorten our sprint lengths so far in order to have the PO present
          at the
          > review session. How much of an issue is this?
          >
          > We're managing so far, but that may be because we're just getting
          ramped up
          > on scrum, so we may not be noticing how much we're missing. I can't
          really
          > force the PO to be present, however, and closing the sprint without him
          > would be pointless.
          >
          > Emile
          >
        • David Milner
          Having a proxy PO is a good idea. Also an option would be to make a business analyst of some sort who works in the same area as the PO the official PO, and
          Message 4 of 10 , Oct 2, 2007
            Having a proxy PO is a good idea.  Also an option would be to make a business analyst of some sort who works in the same area as the PO the "official" PO, and move the part-time PO just to a stakeholder type of position just based upon availability.  If the current PO has great business sense, experience, and is valuable that's a good way to keep them in the loop while not sacrificing Scrum principles.
             
            Dave


            Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
          Your message has been successfully submitted and would be delivered to recipients shortly.