Oversized Requirements? Here's how to fix them.

[Bogdan_Gorka]

Getting requirement sizing right is an important but less obvious driver of predictable SAP project delivery. It is the art of making requirements neither too big nor too small. This may sound like a detail, but it shapes everything that follows: how releases are planned, how work is owned, and how testing stays traceable. After formulation and classification standards, it is another dimension to properly creating requirements.

Why requirements granularity is important?

Granularity defines how big or small a requirement should be so that it can be delivered, tested, and accepted within a single delivery or release cycle.

On one hand, if requirements are too large, their delivery will stretch across waves. This means that one requirement will not be fully completed and fully tested within one Wave release. That breaks the flow of delivery and the traceability of results.

On the other hand, if requirements are too small, the requirements backlog swells with too many tiny items which adds administration effort and slows down the work.

The golden rule

SAP Activate recommends sizing requirements so they can be fully delivered and tested within a single Wave and inside one Work Package. This makes tracking progress from requirement through configuration to test case much easier.

To keep delivery predictable, adopt a simple rule: One Requirement → One Work Package → One Test Case → One Wave

 Decomposition and Grouping

Use early Explore workshops for iterative refinement which is continuously splitting or regrouping requirements as delivery planning evolves.

If a requirement is too large, decompose it into smaller, independent, testable sub-requirements. Each should deliver a clear, standalone piece of value that can be tested independently. They still can be associated with each other in the same test plan.

If a requirement is too small, group it with other closely related requirements and reformulate them into one coherent requirement delivered as one work package.

The effort pays off: proper sizing makes ownership clear, simpler planning, and complete test traceability from requirement to configuration and testing results.

Iterative refinement

Skipping granularity refinement often leaves oversized requirements that may span two waves. This reduces transparency, complicates test coverage, and makes progress reporting unreliable. Right-sized requirements make governance measurable: every item in the backlog has a clear boundary, a single owner, and a defined success criteria.

Iterative refinement

Skipping granularity refinement often leaves oversized requirements that may span two waves. This reduces transparency, complicates test coverage, and makes progress reporting unreliable. Right-sized requirements make governance measurable: every item in the backlog has a clear boundary, a single owner, and a defined success criteria.

Jira practice

Granularity can be managed directly in Jira by defining clear parent–child relationships between Requirements and their Deliverables. This approach keeps ownership, scheduling, and testing transparent.

• Create each main Requirement as a standard level work item

• In case of need for a decomposition, add sub-task level work items called Sub-Requirements underneath.

• Map each Requirement or Sub-Requirement to a single Work Package that will be scheduled in one Wave to preserve traceability.

• Link every requirement to the corresponding Jira Xray Test Cases that verify acceptance and completion.

 You can visualize the hierarchy using a Jira app such as Structure, to display dependencies and delivery scope clearly

 What’s in it for you?

Requirements granularity may sound like a technical detail, but in SAP projects it’s one of the strongest predictors of delivery stability. In simple terms, your project scheduling will be much more reliable.

So, next time before you approve a requirement in your backlog, ask: "Will this fit into one Wave, in one Work Package, tested by one Test Case?" If yes, go to the next requirement.

If you have found this article helpful, please leave me a Kudo on top of this page. This will encourage me to write more articles in SAP Community. Thank you!

Want to learn more about managing SAP projects in Jira?

Follow me to get notified about new articles on managing SAP projects and how Jira can support your S/4HANA transformation.

About author

Bogdan Górka works as Atlassian Solution Architect and SAP Project Governance Consultant. Creator of R2D ALM for Jira, independent Atlassian consultant, and founder of PMBG.EU.