Skip to main content

Voluntary over commitment

Last post 03:00 pm October 10, 2019 by Sherwin Soriano
6 replies
08:20 am October 9, 2019

The team I'm currently working with want to voluntarily over commit to work in the sprint.  So generally we have a pretty good idea what can be taken into the sprint comfortably, and then the team often want to voluntarily (no pressures from the organisation) add a stretch story to the sprint.

Right now its early days on a greenfield project with a single team - but I'm just wondering what the future or current unforeseen perils of this might be.

Currently the only issues I can think of are:

  • The velocity chart will not look good (it will show X committed but Y delivered for several sprints) - but I might be able to talk around this when it goes in front of stakeholders
  • We're potentially promising to deliver something on a certain date, and then we don't deliver it. e.g.  dependencies for another team - but I guess as long as we communicate its a stretch, no one should rely on this.

Are there any other potential pitfalls of this that I'm not seeing?


10:33 am October 9, 2019

A pitfall could be you might not be adhering to the "Sustainable Pace". In other words, people in the team might be burning more energy than they can on the long run. you might be unknowingly be burning them down (or they are burning down themselves)

With regards to your velocity charts: it is a metric to help you plan, and which might help to visualize tema improvements. it is not a promiso for future work nor is it an argument for performance. be very careful how this metric is used, where it is used for, and who uses it.

With regards to your promise: adding a stretch story to the sprint is not the same as making a promise. The team commits to the Sprint Goal, that commitment might be seen as a "promise" in a way. But adding a stretch sory is not the same.


12:43 pm October 9, 2019

I think that's great that the team has the commitment to take on some additional work after meeting their primary goal.

Given that this work is usually a stretch goal which may not be completed in the Sprint do you think the items they're choosing to focus on provide the most value? It could be a good opportunity for them to explore some PBI's that would improve their ability to innovate or time to market such as technical debt, automated testing, continuous integration, etc. 


01:43 pm October 9, 2019

The velocity chart will not look good (it will show X committed but Y delivered for several sprints) - but I might be able to talk around this when it goes in front of stakeholders

Why would there ever be a need to discuss a team's velocity with stakeholders?

On another note, I am personally not in favor of a team adding a "stretch" story (or stories) to a sprint, for the reasons stated already (makes a sustainable pace more challenging, reduces transparency around the actual forecast), but also because it adds lean waste to the sprint.   The Lean Waste is in the form of talking about item(s) that may not be delivered in a sprint, and carrying items from sprint to sprint due to unfinished work.

It is a much more preferable (and cleaner) approach to "pull" item(s) into a sprint as extra capacity allows, than overloadiing a sprint at the start.

 


02:01 pm October 9, 2019
  • The velocity chart will not look good (it will show X committed but Y delivered for several sprints) - but I might be able to talk around this when it goes in front of stakeholders
  • We're potentially promising to deliver something on a certain date, and then we don't deliver it. e.g.  dependencies for another team - but I guess as long as we communicate its a stretch, no one should rely on this.

What is X, if it is not the Sprint Goal? Why would this so-called "stretch story" represent a commitment at all?


07:47 pm October 9, 2019

To add onto what Ian asked, the Sprint Goal outlines what should and should not be in the Sprint and helps align the team on what the expected Sprint Review demo would focus on. The commit is on the Sprint Goal and not the individual stories. What kind of work do you consider to be the over commit? Is it tied to and required for the Sprint Goal?

The velocity really should help you gauge if there is just enough work for the sprint based on the Sprint Goal. If there is too much, then adjust the Sprint Goal appropriately. At the Sprint Review, you focus on the delivery of the Sprint Goal. The velocity is completely irrelevant. Teams don't deliver output, if that makes sense. That metric is just a Sprint planning tool used to help you start the conversation about capacity.


04:33 am October 10, 2019

Based on the example above about X and Y, it will be helpful if the team understands why they they did not complete or reach the committed items and how they can adjust or adapt or improve on it.


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. For privacy concerns, we cannot allow you to post email addresses. 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.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.