I have been in several projects before as a frontend developer when the requirements of the project change in the middle of the sprint. I want to be like "agile" and accommodating to change and flexbile, but I think this can be very hard on a front end developer and also extremely unfair because the front end developer is the last point in the process of developing a product because they are making things look right, and also connect it to the backend so the product will actually work. I think this is confusing for project leaders and customers, because often seemingly large changes are actually the most easy changes to get done, but then the seemingly minor ones takes days if not weeks to implement fully. Anyway because of the nature of agile projects and also the reality of working as a front end developer. I am wondering. Is it ok and normal for a project to make changes in the middle of the sprint and expect the same deadlines?
-
I don't know why someone downvoted this - it's a legit question in my opinion.– Stephan WeinholdCommented Apr 30, 2018 at 5:30
3 Answers
The Scrum Guide says:
During the Sprint:
No changes are made that would endanger the Sprint Goal
Quality goals do not decrease
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
What this is saying is that reasonable changes may be made. If excessive changes are introduced then it is up to the Product Owner to decide if the sprint should continue or be ended early.
It is worth noting that excessive changes mid-sprint have a number of disadvantages including:
- They make forecasting difficult
- They can introduce waste as a result of the team having to re-plan
- They may create confusion and reduce transparency
-
1Thanks for pulling the Scrum Guide verbiage on this. If you'll excuse me tacking on, I wanted to highlight the word "re-negotiate". That seems to be forgotten too many times.– DanielCommented Apr 30, 2018 at 14:00
I realize that the answer below may not have directly answered your question. I'm going to leave it because, well, I'm a dummy, and there's no sense in hiding that.
The answer is, "Yes, requirements can change in the middle of a sprint, and they frequently will."
In the industry in which I currently work, requirements often change mid-sprint due to natural disasters, regulatory changes, vendor changes, system outages, and all sorts of weird goings-on. These things are outside your control (external factors) and you cannot predict when they will occur. But you have to handle them as they arise.
The requirements will change, tasks will be deprioritized in favor of other tasks and your sprint and product backlogs will change. This is where Agile beats the pants off of Waterfall.
Yes, your developers will pull their hair out. So will you. But you'll save money on haircuts.
Agile expects constantly changing requirements.
However, having said that, the team leadership can push back against the customer and make it clear that some of their expectations are unreasonable.
At the start of the sprint, the expectations were clear, and the team presumably negotiated with the customer for a fixed set of deliverables. Barring an extraordinary set of circumstances (natural disaster, regulatory changes, legal obligations, etc.), they committed to those deliverables and anything else should go into a future sprint.
Talk to the customer. Negotiate. Communication is key. In a worst case scenario, and they insist on the new functionality, they'll have to move other items on the sprint backlog into a future sprint to make room for the desired features. It's all about priorities at that point.
With any luck, you'll have a retrospective, and you can include this as a pain point and learn from it.
-
I think that is well said ... I will also just add. While I understand agile, and I think it is superior to waterfall no issues there. I think this philosophy can be abused, and it really comes down on front end developers hard. Because basically as a project leader it can be a license to not have a plan and whimisically order stuff. And as mentioned the front end developer is the last point in product development, so it hits them hard when deadlines have to be reached. It can be really unfair for them.– DanCommented Apr 29, 2018 at 18:02
-
Another aspect is that today the front end of websites can be build extremely quickly and to a high standard. But that really depends on the overall planning of the project. The reason for this is the modern component architecture of javascript frameworks. If a developer has like a perfect idea of what he/she will do over the next few weeks, they can leverage the power of these frameworks and deliver great products built with great code. If there is disorganisation, I would say the length of time can increase several times due to the difficulty of reusing code and maintaining good structure.– DanCommented Apr 30, 2018 at 6:59
To me that's one of the many points in Scrum where it's more about instinct and balance than about rules. On the one hand the customer value is important and you don't want to waste time following a wrong path. On the other hand one want to shield the team from distractions and disturbance. So I'd have a look at four factors:
- Is this an exception or is this happening every sprint? If this is common, your Scrum Master should have a long talk with your Product Owner.
- Are we talking about small change requests? Or are we talking about changing acceptance critereas? A big change will alter the goal of a user story and thus should result in a new user story. My two cents.
- Is there a policy in your organisation how change requests should be handled?
- And finally: in my experience it depends a lot on the length of your sprints. Are we talking about two weeks each? Then maybe ask your Product Owner to write a new user story. Are we talking about eight weeks? Then small changes should be acceptable. But again, for me this is a lot about tact. Talk with the team, your Scrum Master and/or your Product Owner if you feel uncomfortable.
