The word 'ready' is used exactly once in the Scrum Guide (both the 2013 and 2017 revisions).
And an important change was made in the 2017 revision of The Scrum Guide™. The word 'ready' was:
1) Capitalized, and
2) placed in quotes.
(Copied from the guide)
>Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.
Scrum, hence, now has a formal definition of the word 'ready'. All discussion about definitions of Ready (which are NOT the definition quoted above) therefore represent adaptations/deviations from Scrum.
I believe this issue is therefore 'closed', done, decided. Can a moderator of this forum please close the votes?
Less is more. *Not* including something called "Definition of Ready" is best for Scrum, in my opinion. (Is there a way to "Vote Down" an idea in Uservoice?)
I support this proposal. Upon reading the guide, it ought to be impossible that a reader reach the end and still ask these questions:
- "So, is the Product Owner *IN* the Scrum Team?"
- "At the end of the Sprint, the developers pass their work to the QA team, right?"
The guide currently uses the terms "Scrum Team" and "Scrum Development Team" in ways that cause misunderstanding (or, to be more polite, in ways which do not mitigate misunderstanding).
I like the sentence Bob has suggested: "A Scrum Team has a ScrumMaster, Product Owner and 3-9 other team members who have all the skills necessary to create a potentially releasable product increment every Sprint."
I do not support this proposal and don't believe it would have any positive benefit.
I don't understand how this item has received so many votes.
Please, NEVER make 'Backlog Refinement' an event. I fully appreciate that it's an informal and as-needed activity!
In every case that I've observed a team holds a meeting for backlog refinement, it's to overcome an organizational dysfunction such as:
- the stakeholders rarely speak or gather, so a meeting is created to bring them together. An optimal solution (rather than a meeting for backlog refinement) is to experiment with ways to bring them together more frequently, informally.
- people in "the team" aren't collocated, so a meeting is scheduled to bring them together. An optimal solution may be to experiment with ways to create discreet product mandates for each sub-team in their own geographic locations. (in other words, stop thinking they can work as a Scrum team!)
- or people cut the Sprint Planning and other Sprint events short (to an hour perhaps for a 2-week Sprint), so a meeting is created to enable decision-making and consultation about the backlog. A more optimal solution would be to use the Sprint Events more fully -- use the full 4-hours for Sprint Planning every 2-week Sprint (or full day! for 1-month Sprints) to enable effective planning and backlog refinement at an existing 'inspect-adapt' point in the Sprint. (Another positive benefit of the long/full Sprint Events is that stakeholders and team are challenged to actually spend significant time together! This is difficult at first - so people give up and shorten the events - but they can and should get good at such collaboration.)
No. Just no.
I don't agree.
It's difficult for me to understand why I feel such disagreement with the suggestion. Perhaps because RACI is, by definition, a way of predefining (and often segregating) delivery/implementation from decision-making and therefore the model is a barrier to self-organization. (This is an incomplete argument, I know, but I would not support the inclusion of RACI in the Scrum Guide nor in a Scrum environment.
I can agree to this. I can't think of any negative effects of this change.
The 'role' of Business Analyst is not part of a Scrum Team. Business analysis and some related skills are helpful, but the Scrum Guide explicitly states that Scrum Teams do not acknowledge the BA role.
See this line: "Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule"
The Sprint Goal is a phrase which represents the intent of the Scrum Team for a Sprint. It is a goal to which the team and its stakeholders commit to achieving together.
Unlike the artifacts of Scrum, the Sprint Goal is not to be 'inspected' or 'adapted'. It is to be 'set' and then used as a guide for the inspection/adaption throughout the Sprint.
I'd agree that the Sprint Goal can be made transparent or known to all involved, but to formalize it as an artifact in the Scrum Guide would (for me) change the concept dramatically -- the Sprint Goal, if described as an artifact, would become procedural rather than aspirational.
Regarding this line: "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."
In interpret that VERY literally -- the word 'participate' there (I think) means that the (only) Development Team members are sharing information. However, nothing about that sentence implies that others cannot observe.
Personally, I prefer #NoEstimates remain a protest and not formalized by removing the word from the Scrum Guide. It's a worthy cause and I support the movement. As a protest, it raises caution about the misuse of estimates. Estimates which are *not* misused, are extremely helpful while ordering a backlog.
For what it's worth, my personal stance on the matter is this:
- I'm pro estimates and pro #NoManagement.
- I'm pro #NoEstimates in environments with managers.
I respectfully disagree, Mr. Karakaya.
Formalized one-to-one meetings have no place in work environments in which teams are the performance unit. One-to-one discussion may take place and as team members interact naturally, but to make it "an event of Scrum" would undermine self-organization, fundamentally.
I'm on the fence about this. I can foresee good outcomes if DoD is called an artifact -- but it's more "an understanding" than "an artifact".