Comprehensive single requirement docs vs. multiple atomic ones

Question

First of all, let me make it clear that I am a software developer and that I am writing this ISO help with my desire to agile-ize my project management and get a buy-in for changing some general requirements documentation technique that my team follows. Please do not confuse it with seeking people management advice, I am aware that is off topic on this forum.

I will try to make it simple and clear. When I was hired into my contract position a few months ago, I was told the team was following Agile but not all the way and that they were open to making further advancement towards it. Once started, I realized that the instilled workflow habits and procedures are still very much waterfall and that very comprehensive requirements documents are written sometimes several months before any development begins. By "comprehensive", I mean that, while a requirement does cover a coherent and interrelated functional unit, it is by no means atomic and that it can be further broken down into a hierarchy of individually atomic albeit interdependent units of work.

My hope was that each atomic, meaning not possible to further slice it into smaller chunks, unit of progress should have its own sprint/iteration and its own requirements document. From the development perspective, a clear advantage of this is that I don't have to grasp a wider requirements document, which leaves more focus on the direct task at hand, resulting in better quality work. It is like being handed two different tasks for installing a door and painting a room when the two can conveniently be split into two tasks: you first install the door, then you paint the room. In our current setup, it is a single requirements document, which makes it difficult to grasp or even find the specifics of the concrete task at hand in a document that encompasses other tasks as well.

I am asking this question to confirm that my idea does conform to the official Agile doctrine and that I am not misunderstanding. Should Agile requirements always be as minimal as possible or are there benefits to bundling multiple interdependent work tasks together into a comprehensive document? From the perspective of my cognitive styles and preferences, having the project management side of the team break down the work into individual atomic tasks would enable me to have to do less project management myself and actually focus more attention on coding rather than structuring increments towards the final objective. Another advantage is that it would be much easier to give LOE and completion estimates on a more narrowly scoped task than a whole project.

References:

Where is the Work Breakdown Structure (WBS) in Agile?

How do you convince a client to use Agile Methods?

Answer 1

It sounds like you might be describing the differences between a Product Backlog and a Sprint Backlog and perhaps a Release Backlog in the middle.

Product Backlog- Everything desired in the product. This can be a finite list (a PRD) or a living list that is constantly being added to and re-prioritized.

Release Backlog- This is not in the base scrum guidelines, however remember that scrum is a framework which can be customized. A common modification, particularly on large projects, is to break the project into "Releases". If the product is such that it can't be "shippable" every sprint (legacy code, deep integration to other systems, and so on). The "release" is then an interim milestone where the product would be potentially shippable. Releases will often have a core theme like "create core infrastructure". The Release Backlog is all the stories desired for a given release. Engineers would still decide in what order and how to build them.

Sprint Backlog- This is what the developers decide to build in a given sprint. They pull from the top of the backlog, but might not always pull the top item based on grouping like stories, technical dependency, etc. This should be done with the product owner (manager).

So based on your question, if you set up releases, you could then create Release Backlogs.

I'm not sure this is going to solve your problem though. From what you've described, it sounds like your requirements process is pretty far from agile. This pretty much neutralizes any benefits engineering has from operating in a sprint/iteration model. The best agile dev team in the world can't hit peak performance or deliver great value if they are getting garbage requirements or rigid requirements.

Answer 2

There is nothing in the agile approach that specifies the size of requirements. Scrum, which is an agile framework, does specify that the amount of work planned for a sprint should be completable within the sprint. That would imply a maximum size of a requirement such that it does not exceed a sprint (typically 1-4 weeks).

In practice though, there has been a lot of discussion in the agile community around an appropriate size for requirements when working in an agile way. Remember that one of the fundamentals of agile is the ability to respond to change. If you want to be able to respond to change, having comprehensive, coarse-grained requirements documentation becomes a hinderance rather than an advantage.

A popular approach to sizing requirements is the INVEST mnemonic. This stands for

• Independant,
• Negotiable,
• Valuable,
• Estimable,
• Scalable, and
• Testable.

The 'Scalable' refers to making the requirements small enough to be estimated with some certainty. A lot of agile teams take this to mean a typical size of a few person-days of effort.

You can read more about the INVEST mnemonic here

A further consideration is the agile principle of delivering working software frequently. This would suggest that smaller is better, as it would allow for more frequent delivery.

Answer 3

Agile requirements process is a conversation

Let me try to answer your question in the context of Scrum, which is the most popular Agile process.

Yes, you should have user stories in the form of small, vertical slices of functionality, describing a small increment in value to the user. However, reading your question, it looks like the following clarifications on the agile user story process will help:

1. User stories, as initially written by the Product Owner, are not written contracts or requirements the software must fulfill. Prior to the Sprint Planning, the Product Owner and the development team will meet to refine the prioritized stories in the backlog. You need some flexibility so that you can adjust how much of the story gets implemented. User Stories Done Right: Requirements. See the slide titled 'Negotiable'.

2. The Product Owner should work with the development team to refine the stories and add acceptance criteria, what Mike Cohn calls conditions of satisfaction.

3. However, it is entirely upto the development team to figure out how to implement the user story and break it up into smaller technical tasks. See a good example in this article How to Break a User Story into Tasks.