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

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

Answer 2

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 3

"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."

Please do not call that an Agile method or scrum.

That's just craziness.

If you're tweaking things after the sprint starts, you're not doing it right.

You're enabling (indeed, your encouraging) bad behavior. If they can't get the requirements before the sprint starts, you have two choices.

1. Wait. Nothing wrong with this. It's cheaper in the long run.

2. Start. However. Since the requirements are fixed for the duration of the sprint, you have to finish the sprint with no "tweaking". Changes become part of the backlog.

   • You can do shorter sprints.

   • You can simply backlog the tweaks until they get the idea that they're causing their own problems.

Also, a lot of management review is not very Agile. It's not per se wrong. But it indicates a lack of trust. Agile means collaboration and interaction between developers and product owners. It doesn't mean another layer of management review.

Answer 4

We have someone in the team that is in charge of fixing the requirements on behalf of the Product owner. Sometimes we have just-in-time requirements, sometimes, we have some rework to do. QA accepts the requirements are reviewed formally in the latest sprints of the release.

The team should only commit for tasks that are clearly defined by the Product Owner, otherwise they cannot be estimated. Perhaps you could shorten your iteration so that only stable requirements can be planned ?

If your process mandates this review cycle, then perhaps you can restrict your sprintable items to those approved by the product manager/management/stakeholder.

Answer 5

It looks like nobody is really owning the Product Backlog (i.e. you don't have a unique Product Owner) and it looks like the most important Product Backlog Items aren't in a ready state before each iteration. These are obvious major impediments, they need to be solved, your ScrumMaster should work on them.

Answer 6

I agree with the others; your Product Owner is non-existent. You really can't start a sprint until you have enough solid requirements to make a commitment, and your Product Owner agrees with that commitment. Once the commitment is made, neither party can change it within the context of Scrum unless you abandon the sprint and re-plan. Of course, you're not doing this.

I would further state that your Scrum Master is not following his or her responsibilities as Keeper of the Process. Why is he letting you start up a sprint when you don't have a valid product backlog to choose your sprint backlog items from? Do you even have a Scrum Master?

I understand that your team is just trying to get work done, but what is really happening is that you're enabling bad behavior on the part of the product managers, who don't need to have a backlog with well-defined user stories ready before the start of the sprint.

There's a reason that Scrum has a Scrum Master and a Product Owner, and requires agreement between the Product Owner and team on the sprint backlog before the sprint starts. Not having these assigned roles and not following the Scrum process causes things to break. Yes, it's easier to avoid the parts of Scrum that point out bad behavior, but you won't change bad behavior until it is acknowledged. Remember, the definition of insanity is doing the same thing over and over while expecting different results. You're going to have to change what you do if you want to change the results.