My development team is working to the Scrum methodolody, pretty much. We have a prioritised product backlog, which we break down into sprints tracked by a burndown chart.
Trouble is, the product managers (who gather requirements from the stakeholders) will give us an outline of the requirements, say a few days before the start of a sprint, or set of sprints.
We then have a look through them, revise them with what is feasible (technically and within reasonable time). This gets sent off for review by management, other product manages and stakeholders, and usually revised/tweaked further, which tends to go on in a circle until it has all settled down.
Meanwhile, the sprint start date is upon us and we start grabbing at the requirements we are pretty sure are stable. Once those are done we are left with endless days of tweaking the code as the requirements shift around slightly.
While I'm aware that requirements shouldn't be considered fixed, I just feel like we are managing this badly, and trying to fit a waterfall requirements approach into agile development.
Does anyone have any improvement suggestions or experience of this kind of issue?
Edit: This is probably a worst case scenario for us - sometimes the requirements are pretty stable and we actually use Scrum properly! However, more frequently we are seeing the above scenario in our sprints, which is why I have asked the question. I know that the above is not really proper Scrum, that is sort-of the issue :)
Bring your stakeholders to the scrums; invovling them will elimate any "chinese whispers" through the product managers. Also it is they that need to prioritise the back log not the developers. When the stakeholders are at the scrums they also see the ramifications of change better and whilst they won't stop making changes, they will have a better concept of how their changes effect the iteration.
On changing requirements; see the Agile Manifesto ... "Embrace change!"
Kindness,
Dan