Forums

By posting to our forums you are agreeing to the Forum terms of use.
Sprint Commitment
Last Post 28 Nov 2012 12:12 PM by Ian Mitchell. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pat
New Member
New Member
Posts:4
Pat

--
12 Nov 2012 10:07 AM
    I'd like to get a feel about how other scrum teams define the word 'commitment'. When we 'commit' to a sprint, we define that as 'it will be done no matter what'. If that means working extra hours the last few days of the sprint, then that is what we do.
    In talking to others, it seems like this is a bit of an outdated philosophy. The term 'forecast' is now being used? Maybe using a velocity range from the previous sprints?
    The problem I have with our current definition of 'commitment' is that a basic philosophy of Agile is that humans are not good at estimating. If so, how can we 'commit' to an exact set of items to get done in a 2 week time frame for 7 people?
    How do other scrum teams define 'commitment'? What do you do if not everything gets done in the sprint?
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    12 Nov 2012 10:29 AM
    You are getting to the heart of why this word was replaced in the Scrum Guide. You can find some context to the change here (http://www.scrum.org/About/All-Arti...to-Scrum).

    What do you do if not everything gets done in the sprint?

    As soon as this situation becomes a possibility we make sure to inform those who care. Particularly the Product Owner so we can discuss our options.

    We might also explore the why this occurred during our Retrospective (or any time really). This is particularly important if the current process and environment doesn't surface this information with an opportunity to make adjustments. For instance, if it only became clear in the last few days of the sprint that something might not be fully Done, what experiment can we come up with to surface this information more readily. It may be a simple gut check during the Daily Scrum or it may be a change to reduce serial task execution.

    Either way, you are right on: we cannot avoid the Cone of Uncertainty even within the Sprint. For that reason, we do not use the word commitment with all of it's baggage.
    Pat
    New Member
    New Member
    Posts:4
    Pat

    --
    13 Nov 2012 09:51 AM
    Thanks for the comments, Ryan. I definitely agree that 1) as soon as we see that items may not be done in the sprint that we let the appropriate people know, and 2) discuss this in the retro to learn from it.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    14 Nov 2012 09:10 AM
    I agree with what Ryan said, and the only thing I would add is to watch out for carrying over lots of items. Sometimes(often, but not always) consistently carrying over more than 2 PBI's is a smell of something else that is not working well. (Examples: siloing, requirements churn, waterfall baggage, over committing, etc)
    Pat
    New Member
    New Member
    Posts:4
    Pat

    --
    14 Nov 2012 11:00 AM
    My guess is that our velocity will probably increase by going away from a hard commitment to a 'forecast'. I think it is human nature to lower your estimate if you are required to do a hard commitment. There is always that Cone Of Uncertainty in the back of your mind.
    Ryan Cromwell
    New Member
    New Member
    Posts:89
    Ryan Cromwell

    --
    14 Nov 2012 11:09 AM
    Be careful not to equate higher velocity with more value delivered. This
    is an easy and common mistake.
    ------------------------------
    From: ScrumForum@scrum.org
    Sent: 11/14/2012 11:59 AM
    To: ryan@echelontouch.com
    Subject: RE: Sprint Commitment [00000209:00000672]

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:567
    Ian Mitchell

    --
    28 Nov 2012 12:12 PM
    As Ryan Cromwell points out, you are getting to the heart of why this word was replaced in the Scrum Guide. It has been a controversial change because:

    1) It raises serious questions about Commitment-Based Planning, how it can be done, and even if such techniques are appropriate at all. Alternatives such as Velocity Based planning are arguably less suitable for new teams when they haven't established a velocity yet.
    2) It potentially makes the application of agile contracts harder. If a contractual view is taken of a Sprint (i.e. that a supplier will supply X within timebox Y) then reducing this to a forecast may result in perceived breaches of contract, or at least in increased risk from the POV of the customer. This is a hot topic and there is a fortune to be made by lawyers out of it.
    You are not authorized to post a reply.


    Feedback