Welcome to the Simplilearn Community

Want to join the rest of our members? Sign up right away!

Sign Up

Requirement Change after Sprint Completion

Dear All,

I am facing a situation at my organization where the requirements, implemented during a certain Sprint have completely changed in the next one.
For e.g. we had certain Wire frames to be converted to HTML, having a very basic but defined structure. The team implemented the same and we had a good Demo on the same at the end of the Sprint.

Now while discussing the future requirement, there are changes mentioned by the Product Owner. These changes nullify the HTML conversions done in the past Sprint (total change in the layout) and will require the team to start afresh on the conversions. The past work done will be of no use and there is a total rework involved here.

Is this acceptable? OR should I (Scrum Master) be communicating to the Product Owner to freeze on the requirements and tell him that only a certain level of change in the requirement (which does affect the whole work done by the team in the last Sprint) will be allowed.

Please provide your valuable comments/ suggestions.

Thanks in advance.

Raj K(3066)

Well-Known Member
First things first: You as Scrum Master (as given in your text) trying to protect the team from "possible rework, disappointment of earlier work going waste" is wonderful. That is what is expected of Scrum Masters!

Now let us examine the issue deeper.
1. Agile is all about handling change in requirements. Therefore, communicating with Product Owner on freezing the requirements is a BIG NO. That is waterfall, isn't it? Brainstorm with the team to see what are the ways in which much of the rework can be eliminated. In one of a project where I am Agile Coach, for each iteration there were changes to Database tables and team was frustrated with rework. In Retrospect, I asked team to establish a goal to reduce database changes and thus eliminate rework. The team found best ways to handle database changes and in next sprint, the database changes became minimum or negligible. The goal was achieved.
2. Was there any "Definition of Done" for the work done by team in certain sprint agreed with Product Owner, which they met? If answer is Yes, then the team need not worry on their work going waste - from Agile process perspective. You have got velocity there for these stories. On the other hand if answer is No, then you need to sit with team and Product owner to ensure that clearly defined "Definition of Done" exists for future iterations.
3. Well from a psychological perspective, team's disappointment is understandable. But it is part and parcel of Agile. If the answer to 2nd question above was Yes, then team need not worry. In the retrospect, encourage the team and motivate them further by talking about achieved velocity. In a cricket match context, they are scoring runs, not playing maiden overs and increasing the run rate. Happy situation, isn't it?
4. Last but not least, Architecture evolves over iterations in agile. Keep that in mind also for future iterations.

Let me add something more from a Contract perspective:
If the Project is Fixed Bid and you are from a supplier i.e. vendor organization (most likely it would be), rework is definitely a worry. It is known across the world that Customers exploit Fixed Bid projects in Agile by keeping some scope volatile. Supplier finds never ending work coming. Review SoW or other relevant documents, get in touch with your account manager and see what best can be done.

Finally, the team should be happy to have you as Scrum Master. Way to go !