Emphasize that releases can be more often than once a sprint!
I always encounter teams that practice Sprints as mini-waterfalls, with software being integrated and made release-ready only at the end of the Sprint, so that the increment is ready for the Sprint Review. They feel this is what Scrum asks for as this is what Scrum Guide describes. What I would like to see underscored in the next edition is that making releasable software available at the end of the sprint is just a minimal requirement and having it integrated & tested more often is encouraged even though not required.
Resolved in Nov 2017 release.
Marc Trudeau commented
I think shorter sprints, which I find many teams naturally adopt as they learn/improve, accomplishes much the same thing with the added benefits of further reducing context switching and increasing swarming.
Charles Bradley commented
Interestingly, I think that the Scrum Guide already requires multiple increments per Sprint.
See this other suggested Scrum Guide change for more details:
Mike Dwyer commented
This is an advanced concept introduced by Jeff Sutherland in 2005 when he wrote about Type A, B and C scrum. James Coplein wrote an excellent piece on this for the Scrum Alliance and I urge you all to read these works.
A couple of thoughts.
To get to this level of delivery (Type C - Continuous) you need to have a team that has core scrum part of their dna. That means intuitively delivering the outcomes of the Core Frame as outlined in the ScrumGuide. Do not think this is performing the rituals, this is delivering on commitments.
If you have not experienced a Type C scrum, then this may not make sense to you, unless you have tried to take a team to Type C and they were not ready.
Wayne Mack commented
Would someone care to describe how mid-sprint releases work with sprint reviews? It would seem that this would interfere with the inspect and adapt loop.
I understand the concern with teams doing "mini-waterfall", but I am not sure that mid-sprint releases are the appropriate solution. I also recognize that many teams need to go through the mini-waterfall approach before getting to a more continuous flow model.
Jelle van Wieringen commented
@Andy. Are you saying that you want to encourage teams that meet the Definition of Done continuously rather than at the end of a Sprint? I agree with that but consider it as a best practice.
As for your proposal. Please note the word "coherent" in the Scrum Guide: "The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal."
If I follow your thinking correct, then you suggestion implies multiple Sprint Goals per Sprint.
Charles Bradley commented
I agree with the sentiment, the trick is to emphasize it without suggesting that it "should" be that way. I think some clarification of the current language might help people see that Scrum only requires that you have a PRI(Pot Releasable Increment) at the end of the sprint, AT THE LEAST, but you can do it more often than that if you like.
Serkan Bolat commented
If a team seems to be capable of releasing more than one increment during a sprint, maybe shorter sprint durations should be set.
Andrew Marshall commented
I disagree with this suggestion for two reasons. First, there is nothing in the scrum guide forbidding you from releasing as often as you want to. It's a guide, not a set of rules. Second, the words "software" and "program" do not appear in the Scrum Guide and never should. I just presented Scrum to my company yesterday and someone asked if it could be applied to other industries. I replied with a smiling "Yes!"
BTW, I suggest embracing the idea that sprints are mini waterfalls. At some level, everything we do is a mini waterfall and there's nothing wrong with that. I feel it's a fact of life.
Mishkin Berteig commented
I think that if we start including "encouraged even though not required" items in the Scrum Guide, we would end up with a huge methodology document instead of a spare, just-enough description of an important framework. I don't think that including this is such a good idea. If it's in the Scrum Guide, it should be a required part of the definition of Scrum.