How to handle more than 4000 requirements?

Last post 04:03 pm March 25, 2022
by Ben Jarvis
5 replies
06:31 pm March 24, 2022

In a integration project where we have 200 requirements per application. The same requirements will be applicable for 89 other applications.

So, a total of 200*89 = 17,000 requirements. The integration with multiple applications will be active at the same time (about 10 of them)

How do we add user stories for such high number of requirements into the board in this scenario? Any recommendations or suggestions?

10:34 pm March 24, 2022

You talk about applications. How many products are there? Is each application a product? Can groups of applications be considered a product? Is the whole set of applications a single product?

Are all of these requirements functional requirements? There may be requirements that can be more easily satisfied by including them in a Definition of Done or considering a platform. Non-functional requirements and some regulatory requirements may fall into this category. You may actually have far less than 200 requirements to satisfy.

Do you need to use stories? Nothing says that your Product Backlog needs to consist of stories or even that those stories need to be user stories. There may be better ways to represent the functional and non-functional characteristics of the system or products.

10:40 pm March 24, 2022

The challenge you describe appears to be complicated, but not necessarily complex. There are 17,000 requirements which you appear to be quite confident of. If so, I suppose you might reasonably just accommodate them all within a project plan. I'm not sure why you would need Scrum in this situation or why you would even benefit from having a backlog at all.

06:50 am March 25, 2022

Define a product vision, identify what is important first. Not all applications needs everything simulataneously. We need to identify critical user storis , and thats the crux of managing 4000+ requirements.

Organize planning workshop to identify most important , business viable , maximum value delivering user stories, as per Pareto principle 80% of value delivered by 20% of user stories. So even for intergtation project, we just need to identify those 20 percentage of stories.

No one can add/deliver 4000+ requiremetns in board. That will be done gradually

1. Identify important stories with MoSCoW

2. Use planning workshop to identify stories required by customer to deliver business value

3. Identify story roadmap

4. Identify less dependent or resolved dependency stories 

5. Plan for release - quarterly, monthly or as per customer need

6. Identify candidate stories as per the user story roadmaps for initial relase (ideally those having 0 or minimal dependency)

7. Gradually work on impediments, dependency resolution and work on user story map, refinement of user stories and release planning and execution and delivering user stories to end customers.

03:00 pm March 25, 2022

Thank you all for comments.


@Thomas, yes they are separate products and multiple applications cannot be clubbed as different products. They are all functional requirements. There are non functional ones too. If not for stories, what else can product backlog consist of? set of tasks perhaps?

@Ian, We want use scrum because we want to deliver it for each iteration and plan release accordingly. We want to track and estimate what is team velocity to plan further integration activities. We do have a project plan as well to track and maintain gaps, dependencies and risks. But without a backlog, it seems arbitrary start integration with multiple applications. 

@Jaya, Thank you for the detailed steps on how we can breakdown. Pareto principle is something we can consider initially. I'm having planning sessions with team to understand how we can represent these requirements better so we can track and organize it. Release cadence is something we are still planning. But these steps are something I will keep in my radar during planning. 


04:03 pm March 25, 2022

I'd argue that EVERY product has 17,000 + requirements in them, it's more than you're looking at the entire "iceberg" rather than just the stuff above the water. Just focus on what is the most important first, raise epics for the other areas and wait for them to eventually rise to the top of your backlog...