Hello my fellow, lemons? I have this problem in my current project I’m out of clue how to approach it. Maybe someone had similar experience and can give an advice.
Our requirements captured in JIRA. Throughout years we accumulated thousands of user stories. Say suppose following naive requirements team knows about:
- Day 1: create home page
- Day 20: create profile page
- Day 50: add green footer to all pages
- Day 100: create admin page
Day 150: change footer color to blue
Now I’m doing refactoring (yes, I know, this is the actual problem) on day 400 and noticed that footer on profile page having green footer. Because requirements are just set of individual statements not consolidated with all history of system no one on the team knows why is that, is it bug or requirement did change on day 300 but we cant find it now.
When I worked in Waterfall we had BRD and FRD stating current actual desired state of system which was “reduced” from individual requirements which were coming in throughout project life. When in doubt devs can check FRD and not only know how system expected to behave but also which are other parts of the system that will be affected. How is it in Agile? To my understanding FRD is not a thing in Agile. Do I need to scan through hundreds of tickets and hope I didn’t miss anything every time i’m doing any non-trivial change to system?
I think there are two separate things I want to address here:
First, agile isn't a project management methodology, it's just a set of 4 abstract priorities and 12 abstract principles. It's very short, you can check it out here:
https://agilemanifesto.org/
Nothing here says that you're not allowed to write documentation, write down requirements, etc. In fact, the principles encourage you yourself as a software team to create the exact processes and documentation that you need in order to meet your goals.
"Working software over comprehensive documentation" does not mean you aren't allowed to have documentation, it just means that you should only write documentation if it helps you build working software, rather than writing documentation for the sake of bureaucracy.
"Individuals and interactions over processes and tools" does not mean that you should have no processes, it just means that the individuals in your team should be empowered to collaboratively create whatever processes you need to deliver good software.
Secondly, in terms of practical advice:
a. You have metrics about how your system is used.
b. You have automated tests covering any requirements, so that you can feel confident when making changes to one part of the system that it isn't violating any unrelated requirements.
c. You actually document any confusing parts in the code itself using comments. The most important thing to cover in comments is "why is this logic necessary?" - whenever something is confusing, you need to answer this question with a comment. Otherwise, the system becomes very annoying to change later on.
If you are missing any of the above, then propose to your team that you start doing it ASAP