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

55277Re: [scrumdevelopment] Express checkout during a sprint

Expand Messages
  • RonJeffries
    Jun 11, 2012
    • 0 Attachment

      On Jun 5, 2012, at 6:57 PM, fortheloveofmathematics wrote:

      How does everyone handle high priority items that come in during the middle of a sprint?

      Currently both of my teams run one week sprints.  Coming up we will be all switching to two week sprints because of the type of work we are doing.  

      Now a few of our product people are worrying that they won't be able to get high priority items in mid-sprint.  Part of this is unavoidable because we make all our revenue on advertising and when a deal is made we have strict deadlines.

      The phrase "because of the type of work we are doing" does not suggest anything to me that would make me want to go to two week Sprints over one week, because I can't think of a "type of work" where two weeks is likely better..

      The phrase "because of the type of work we are doing", and the phrase "we have strict deadlines" does not suggest going to two week Sprints over one week, since your stakeholders are clearly concerned.

      Why do you think two weeks is better, in view of all this?

      I would prefer not interrupt sprints for that kind of stuff, and mentioned we could possibly allocate 10-15% of our sprint to those type of items and if they don't arise work on our tech debt.

      Do you have a real Product Owner? Isn't it their job to manage these "high priority" items? Are you the Product Owner? If so, why do you not want to deal with these revenue opportunities? If not, what is the PO's position on the matter? 

      I'd also like to inquire about why you have tech debt, and why you want to work on it separately from work bearing actual business value, instead of in the course of value-bearing work, but perhaps that is off topic.

      Any other ways of handling that?

      Some notions:

      Get the Product Owner to solve the problem instead of pushing it down onto the developers. This is Scrum 101.

      Figure out what kind of changes these are and evolve ways to do them without much interruption. Often some tools can be evolved to reduce the impact.

      Treat interruptions as an impediment and work with sales not to have them. It really isn't necessary to bend over and take it when people sign up for business. A reasonable deadline is quite often possible.

      Schedule "placeholder" stories or "resigner" stories that can be used to accommodate truly urgent work.

      Limit this kind of story strictly and make Sales live within the WIP limit. (This requires negotiation, not unilateral action, if you want to live. :) As do most things. )

      Ron Jeffries
      I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

    • Show all 12 messages in this topic