Gathering Requirements with Scrum [closed]

Question

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 :)

Answer 1

Yes. And this is important: Don't accept changes to stories after a sprint starts.

This will take much effort on behalf of scrum masters to tell the product owners that this is not permitted. The important thing to emphasise to them is that as developers you undertake to estimate and deliver the stories as specified, and any changes negates that effort.

In some cases the requirements legitimately change after a sprint starts. Here, consider aborting the sprint altogether. (That should get their attention.)

If your product owner finds that this is too inflexible, consider reducing the spring length. I've worked in a shop that used a sprint of one week, which I reckon to be the minimum, as the stories ended up being very small.

For more details see Agile Project Management with Scrum by Ken Schwaber.

Answer 2

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