Dealing with large specifications with Scrum

Question

From time to time, our product need to cope with new network protocols that comes in large specification files (~100+ pages). Usually, gathering the requirements from the specification can't be done by only one person, because it's large and prone to errors. On the other side, the development team feels demotivated doing this kind of analysis.

Given that, what are the alternatives to gather requirements from large specification files with Scrum? Should the PM take care of it with a specification team? Or the development team should be more suitable for this kind of task? The specification analysis should be time boxed into the sprint or it comes before Scrum can be applied?

Answer 1

Given that, what are the alternatives to gather requirements from large specification files with Scrum?

I'm afraid that there isn't any. It is either the Product Owner, the Scrum Team, or them together. Another option might be to hire an expert how can help out with the processing of the documentation.

Should the PM take care of it with a specification team?

By default yes, but in case of a large amount of complex work it is good when the Product Owner cooperates with the Scrum Team.

Or the development team should be more suitable for this kind of task?

I would say, yes. It seems that you have to do this kind of work on a regular basis. I assume these large specifications are vital to your business, which means that somebody has to do it. If the Product Owner is not enough than the team should help out. Maybe you can compensate the boring part with some "fedex day" like activities such as team members can pick what they'll do during a day.

The specification analysis should be time boxed into the sprint or it comes before Scrum can be applied?

If it is possible, this is the best solution. You can iteratively process the document and implement the features. If you have a backlog (user stories) for 2-3 Sprints ahead it is fine, and actually it is the best, because you don't create too much waste by defining user stories which may not be implemented.

In other words, it is not mandatory to process the whole requirement specification before starting the project. You create just enough user stories so that the team(s) can start to work and while they are working, the Product Owner continues the processing of the large requirement file, and puts the new user stories into the backlog.

Answer 2

I'd like to address the "demotivating" part of your problem. The most effective tool I have found for addressing these kinds of problems is to break up the time that developers spend doing non-development activity. Funny thing about programmers: most of them only want to program. They don't want to do doc. They certainly don't want to do QA. And most of them aren't interested in doing requirements.

But in cases where there is a lot of material that needs to be processed for requirements, it is a lot more palatable to the developers if they are doing it in chunks. This may or may not work with the 100-page doc that gets dropped on you. It could be that you are required to go thru all of it and provide time estimates to management as soon as possible. In that case, there's not much you can do.

And see if you can work with the team providing these document drops to you. If you tell them that you are trying to break things up to make life more bearable on your developers, they may be able to structure the document a little differently to support your efforts.

Also, try the XP "pairing" approach to this problem. Pairing takes two medium programmers and turns them into a single better programmer. A lot of times people don't like doing something because they feel like they aren't good at it or are unsure of themselves. If you pair the developers up to chew on various pieces of the requirements doc, they will self-organize and optimize for their own strengths and weaknesses. It might introduce a little competition and energy into an otherwise dreary process.

Answer 3

It depends on who is available to you, of course, but I think it is a good experience for the developers to do this. As this analysis happens, they will hopefully be contemplating design, and will ultimately come up with a better design. I agree it may need to be done in smaller batches if possible, to avoid burn-out and attention drift.

I've been a developer for more than 25 years, and I have little tolerance for developers who "only want to do code". Of course, I come from a small company environment where it is necessary to wear different hats. In my experience, it's always beneficial to sample different roles, so you can see the work from a different perspective.

Having said that, the Product Owner should at least confirm the level of suport for the spec (if there are variations).