Back to Forum

Commitment and priorties

Last post 02:55 pm October 17, 2014 by Ian Mitchell
1 reply
Christopher Brown
10:07 am October 17, 2014

Hi,

Yesterday our Product Owner team went on a days scrum training for PO's and it seems to have caused some confusion within the organisation. We have been running scrum for around 2 years now and follow the 2013 scrum rules pretty much to the letter.

Commitment

The scrum trainer told the PO's that the engineers made no commitment what so ever other than to focus on the work in hand and tackle everything on a best endeavor basis. I agree that software development, just like any other engineering process, is difficult to predict. But i also believe that, whilst not explicitly defined, the team are committed to delivering the sprint goals. Once negotiated between the dev team and PO the sprint goals should be broad enough to allow the development team to navigate and satisfy the commitment by adjusting scope accordingly.

In some cases the development team won't be able to deliver the goals due to a variety of potential issues. In these scenarios the development team should be encouraged to communicate the issues at hand with the PO and be prepared to cancel the sprint as soon as scope adjustment becomes no longer feasible and the goal not deliverable.

Sprint Backlog Priority

The trainer also told the PO's that the development team must work on the PBI's in the exact order it was defined in the Product Backlog. That was not my understanding as i was under the impression it was entirely the development teams responsibility to organise the sprint backlog with a focus on delivering the goals as effectively as they can.

I would welcome your thoughts and ideas on the above topics. My concern is that the trainer in question may not have been familiar with the most recent version of the scrum rules that in my opinion focus on development goals in order to provide greater flexibility for the development team to respond to change.

Thanks in advance!


Ian Mitchell
02:55 pm October 17, 2014

The "commitment" in Scrum is indeed to the Sprint Goal. The Sprint Backlog is effectively the team's forecast of the work needed to meet that commitment, and is subject to revision.

If the PO cancels a Sprint because the Goal is redundant or seemingly unachievable, the Scrum Team should attempt to release as much value as possible from the work already done. In that context, with the absence of a Sprint Goal, the team's subsequent endeavors might be described as best efforts.

The Development Team own their Sprint Backlog and can order it any way they like as long as they deliver the anticipated Potentially Releasable Increment. There's nothing to stop them agreeing a certain order of actioning with other stakeholders such as the PO, but they are not required to do so.

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.