Managing Complex Requirements - Part 4

In Part-3 of this series, we discussed a simple anatomy of business requirements and raised couple of questions – ‘Is it enough if we focus on INVEST in large projects? What else should we do in order to manage complex requirements?’    In this post, I will share my thoughts and some takeaways.

Severability:  Severability of a user story (or user case or a piece of requirement) is an indicator of the level of connectedness or interdependency it has with other user stories or epics.  High severability indicates that a user story can be developed and deployed anytime in the development cycle in any iteration.  Low severability indicates high level of connectedness or dependency.  Obviously, developing and deploying user stories with low severability requires significant amount of planning, dependency resolution and regression testing.

How does severability relate to complexity?  Let me try to answer.  If you have an epic or user story with high severability and if it is complex, it is relatively easier to deal with it.  You can design, develop, test and deploy by budgeting extra time for analyzing and understanding the complex requirement and designing appropriate test scenarios.  You can treat that as a separate release comprising of two or more iterations.  Presumably, there will be very little or no rework on the rest of the system.

On the other hand, if you have to deal with a complex user story or epic with medium or low severability, you will find it very challenging. This is because you need to understand all dependencies, resolve them and sequence the development activities (and make it part of your ongoing prioritization exercise). When you ignore this, you accumulate technical debt. This can lead to significant refactoring at a later stage.

When you do iterative and incremental development using Agile methods, you need to understand the severability of epics and user stories and manage dependencies by means of proactive architecture or design, backlog prioritization and release planning.  Project teams will be able to identify a greater number of user stories that can be constructed and tested with minimum need for rework  or impact on related stories when

1. Architecture and design trade-offs, other decision making, and issue resolutions happen in a timely manner and architecture sub-systems are mature enough,
2. Release planning is effective, and
3. Prioritization of backlog is based on business needs as well as dependencies.

In a way, this approach can improve our ability to deliver user stories or features as individual (and independent) components or apps.

So, what are the takeaways?

1. Build architecture and design components or sub-systems and mature them iteratively as early as you can. Avoid procrastination.  In the name of ‘Agile’ do not let all aspects of your technical components (or sub-systems) emerge all the time until you complete the final iteration.
2. Validate if user stories can include all related NFRs in your project.  In some projects this may not be possible. In that case, you will have to plan for technical stories to address NFRs at regular intervals to suit your release plan.
3. At iteration level, focus on INVEST.  At release level or product roadmap level, focus on everything else discussed in this blog series.  If your project is large, consider disciplined or structured parallel agile development teams working at multiple levels such as features, design/architecture, independent verification etc.
4. Focus on proactive grooming and creating INVEST stories for upcoming iterations. If user stories are volatile inside iterations, find ways to improve grooming sessions.  With multiple parallel small teams moving forward in sustainable pace, you will need the right number of teams working on identifying and creating user stories for upcoming iterations.
5. Identify complex requirements and come up with techniques to deal with them. Complex requirements will need extra grooming expertise and efforts as compared to other requirements. Resolve dependency issues of complex requirements. Follow techniques such as TDD, ATDD, or BDD and ensure high level of collaboration with business at the time of development, testing and acceptance.

Other Posts on Requirements Engineering:

1. Changing Requirements: You Have a Role to Play!
2. Requirements Specification: The Weak Links
3. Requirement Engineering: Ten Principles
4. Requirement Engineering: Specifications in which form?
5. Requirement Engineering: Asking Context-Free Questions
6. Requirements Engineering = Elicitation + Analysis and Negotiation + Specification or Documentation + Validation!