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

Re: [scrumdevelopment] Re: Variable sprint lengths

Expand Messages
  • Emiliano Heyns
    ... I like that. In our case, however, the person closest to having something that could be labeled BA skills without the rest of the group sniggering would be
    Message 1 of 10 , Oct 2, 2007
    • 0 Attachment
      On 10/2/07, paul_oldfield_ams <Paul.Oldfield@...> wrote:
      (responding to Emile)

      > No, unfortunately. He works part-time, and only about half
      > of the time he's available to the organization is allotted
      > to us. Effectively, that means 1-2 days a week. He goes
      > off on holidays quite frequently. I can hardly begrudge
      > him that, but it is inconvenient for our team.

      One thing I've had succeed on a RUP project might work for
      you?

      We assigned someone from our team to act as "Product Owner"
      proxy and spend all the time available with the true PO
      to capture as much as possible of the relevant information.
      The rest of the time this proxy PO was acting as a PO for
      the rest of the team.  The proxy had good Business Analyst
      skills, so could use his time effectively when with the
      true PO.

      I like that. In our case, however, the person closest to having something that could be labeled BA skills without the rest of the group sniggering would be me -- and I don't think PO and SM should be the same person.

      Emile
    • 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 2 of 10 , Oct 2, 2007
      • 0 Attachment
        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 3 of 10 , Oct 2, 2007
        • 0 Attachment
          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 4 of 10 , Oct 2, 2007
          • 0 Attachment
            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 5 of 10 , Oct 2, 2007
            • 0 Attachment
              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.