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?
First and foremost, it puts you into tight-knit communication with your team and the customers, so just ask if anyone remembers why it is like that.
If no one does, then Agile enables to basically fuck around and find out.
Which is to say, change it to how you think it’s supposed to be and see if anything breaks / anyone complains. If that happens, Agile allows you to react quickly, i.e. to change it back and quickly release a fixed version.
But yeah, as the others said, if your team feels like documents work better for them, then do Agile and documents. That’s why retrospectives are an integral part of Agile, because it’s not a perfect plan how to work together. You’ll know best what works in your context.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@beehaw.org
All things programming and coding related. Subcommunity of Technology.
Agile tries to solve this differently.
First and foremost, it puts you into tight-knit communication with your team and the customers, so just ask if anyone remembers why it is like that.
If no one does, then Agile enables to basically fuck around and find out.
Which is to say, change it to how you think it’s supposed to be and see if anything breaks / anyone complains. If that happens, Agile allows you to react quickly, i.e. to change it back and quickly release a fixed version.
But yeah, as the others said, if your team feels like documents work better for them, then do Agile and documents. That’s why retrospectives are an integral part of Agile, because it’s not a perfect plan how to work together. You’ll know best what works in your context.