I am in the middle of an agile sprint. Midway we realize that the requirement that we were working upon, could have been done in an easier fashion in a totally different way. The development work done on the current requirement wont be needed at all or needs to be changed totally. How is this handled in Agile? Even if we do communicate timeline and impact changes what is the formal method of handling this.

  • 5
    Your question seems to mention changing requirements but then also mentions how the implementation looks. In an agile world, the requirements specify the why and the what, not the how. It's up to the tech team to decide on the implementation. You should find out why and what is changing about the specifications after the sprint and then decide how to get some value out of the work already done. – RibaldEddie Jun 26 '15 at 5:00
  • 1
    @RibaldEddie: in theory - yes. In practice: its perfectly natural that when during implementation of a feature you note that the written down requirements may not be the best and simplest solution for what the user really wants. So the distinction is not always clear, these things are sometimes interwoven. Especially when designing GUIs. – Doc Brown Jun 26 '15 at 9:20
  • Does the change jeopardize your ability to meet the sprint deadline, and if so, is it possible to still meet the deadline by dropping one or more stories from the sprint? – rob Jul 10 '15 at 4:14
  • @tuffkins20, Did you find any useful help here? How did you end up dealing with the situation? – David Jul 13 '15 at 23:22

Generally, the product owner would create a new story that describe new requirements and you would estimate and prioritize the new story as any other story.

|improve this answer|||||

If you are faced with the work needing to be re-done, you re-do it.

Re-doing the implementation of a product backlog item does not necessarily require any user story to be re-written. The motivation to re-do the implementation may not have had anything to do with a change in the user story.

Re-doing some implementation also does not necessarily require a sprint to be cancelled. Sprint-cancellation should be rare. Scrum teams do not always accomplish everything that they set out to accomplish in a sprint.

Scrum does not aim to minimise effort. Scrum aims to produce high quality increments of a deliverable solution. If you use Scrum, you accept that sometimes "re-work" will be necessary. If you want to aim for minimised effort and re-work, you might adopt a different method.

|improve this answer|||||

(I assume, you do not mean "in Agile", but more specifically "in Scrum" - otherwise asking for "what is the formal method" does not make much sense).

If the change is so essential that the work on the sprint, as it was planned, becomes nonsensical, the product owner should cancel the current sprint and initiate a new one (see, for example, here). Of course, he should dicuss the issue with the team first.

This is hopefully a situation which does not occur too frequently in your team.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.