Our team is developing a project using an Agile development process. All of our requirements are converted into product backlog items and task are broken down based on that. One of my team member suggested to maintain the High Level Document (HLD) and Low Level Document (LLD) for the requirement.
Do we need to have these documents to follow the Agile process?
No, Agile does not call for the need of HLD (or SRS, business requirements) document or LLD (or technical specification) to be associated with User Stories. These documents would be highly encouraged for the Waterfall process however.
Simply because Agile does not call for this doesn't mean that it shouldn't exist though. They are not mutually exclusive. One can theoretically manage an Agile project and still demand HLD and LLD documents however the case should be made if these documents bring value to the stakeholders.
It is highly encouraged in Agile to only do tasks that bring value to the stakeholder and most would argue these documents do not do this. They may bring value to the architects or to the developer, but the users and other stakeholders likely do not care about such things unless they specifically require them as deliverables.
Short answer no. Agile does not say much about what you must or must not do. It's mostly a set of values and a way of thinking.
However typically written requirements are pretty light in agile processes. Your HLD and LLD documents sounds heavier then what might be common.
Typically backlogs are filled with stories, stories are mostly invitations to have a design discussion. After a discussion some notes may be written down, some acceptance criteria worked out. But it's all pretty informal on a need to have basis.
I believe It depends on some factors like :
The business domain of the project if we are talking about medical application or similar then you'd definitely want to keep track of these type of documentation for FDA or equivalent Approval.
Expected lifetime of the project to release if we are looking to a 2~3 years then its better to keep as minimum and effective level of documentation as possible maintained to keep track of the critical changes through life time of the project.
And I believe there can be more factors that can affect such decision so it is better to define the pros and cons of creating & keeping such type of documentation maintained and deiced.
The answer is that we should use documentation when we think we need it, rather than ban it altogether. One person suggested if a project is long then maybe keeping an original document stating what the goals and objectives were at the time could be useful. Long before there was Agile, I used this common sense approach. I got told off a few times for taking whole sections out of test strategies and plans because they were of no use in the context of what I was doing, rather than complete them to simply comply with a standard. If a test plan can be written on a single page, I do it because over time its easy to meander down the wrong path especially if there is no other documentation in the project at all. Its not a bad thing, unless the information in it is wrong or irrelevant or just not useful. When its useful, do it, when its not dont. That to me is "agile"
If you care for these things (depending on the environment/project you may very well want to), you treat them as tasks and plan for then just like any other task. Whether you want to make these documents or not is independent of your agile/scrum process.
