Is it valid\accepted to change the scope in the middle of the sprint ?
As the title implies , here is the scenario .
In the middle of a 10 days sprint , in the 7th day , we received major changes in the graphic design of all the user stories . Major changes that require reworking all the UI effort we made from first day and until this day .
When we escalated this matter , we have been told that "This is what Agile for . Agile exist to address such situations" . Is that really true ?
Agile practice wise , is it valid\accepted to change the scope in the middle of the sprint ?
And should the team commit to finish such changes by the end of the sprint ?
Here are my believes , I believe that the whole point of the sprint being short is that new work and changes can be added to the next sprint without affecting the overall project timeline.
Thanks in advance :) .
> in the 7th day , we received major changes in
> the graphic design of all the user stories
Where from? Are there people engaged in design for this work who aren't Development Team members?
From Egypt .
People engaged in design (Graphic Design) belong to the creative team not development team .
Actually the creative team is a separate unit providing services to all the development teams across the organization .
It sounds as though you don't have a Development Team which is capable of forecasting and actioning its own work. That's a fundamental requirement in Scrum.
I suggest you have a read of the Scrum Guide and pay close attention to the roles and their responsibilities. You need an appropriately skilled Development Team in place before anything is said about scope or timelines or commitments.
Thanks a lot Ian for your response and interest . Highly appreciated .
Forget about this particular scenario . let's say that we received major changes in the business requirements of those user stories . What about that ?
Who is your product owner? How strong are they with their understanding of Scrum ?
Any work being offered to the team mustcome from the Product Owner. Your Scrum Master needs to work to protect the team from outside interference and anything that may jeopardize the sprint goal. Even if they are unsuccessful, they must make these actions and effects visible and transparent to the rest of the organization. Every time, no exceptions.
If your organization truly believes that being "Agile" supports context-switching and ignoring the sprint time box, then unfortunately they have a poor understanding of Agile/Scrum.
I get asked this question a lot, so here is my answer:
http://www.scrumcrazy.com/scope
The one thing I probably didn't include in the chart above but probably should have is.... "Does this change jeopardize the Sprint Goal?" If it does jeopardize, then this is a clear violation of Scrum. OTOH, one can make the Sprint Goal so loose and vague that it could be "Put a daily focus on the work that the PO tells us too"
Hi,
I have a scenario here and request your suggestions. Our Sprint is 10 days duration. On the 7th day of sprint, the business requirement impacting multiple user stories are changed. Since this is almost after the mid of sprint and the PO feels that these user stories (entire user story with complete scope and estimations as it is) has to be moved to next sprint. Is this the correct time during the mid of the sprint to move the user stories to next sprint? Or should be done at end of sprint since this is impacting the sprint goal, burnup chart etc ? Another query is that will it be a good idea to split the user story with completed tasks and new user story with pending tasks. The user story with completed tasks should be accepted by PO in current sprint and new user story with pending tasks with new estimations has to be moved to next sprint. Please suggest.
Does the Sprint Goal remain intact in this situation, and does the replanning of work on the Sprint Backlog allow it to be better met?
No the Sprint Goal has also changed as the business need changed. Yes the re planning of work on Sprint backlog makes it better as more details are specified along with the current scope.
What does the Scrum Guide say about the Sprint Goal and what should happen if it is no longer achievable?
Sorry Ian. I was stuck with Sprint Closure and Sprint planning for next sprint.
Thanks for your quick responses.
I know, there shouldn’t be any changes that will endanger the Sprint Goal and sprint would be cancelled.
When the sprint is cancelled, done work is review and in completed work is re-estimated and put back to product backlog.
My query was about at what stage we can move the user stories to next sprint.
Anyways accidently I had look at forum “Undone Work in a Sprint” and got the answer.
Thanks again for the responses.
Ok try this one on the 6th day the development team discovers some tech debt that they must resolve meaning the sprint goal is or could be unachievable... Now what?
1. Sprint could be cancelled and refined tickets put into backlog.
2. P.O. Could agree with dev team to try achieve the original goal (assuming Scrum team feels the extra work will not inhibit capabilities in next sprint), but does this break the rules... Technically the same sprint goal but also scope creep?
3. Any other valid options?
Also as an alternative... How would you address this in Nexus scenario?
4. Renegotiate some of the scope with the P.O. removing items to accommodate the new
What is the difference between scope creep and scope change in agile? And depending on that if someone can please help in understanding below -
1- If any new user story is pulled during sprint provided current committed stories are completed and team has capacity, will new pulled user story be a scope creep or scope change?
2- If a highest priority item gets pulled in during sprint and we need to prioritise between current work of sprint and bug then will that be scope creep or scope change?
To answer either of your questions, we would need to know the Sprint Goal. The Sprint Goal identifies the reason for executing a Sprint. It focuses the Scrum Team on what work is most important to complete. Does every item in the Sprint Backlog have to support the Sprint Goal? No. There could be items in the Sprint Backlog that are needed in order to do future work (such as buying down technical debt by upgrading a backend component to a newer release). There could be defects that are needed to be fixed in order to improve the Product. There could be some exploratory worked needed to refine items that are still in the Product Backlog. Any of that work can come and go from the Sprint Backlog without too much importance. However, anything that impacts the ability to meet the Sprint Goal needs to be discussed among the Product Owner and Developers to identify the best solution going forward.