Resolved in Nov 2017 release.
Interestingly, I think that the Scrum Guide already requires multiple increments per Sprint.
See this other suggested Scrum Guide change for more details:
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.Charles Bradley supported this idea ·
Added to July 2016 Scrum Guide
Responding to some earlier comments... Here's what it boils down to with me. The previous use of the term "Sprint Commitment" was deemed to be harmful to Scrum and value delivery due to its misunderstanding by those outside the Scrum Team. As such, by bringing the word "commitment" back, I think we will be confusing a lot of people, and returning back to older habits that were deemed harmful to Scrum and value delivery. If we didn't have that baggage in the Scrum world, I wouldn't have a problem with the word in this context at all. Btw, 4 years after the term "commitment" was changed to "forecast", I still see it used at almost every coaching client I go to.
Someone asked how many "votes" this would have to get to for me to change my mind.
People who know me know I stand on principle, not popularity, which sometimes is to my detriment, and other times to my benefit. There is no amount of votes that would convince me otherwise. It's a principles thing. I want to improve the profession of software development like all of you do, we just disagree on the route to get there.
I teach probably 30-40 classes a year, and coach the rest of the time, and the number of times the word "commitment" has confused people and harmed value delivery has convinced me that, IMO, we need a different word.
So, to help allay that confusion, I'm suggesting we use a synonym that either means the same thing, or can be clarified in the guide to mean the same thing that the word "commitment" means.
I respectfully disagree, but I'm also not going to lose sleep over it. It's just my opinion.
Iain, re: --> "Charles, what about..."
1. Your phrasing sounds a lot like "dedication to value delivery", except uses many more words.
2. I'm very uncomfortable with your use of the words "achieve the most they can" because I think it will be interpreted as ""achieve the most [work] they can", which is a toxic direction to send teams in...
3. The term "commitment", at least in the USA, comes with a lot of baggage by those outside the Scrum Team -- especially stakeholders and dev mgmt. This is why the word "commit" was changed to "forecast" in a previous Scrum Guide. It leads one down a road of schedule/scope/cost/deadlines which is toxic to value delivery. It also strongly implies contracts instead of collaboration. Schedule/Scope/Cost is a dead model, and any words like commitment are a shortcut back to that thinking.
Thus, my intention to push us away from s/s/c and towards dedication to value delivery. There, I'm at a first of five. With your current proposal, I'm at a fist of 1.
I could probably be at a fist of 3 if you wanted to change the language to "dedication to helping each other" or "dedication to teamwork".
However, the word "commit" or derivations of it, are a fist of one for me. Non starter.
For those of you that don't know me, I'm known in the Scrum.org community for being the "Scrum Guide nerd" -- a term I originated for myself, and others have understood why through my actions. I focus very intently on the Guide and its wording, because I think many people make fundamental misses(misunderstandings) when they read the guide and don't give it the deep reflection it deserves. So, just a quick introduction to where I'm coming from with this line of thought.
Or maybe "dedication to value delivery" instead of commitment.
I could only be in support of this if the word "commitment" was changed to "dedication" or similar word. "Commit" baggage from previous Scrum Guides still persists. Count me as a vote "against" for now.
The word “confusing” is used. Does that mean that Scrum is not absolutely, incredible clear to everyone who uses it for whatever purpose. That would mean that Scrum is structured to address complex problems what many possible solutions are present.
The Scrum Team’s job, led by the Product Owner and guided by the Scrum Master, is to arrive at the best approach for their product. Who knows, maybe the whole team or organization will participate in this definition of their culture.
Read about Spotify and Salesforce.com.
More examples of confusion around this line in the Scrum Guide:
Dennis makes a good point, maybe the word "guide" is not necessarily the best word. Maybe something like "...responsible for providing vision to the..."Charles Bradley shared this idea ·
It's really hard to go against the Scrum Co-Creator on something, so let me try and understand... Given all of the millions of different contexts out there,how would one come up with an "optimal" time? I mean, isn't the point of the looser time boxes for the Scrum Teams to take more ownership of deciding what's too long or what's effective or not effective? Seems like we might be harming self organization here.
Then we’d have to track down everyone who downloaded it to ensure that they are complying, conforming to it.
Not our job.
Wow, great idea, Douglas.
Unfortunately I'm already low on votes, so can't vote for this one yet. It would also be cool if there was a logo/badge that said "Based on the 2013 Scrum Guide" or "Based on the latest Scrum Guide" or maybe just "See the up to date Scrum Guide at ScrumGuides.org"
More on why DoR is a double edged sword: http://stefanroock.wordpress.com/2012/08/04/definition-of-ready-a-double-edged-sword/
I do not think this should be part of the Scrum Guide. I think there is a danger in some teams to focus too much on overly specified requirements or for a DoR to become some sort of contract wall where someone can "throw requirements" over the wall.
So, while I think the DoR is a decent complementary practice to consider, the choice to have a DoR is one that involves tradeoffs. Because it is not universally applicable, it should not be in the Scrum Guide IMO.
Further, there is enough suggestion about "ready" and the Dev Team choosing which items to bring into the sprint (they could skip one that they deemed "not ready" -- and all of that without having a DoR contract), that I don't think we need anything more formal.
Further, because the DoD is VERY MUCH a contract, it is likely that the teams will implement DoR as a contract, and I think that leads us back to dysfunctional waterfall contract/wall/Product Marketing-Dev adversarial behaviors.
Count me in full opposition to this as an addition to the SG, but in full support of it as a complementary practice for people to choose to do in the contexts where it is necessary to continuously improve. I would expect a team to only need a DoR temporarily until the can eliminate the dysfunction that requires it.
Martin, because I know you, I get the eery feeling that you should have posted this on April 1 instead of Feb 19. Am I right in that?
Consider me adamantly against this idea.
Those are interesting guidelines. Based on where we are in creating a product, the skills and background of the team members, and the response of the customers/users, you will find this ratio shifting all over the place. Adjustments occur as the context demands.
Unless you want a methodology, then we can pour concrete on ratios.
I am a huge fan of both Martin and Richard! Definitely two of the top Scrum Trainers in the world!
However, gentlemen, I am not in favor of this idea. I personally think the flexibility here helps with 2 things:
1. It forces the Scrum Team to inspect and adapt on how much time they think is sufficient, because there is a looser time-box.
2. In large scaled implementations of Scrum, the extra time might be needed due to the communication needs of several teams to coordinate during their Scrum Events. I think having some more flex in the time-boxes helps accommodate this scaling need.
See my comment. Ken
I'm not comfortable making it an event because in really healthy co-located teams, it need not be an event -- it can happen informally and organically. I like that it is a required activity with a time-box, without it being an official event.