What Does a Scrum Team Commit To?

July 17, 2013

I mentioned in last week’s post that teams commit to a Sprint. The context of this statement involved tasking out User Stories so that the team understands the nature of the work and what need to be performed, the skills required, and an estimate on how much time it will take to complete that work. My point was that the team’s confidence in meeting its Sprint commitment by tasking out the work.

There are two things wrong with this:
  1. The most current Scrum Guide changed its wording from prior versions. What was a Sprint commitment is now a forecast. (My memory failed me on this point as I wrote last week’s post. Old habits die hard!)
  2. It was misleading for me to strongly associate tasking User Stories with achieving a Sprint forecast because in practice I favor committing to a Sprint Goal, which is in alignment with the current Scrum Guide.
It makes sense that the wording has changed from commitment to forecast. We don’t want to encourage the negative behaviors and outcomes that result from commitments being equated to guarantees of delivery (short-cutting quality in an effort to implement all of the User Stories, for example). But don’t be misled! This wording change is not about loosening up on accountability and giving teams an “out” because they failed to deliver.

Let’s say that User Story is discovered to be 2x to 3x larger during a Sprint than anticipated. A team that has committed to implementing a set of specific User Stories is in jeopardy of failing to meet its commitment.

Fortunately, the Scrum Guide provides an answer: teams should commit to Sprint Goal. By committing to a Sprint Goal, the team now has flexibility in regards to the functionality being implemented, as it is possible to negotiate with the Product Owner about what is necessary to satisfy the Sprint Goal.

Does this imply that we are right back to making the team feel good about itself despite its failure to plan appropriately and hit its own target?

It’s not a difficult stretch to arrive at this assessment. After all, the team is in control of its work and even collaborated in shaping the solution, so they should own it, right? And by own it, they should finish the work that they said would complete, when they said that they would complete it, right?

Not so fast. For some reason, something is off. The team either underestimated would it would take to complete the work as they planned it or new information and challenges were revealed once they had started the work – or some combination of both. Welcome to the nature of complex knowledge work where uncertainty and variability exist.

If the team’s estimate was somehow an order of magnitude off, then the team will need to ask themselves why this happened and what they can do to avoid this in the future. But there are times when all the up-front planning and estimating in the world won’t help. We need to roll up our sleeves and engage in the actual work to discover (learn) about those things that are hidden from us. And once we are equipped with this understanding, we now have the opportunity to manage the variability that is inherent with software development.

We have the option of pulling that User Story from the Sprint, to work on other User Stories and deferring work on that now larger User Story until later. Sometimes, all you need is a little time to determine another approach, perhaps aided by a research spike can be used to better inform the team on potential options.

As we defer, we can have a conversation with the business stakeholders about the level of difficulty and effort required. Once the business stakeholders realize the cost/benefit of a feature has significantly changed, they may prefer to pull the feature from the release altogether because other things become more important to them in the light of this new information. Or they may have a different angle on what is truly important about the feature that will have a significant bearing on the issue.

Agile is about transparency and visibility and this timely information-sharing and resulting conversation are one way agile teams inspect and adapt. We don’t have to dig in and continue slogging our way through a static list without reassessing the situation.

So, the team commits to a Sprint Goal, of which the content can be considered flexible – or at least negotiable – should challenges emerge. My take is that tasking out User Stories in Sprint Planning reduces the chances of needing to negotiate content in mid-Sprint because the team has engaged in more detailed thought and discussion about what it will take to implement a User Story, so the intent of my last post still holds true.

By is this all that a team commits to? Hmmm… Since we are talking about Scrum teams, what are the five Scrum values?

Ah, yes! One of them is Commitment. The team needs to be committed to completing each User Story to the satisfaction of the Product Owner, meeting the team’s Definition of Done. The team also must commit to honoring its Working Agreement.

The final word on commitment is that it comes from within. It can’t be mandated. There is an unspoken, intrinsic motivation and commitment that comes from people to complete work that they define and have under their control. And that is what we really need to cultivate.


Adem Joe said...

Makes sense,Basically these are the responsibilities that they are fulfilling in a very right way and which is quite impressive because that is the way how things are necessary to be especially scrum team building are doing really well that is why the have become the need of organizations.

May 12, 2014 at 6:42 AM
Regina Hilary said...

Thanks for the best blog.it was very useful for me.keep sharing such ideas in the future as well.this was actually what i was looking for,and i am glad to came here!
kids games free | games games | shooting games | tank games | apple shooter | stick war 2 | unblocked games

July 22, 2016 at 4:53 AM

Post a Comment