Skip to main content

Uncommitted sprint work

Last post 08:22 am March 5, 2018 by Ian Mitchell
3 replies
07:12 am March 3, 2018

During sprint planning my team has come upon the situation a few times where they aren't comfortable committing to the highest priority story.

In one case the story was too large, and the only way the team and PO could split it up was horizontally by component, or by splitting up into dev and test. In either case, no potentialIy shippable increment would be achieved to offer business value. I'm curious if folks here feel that it is acceptable nevertheless to split in that manner

In another case there was a major impediment that was not expected to be cleared in time to allow completion of the story, but progress could at least be made. The team felt there was a need to work on it and make some progress given the critical priority (with the customer demanding it ASAP). They just couldn't commit to getting it Done because of the impediment.

In both of these cases they elected not to commit to the story but worked on it during the sprint treating it as if it were the highest priority. This seems like a scrum anti-pattern- if a team can't commit to work in a particular sprint there's not much point to a sprint time box, right? But what's the alternative in either of these cases?


10:46 am March 3, 2018

Scrum doesn’t say anything about committing to stories. It talks about committing to goals. In your situation, team members were able to assert what they could and could not commit to. It seems they were able to collaborate on that matter and to be transparent about their agreed commitment, which is a good thing.

What is lost, when those commitments don’t result in Done work, is empirical process control. The challenge of course is to refine and right-size the work so a useful and Done increment can in fact be produced. Two questions to ask during refinement are:

- How can we break down a challenging item into scenarios which allow assumptions about it to be validated, unknowns to become knowns, and the size of the challenge to thereby be reduced?

- How can we navigate an anticipated impediment so demonstrably valuable work is done before our effort is impeded? Can we learn something about the product which helps to resolve or clarify that impediment?

Remember that an MVP is primarily about learning so empirical process control can be demonstrated. Fitness for release, and what constitutes a Done and feature complete increment, can be seen in those terms. The Development Team and Product Owner should refine the Product Backlog accordingly.


06:41 am March 5, 2018

Thanks Ian. I've been operating with the understanding that the team should be striving to commit to a set of PBIs per sprint (i.e. making up the sprint backlog). Would you agree with that?

I'm not sure if the decomposed increments you are suggesting are of a nature that would be better classified as a spike rather than a story. Do you have any thoughts on that?

In either case, I interpret your comments and questions to mean that it is okay to decompose work into increments that may not be potentialIy shippable as long as they can be demonstrated or lead the team toward learning. Is that a fair paraphrase?


08:22 am March 5, 2018

Thanks Ian. I've been operating with the understanding that the team should be striving to commit to a set of PBIs per sprint (i.e. making up the sprint backlog). Would you agree with that?

It’s up to the team what they choose to commit to, but it may be better to commit to the actual goal rather than the plan or forecast of work.

I'm not sure if the decomposed increments you are suggesting are of a nature that would be better classified as a spike rather than a story. Do you have any thoughts on that?

They should be of value to the product owner irrespective of how they are described. They could be considered as spikes in so far as they may assist the Product Owner in learning about the product, its scope, and how best to deliver value.

In either case, I interpret your comments and questions to mean that it is okay to decompose work into increments that may not be potentialIy shippable as long as they can be demonstrated or lead the team toward learning. Is that a fair paraphrase?

Increments must be fit for release into an empirical environment. It’s only through empiricism that validated learning can occur. Another way to look at it is that the Product Owner must obtain value from those lessons.


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.