Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
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
up vote 4 down vote accepted

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.

share|improve this answer
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
@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. – Matthew Flynn 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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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