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?

  • Forgive my ignorance but what is an HLD and LLD document? That must be an abbreviation for something but I have never heard this term.
    – maple_shaft
    Feb 17 '12 at 17:44
  • 1
    HLD - High Level document (Overall explanation of the requirement) and LLD - Low Level Document (Explaining about the technical description)
    – user46506
    Feb 17 '12 at 17:45
  • Thank you, that makes sense, I typically use the terms Business Requirement Document or SRS, and Technical Specification for the low level technical description.
    – maple_shaft
    Feb 17 '12 at 17:49
  • @Tomcrusie: Please update the question to include the definitions. It's hard to piece the question together when comments contain essential information.
    – S.Lott
    Feb 17 '12 at 18:41

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.

  • 2
    Documentation may not have the stake holders as its audience, but that doesn't mean it doesn't provide them value. Having a well-informed team working a well-thought-out project is far more valuable to the stakeholders than the alternative.
    – Dan Ray
    Feb 17 '12 at 18:29
  • 3
    @DanRay I agree with this that good documentation increases the value of what is delivered to the stakeholders, however the point I am making is that the conversation needs to happen about if this documentation is truly adding value or not. More often than not, most developers who are turning out technical documentation for a project, do so because it is mandated that they must by their manager or tech lead or architect. These documents tend to not provide value. Good technical documentation communicates a complex design or pattern, is consumed by multiple members of the team, cont...
    – maple_shaft
    Feb 17 '12 at 19:24
  • ... cont and helps the developer turn an abstract idea into a technical implementation. It flows naturally from the developer because it helps the developer or helps other developers on the team understand a design or concept. Nobody should mandate this of the developer.
    – maple_shaft
    Feb 17 '12 at 19:27
  • Surprisingly (or not), many stakeholders do find value in documentattion the shows what a system should do mapped to tests that show that the system does do what they want it to. Feb 18 '12 at 4:04
  • Not worthy of a new answer, but extremely relevant is Scott Ambler's articles on Agile/Lean Documentation.
    – Thomas Owens
    Mar 18 '12 at 22:03

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 :

  1. 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.

  2. 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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.