10

Has anyone had this issue of a project defined as 'Agile' being overrun by requirement changes ? I work on a development project which is run in 4 weeks Sprint but there are always changes in between these Sprints . Is it still defined as Agile then ? I feel it's sort of a sub Agile process - The requirements of an Agile process should be defined at the beginning of a sprint and reviewed towards its end. Am I right in this? Please let me know your experiences in this .

Improve this question
4
  • "Requirements change" is a loose term. Is the change because the customer actually changed their mind about an approved requirement? What triggered that change? If this keeps happening then you need to re-examine how you collect requirements. No SE methodology could cater for lack of proper requirements gathering.
    – NoChance
    Dec 14, 2011 at 20:15
  • @Emmad The requirement changes happen during UAT when users feel that the usability could be improved by certain means . This causes a build up of issues pre production . This certainly is not Agile .
    – Aravind A
    Dec 15, 2011 at 4:53
  • @Aravind A: UAT happens at the end of the sprint, doesn't it? Then any new ideas/changes that come up during UAT should normally become stories for the next sprint (if you use sprints).
    – sleske
    Dec 15, 2011 at 8:16
  • Maybe what @sleske is suggesting works for you, but also, ease of usability can be prototyped in advance if the user has exceptional requirements. Sometimes, in projects bound by resources, you need to control your user ambitions.
    – NoChance
    Dec 15, 2011 at 8:27

5 Answers 5

Reset to default
9

The requirements of an Agile process should be defined at the beginning of a sprint and reviewed towards its . Am I right in this?

No, this depends on the nature of the project (and the process).

There are some agile development models where requirements are meant to be fixed during a sprint, and should only change for the next sprint (a prominent example is Scrum).

However, there are also processes where changes can happen almost any time (as long as the customer accepts the delays and the extra work which the change causes). Kanban is often used to manage these workflows (although Kanban can also be combined with Scrum).

Which model you follow depends on the details of each project.

So yes, if the customer feels they need the possibility of constantly changing the requirements, then an agile process can accommodate this. However, the customer should be aware of the consequences of constant changes, and should understand that they will slow down the project.

This boils down to the principles from the agile manifesto - "Individuals and interactions over processes and tools", and "Responding to change over following a plan".

Improve this answer
5
  • Does not not make the Process overtly Agile ? I mean , how far can the Agility go ? If a developer fulfills a requirement for the first time , there is bound to be a demand the next time . I feel this is one of the many issues which causes the code quality to be tossed over.
    – Aravind A
    Dec 14, 2011 at 12:08
  • @AravindA Code quality should be a seperate concern and regardless of how many times the code changes, the team should focus on the same code quality standards at all times. In fact, code quality is more important because requirements and code are changing constantly.
    – maple_shaft ♦
    Dec 14, 2011 at 12:34
  • 2
    @maple_shaft is right - quality is (at least mostly) orthagonal to the requirement change. Give me a req: I start writing good code. If I am done, and get a new req, or half-done and get a change, I start (re)writing good code. After having highlighted the impact to the current schedule/commitment/etc.
    – sdg
    Dec 14, 2011 at 13:49
  • Requirement changes that have large influence how the system is architected will result in major delays or quality compromises. That's why you should do some good old waterfall-ish analysis (can be also iterative) where you try to reduce risk of their "sudden" appearance.
    – MaR
    Dec 14, 2011 at 15:40
  • @sles Thanks for the explanation. I think I get it now . I think I'll have to get to know Agile more .
    – Aravind A
    Dec 15, 2011 at 5:02
12

I think the question you should be asking is: Why are you overrun by requirements changes? Common causes include:

  • The developers don't have (enough) contact with end users so they can't understand the users' needs. Instead they treat requirements like an abstract Rubik's cube - they follow the letters of the requirements without even trying to understand their spirit
  • Somebody (e.g. from marketing) is adding requirements that don't make any sense for the end user (but e.g. sound good on a brochure). So there's a battle between "real" requirements and "other" requirements that's fought on the backs of developers
  • The scope of the project is undefined ("Well, if you're implementing a word processor anyway, couldn't you just add a small module that does our payroll accounting? Oh, and Bill from the other development team asked how hard it would be to make the word processor compile C++ code, too?")

Whatever the root problem is, you need to fix that. Drowning it under layers of "Agile" (or any other methodology) won't work.

Improve this answer
1
  • @nike Thanks . This is Just what I thought . Your third point fits into my scenario . Some customers just take advantage of the work 'Agile' thinking it's a silver bullet to get work done faster .
    – Aravind A
    Dec 15, 2011 at 4:54
9

In Scrum at least, which seems to be the Agile process that's most popular with management types these days, the scope of a Sprint is fixed. If your Sprint Backlog is changing during the sprint, that's not Scrum, it's chaos. The Sprint Backlog should be created at the start of the sprint and remain fixed until the end of the sprint (at which point you create a new Sprint Backlog for the next sprint).

If your Product Backlog is changing during a sprint, it's no big deal. The changes just become new work that's prioritized, estimated, and selected like any other requirement for the next sprint. If the requirements change so much that the Product Owner has to cancel the sprint on a regular basis, though, you've got Trouble with a capital 'T'.

Maybe you need shorter sprints?

Improve this answer
2
  • +1 for needing shorter sprints. Scale back to 2 weeks and see if it helps.
    – John
    Dec 14, 2011 at 14:47
  • 1
    4 weeks does indeed sound quite long for a sprint, especially on a project that is suffering from requirement instability.
    – Carson63000
    Dec 15, 2011 at 3:14
7

For the sanity of the programmers it is best if requirements do not change during a revision/sprint.

In your situation, there are two obvious options:

  1. shorter sprints
  2. get the customer to agree not to alter the requirements during a revision/sprint unless the entire revision/sprint is cancelled and re-planned

I highly recommend both.

Improve this answer
3

The main problem is that you believe that you are using Scrum but you don't. Especially your product owner doesn't follow it. In Scrum a sprint is a safe zone and no changes to committed user stories can be made unless current sprint is canceled. It is responsibility of Scrum master to enforce this. If this doesn't work in your environment then it is a process problem = you are not using Scrum.

The simplest change you can do (if you want to follow Scrum) is make your sprint shorter - one week for example. 4 week sprints were considered as option in early days of Scrum but today common is 1 - 2 weeks and 3 weeks is considered as upper boundary. 4 weeks is very long time in changing environment.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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