Re: [scrumdevelopment] Question on Scrum Guide 2011 statement
- In the Scrum Guide (2011)...It's a bit ambiguous in the guide -- it kind of reads as if the PO can introduce new scope mid sprint. The Sprint Goal is a very ambiguous concept as well, so it's really hard to tell if one is "affecting" the Sprint Goal, and it's not clear who decides whether one is affecting the Sprint Goal. What if the PO and Dev team disagree on the Sprint Goal or whether new scope "affects the Sprint Goal"?People on this list will tell you their opinion of what it means(including me), but because it's ambiguous, it can be interpreted in several reasonable ways. You can consult secondary sources on this, and many of them will tell you that Scope is fixed within a Sprint, but that's not exactly what the Scrum Guide says. In fact, this "scope is in concrete" mentality was a common misconception in the earlier years of Scrum(so much so that an "optional tip" attempting to clarify was introduced into the guide).Here is what I think the Scrum Guide means here.As more is learned about the current Sprint scope, the Dev Team and PO may decided to renegotiate the forecast of how many product backlog items can be completed within the Sprint. As such, the Scrum Team may decide to take on more items, or they may decide to take on fewer items, based on new knowledge gained after the Sprint began.In My Coaching Experiences...In my coaching experiences, most of the teams I have coached have had trouble coming up with and applying the Sprint Goal concept -- partly because much of their work is heterogeneous (new features, maintenance, multiple themes occurring at once, a product that is wide in scope, etc). It's really hard for them to pin down a statement that describes what they are trying to accomplish when the work is so heterogeneous. As such, they generally devolve to a generic Sprint Goal like "Our Sprint Goal is to get as many backlog items to 'done' as possible during the Sprint, while maintaining a sustainable pace."As for the scope issue, I generally think that the SM should try to protect the team from too much spontaneous scope change or scope clarification, but should always encourage the team to get scope and backlog item clarification, and should also encourage the team to handle small amounts of scope change or scope clarification well. By scope clarification here, I mean clarification of the product backlog items.-------
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
My blog: http://scrumcrazy.wordpress.com/
From: solutionbuilder <greg_della-croce@...>
Sent: Wednesday, August 17, 2011 9:18 AM
Subject: [scrumdevelopment] Question on Scrum Guide 2011 statement
In the Section on Sprints the guide states that "Scope may be clairified and re-negotiated between the Product Owner and the Development Team as more is learned"
What is the guide trying to say? Is this Scope creep within the sprint? How does this fit with the "no changes are made that would affect the Sprint Goal" (which I assume includes "Done")?
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: