Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Sprint Commitment
Last Post 28 Nov 2012 08:12 AM by Ian Mitchell. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Patrick Owens
New Member
New Member
Posts:4
Patrick Owens

--
12 Nov 2012 06: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 06: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.
    Patrick Owens
    New Member
    New Member
    Posts:4
    Patrick Owens

    --
    13 Nov 2012 05: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:409
    Charles Bradley

    --
    14 Nov 2012 05: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)
    Patrick Owens
    New Member
    New Member
    Posts:4
    Patrick Owens

    --
    14 Nov 2012 07: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 07: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
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    28 Nov 2012 08:12 AM
    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
    seo