Commitment and priorties

Last post 02:55 pm October 17, 2014
by Ian Mitchell
1 reply
Author
Messages
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!

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.