A discussion I started on Linked:
Breaking Scrum: Scope changes within the sprint...
Hi,
Looking a "list of reasons" on why product-owner-pushed scope change during the sprint breaks scrum...
Few I can think of (please add):
- Takes away the focus from the current functionality
- Reduces team ownership
- Impacts Quality
- Impacts Velocity
- Impacts sustenance of Scrum
- .......
Thanks!
Rahul
3 months ago
Prasanna Raghavendra • The basic essense of agile to me is getting joy in the journey (see here: http://2srp.blogspot.com/2010/06/joy-of-journey.html). One should be successful in the small steps to make sure there is continuous passion and teaming, If this fails, everything breaks!
Mike Caddell • A scope change during a sprint - which is a contradiction in terms - invalidates the fundamental agreement and commitment that bounds a Scrum iteration. The team commits to complete a set of functionality as prioritized by the Product Owner and agreed to by the team. The Product Owner in turn commits to helping define and elaborate the agreed on scope in a timely manner to enable the team to do it's work; and only the agreed on scope, nothing else unless the team finishes early and then picks the next highest priority Release Backlog item.
If the team is asked/required to accomplish a different scope of work during the sprint, the mutual commitment to the previously agreed to scope is thus invalidated. At this point, the sprint should be terminated and a new sprint with the new scope begun - starting with Backlog Grooming and Sprint Planning.
Julie Hendry • I agree Mike, although it often depends on what is meant by 'scope change' - is is the overall deliverable or is it simply that we discover more detail?
I've seen successful teams accept some changes within scrum as long as the changes are agree and communicated, and do not change the underlying goal of that sprint.
Rahul Sawhney • Thanks all for comments.
@Julie, To clarify I mean "goal changing" and "deliverable changing" sort of changes. I do not mean discovery of some more details.
Mike Caddell • @Julie - a great clarification!
I meant as Rahul indicates, a change in the objective or the actual content.
As this discussion clearly illustrates conversation almost always illuminates more detail - which is why we value Individuals and Interactions more than Process and Tools!
Derek Neighbors • Is the reason why they do? or the reason why they shouldn't be allowed to?
The reason they do... the team allows them. The don't enforce some penalty in breaking the contract.
The reason they shouldn't be allowed to. A key premise of agile resolves around trust. Changing course mid sprint breaks trust and deteriorates the relationship.
Prasanna Raghavendra • I am seeing this discussion going similar to building a stringent chinese wall between the product owners and the team and closing doors on genuine yet possible changes within iterations. Like I mentioned earlier (brewity killed clarity in my earlier note, I guess!), the focus should be on small but quick win at the end every iteration for the entire team (including product owners). That would mean there should be constant communication and acceptability of what can be done for the changes coming-in while appreciating concerns from both end. A "genuine" change coming in within an iteration should be discussed and accepted when possible while showcasing what it means for the dev teams to pick it up. This is when teaming and binding becomes stronger. Product owners should also have strong reasons why the change envisaged cannot wait until the next iteration.
I would discourage a generic and rigid process coming in the way of teaming. Agile is not a process but it is a set of natural tendancies teams follow to bond, and that should take precendence. it is interesting to note that we are losing our this natural behaviour and find it hard to let those take precendence.
Rahul Sawhney • @Prassana - I agree with you completely.
Just to bring the discussion back towards my question, refining it a bit....
What are the after-effects (short term and long term) of having the "sprint-goal changing" scope changes, which would take the focus away from the team to deliver what they committed?
So far, we have seen some points indicated above, would like to learn more perspectives, experiences when this happened etc..
Jeff Smathers, CSM • Rahul, If I understand your question, I think that Derek and Mike have great answers. I will try to summarize for my own benefit. If the scope change is so large it changes the sprint goal then the team cannot meet its commitments and the sprint is no longer valid and should be ended. A new sprint needs to be planned and started to address the changes. Depending on the maturity of the team, the trust between members and the quality of their relationships could suffer. Keeping to the commitments defined by the sprint goal is very important.
Jason Little • I wouldn't worry so much about the after-effects as I would in trying to figure out why the scope keeps changing every sprint.
Some context would be helpful. Is this team supporting an existing product? Are the interruptions due to customer complaints or support issues? If so, Scrum doesn't work well in that situation.
Is the PO having problems grooming the backlog to get stuff ready for the sprint? Is there a lack of overall product direction? Are different stakeholders pushing conflicting priorities?
A sprint being constantly interrupted is often the symptom of a deeper problem. Focusing on Scrum as dogma isn't going to solve the problem and you'll end up creating more dysfunction and trust issues between the team and the PO.
John Clifford • In Scrum, the team's commitment to accomplish the items on the sprint backlog that starts the sprint is matched by the Product Owner's commitment to observe and respect that commitment by not trying to change the agreed-upon scope for the duration of the sprint. One can't work without the other. I would argue that a Product Owner who continually wants to change scope during the sprint isn't following the Scrum process and doesn't respect the team or their commitment. In my experience, this happens because the Product Owner fails to take ownership of the product backlog; either he procrastinates on prioritization until the last moment and then overlooks stakeholder commitments that drive prioritization needs, and/or fails to take responsibility for ensuring backlog items are groomed and prepared prior to sprint planning.
Not having objective, quantitative, and binary acceptance criteria for sprint backlog items is one of the problems leading to scope change; if the team has no defined criteria for the complete story then what is to stop the Product Owner from whipsawing them around? Therefore, the Product Owner should ensure that sufficiently-defined acceptance criteria exists for all stories that she will bring to the sprint planning meeting... and the team should refuse to consider any item lacking this. This isn't to say that the team and the Product Owner should be at each others' throats, but instead to say the team may need to spend some time during the sprint planning meeting working with the Product Owner to create sufficiently-defined acceptance criteria.
(Product backlog items with valid acceptance criteria and that have been estimated are often referred to as 'Ready-Ready', in the way that sprint backlog items that are completed according to the Definition of Done and all acceptance criteria are referred to as 'Done-Done-Done-Done.' Effective Product Owners always have at least one sprint's worth of backlog items in a 'Ready-Ready' state before the start of a sprint planning meeting.)
I'm a huge believer in not hiding dysfunction, because you can't fix it if you refuse to see it. In the above situation, the sprint planning meeting timebox will most likely end with only one or two items that have valid acceptance criteria; so be it. The Product Owner will need to accept that bandwidth may need to be reserved during the sprint to work on additional items' acceptance criteria in order to be ready for the next sprint; if the team finishes with the committed items early, they can either drag additional items into the sprint or end the sprint early and re-plan/re-launch. At any rate, this should be discussed at the sprint retrospective and a solution devised that will prevent this from happening again should be implemented.
As others have mentioned, if the team believes that an item's scope has changed to the extent that the original commitment is invalidated, then they have the authority to reject the changes and not complete the item... and this should be discussed at the retrospective. Or, if the Product Owner really wants to change scope, e.g., substitute a new sprint backlog item for an existing one, even if the item estimates are identical, then the team has the authority to accept or reject the change, to the extent of cancelling the sprint and re-planning. Again, to expose dysfunction, I counsel against accepting ANY sprint backlog changes, not to be a jerk or uncooperative, but in order to force the issue to the surface... Product Owners who continually fail to prioritize and want another bite at the apple, for whatever reason, are a common issue.
Andy Dent • A few thoughts on this, against a background of multiple scrum teams collaborating internationally, spanning 24 hour time differences. We have architectural separation of much of the work but that translates into one team having the other two as customers.
We could take the bloody-minded approach of just saying "no" but that risks some bugs being blockers to another team for an entire sprint.
An alternative is for the team to identify one or two people as responders to handle urgent cross-team requests. They can have a task allocated in the sprint which is basically a budget of their time, to be whittled down over the course of the sprint and leaving them free to do other tasks of moderate size.
When it comes to tasks being inserted into the sprint, another pet idea of mine is to mandate that tasks with twice the number of story points have to be removed.
This reflects the loss of velocity from something unplanned being included and emphasises the seriousness of the interruption to the product owner. I'd love to know if anyone applies this, how they get on!
Raul Xavier Neto • I´ve got a little intrigued with that many arguments being so dogmatic about scrum. I think that one of the best points of agile (in this case, scrum) is to help teams cope with change. Change that is a big reality on every software project.
I´ll go with Jason and Prasanna telling you that the best thing for your team is to find out why the owner is changing that much and try to bring him to the team, where those changes should be agreed by the team with good discussion.
Speaking of dogmas, maybe the initial phase is too dark in the owner´s head, maybe the team is not sure about the concept or something else. To ease that kind of thing, that usually comes in the beginning of the project, you can try to reduce the sprint duration, bring the owner closer to the team, try different approaches to put the team as one peace. Scrum is not a Religion, it only guides teams to achieve good results, but the principles are the important thing, not the "rules". If you have to, adjust the "rules" to your needs.
Prasanna Raghavendra • @ Raul, @Jason: Bingo!
@Rahul: It is less about worrying about after effects than accepting it as another pragmatic anamoly and see why it occurs and how it can be fixed.
Rahul Sawhney • Thanks John - I enjoyed reading what you have written here.
Thanks to everyone else too - great insight!
Cuan Mulligan • @Rahul, the impact for me is one of cost.
for example, lets say the PO has aprpoval to spend $x on the delivery of a project. It is the role of the PO to ensure the best spend of the companies money.
If the PO keeps changing their mind, this will consume time (cost) and reduce the teams ability to deliver the project benifit for the agreed amount of money.
If the changes are small , ie refeinments, then this should not be an issue. However I have worked with PO, who make quite dramatic changes during a sprint, and then wonder why the project did not deliver. The upside was that they learnt a valuable lesson, and stopped this behaviour.
Gail E. Harris • The fundamental question in this discussion thread is about product-owner driven scope changes during a sprint breaking Scrum. Well, as someone else wrote, Agile approaches like Scrum are all about being agile, and, as it turns out, changing the scope during the sprint doesn't break Scrum at all.
In Ken Schwaber's book "Agile Project Management with Scrum" he describes exactly how to handle this. He says that "management could abnormally terminate the Sprint" at which point there would be a new Sprint planning meeting. Ken further notes that this new planning meeting would make the action highly visible and thus hopefully product owners would not make a habit of it.
It's also worthwhile to note that a new opportunity to change the scope is never more than four weeks away. Once they realize this many product owner's find that four weeks from now is more than soon enough.
Griffin Jones • We have a very small team, working in a start-up.
Priorities change.
When targets-of-opportunity appear, ownership will pause the sprint as we deal with the new higher priority. The owner makes the informed choice.
Long pauses force a clean re-plan of the sprint. Too much switching reduces velocity. But the owner values responsiveness from development, and is willing to accept reduced velocity in exchange.
Rahul Sawhney • @Cuan,Gail and Griffin, Thanks I was looking for exactly these inputs!
I do believe that this does not break Scrum as a framework. When Scrum is done incorrectly, (i.e. when PO makes significant changes without agreeing with the team and does not allow terminating or pausing the sprint, and does so regularly), the team gets demotivated and starts falling apart. And as Cuan mentioned, not learning from experience escalates costs and reduces team's ability to deliver and impacts collaboration.
To begin with, requirements are understood at a very high level and thereafter, the rest of the planning is driven by priority. As a rule, lesser time is spent on figuring out the details of those requirements that do not have a very high priority. High priority bigger requirements are split into smaller ones so that details can be explored. Only relative size estimates (at a high level) are done at this point to get an idea of how "big" the work is. Once the work is quantified, tasks and effort are estimated for the highest priority requirements. That gives an idea of how much the Team can deliver in a Sprint. This idea is tested in the first Sprint and gives the Team a better understanding of its Velocity (or the size it can deliver in one Sprint). Using the Velocity, the Team is now in a better position to give commitments for later sprints.
As the project gets underway and the Team executes multiple sprints, the Team has better visibility on the customer needs. Likewise, the customer also understands the requirements better. This understanding results in evolution of the Product Backlog (e.g. changes in functionality and scope, priority).
As the Product Backlog evolves, the size estimates are done for newly added requirements. The Product burndown chart shows how much work is remaining based on the revised scope in the Product Backlog. The work remaining is controlled usually by removing some low priority requirements (of size equal to the added requirements) from the scope. This ensures that scope is managed continuously based on highest priority requirements.
Adapting the plan in this manner helps in providing better visibility to all stakeholders by tackling many important issues, such as: