Uncommitted sprint work
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?
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.
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?
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.