> For the complete documentation index, see [llms.txt](https://www.lawfirm-operations.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.lawfirm-operations.org/publications-and-articles/agile-law-firm-workbook/4.-elements/4.2.-epic.md).
# 4.2. Epic
When the (work) Elements that lead to the Goal are first written down, they often have the form of an Epic. There, the first general description is added, but it is too large to be immediately executable by the team. The further you get into a project, the better the individual Items of an Epic emerge. The Product Owner takes Epics, turns them into Items and defines them—if necessary, in coordination with the team—until they are ready to be added to a Sprint.
Specialised attorneys might find themselves with recurring Epics. These may be standard procedures in special types of cases, similar types of contract projects, etc. Not all Epics of a project and their content are known at the start of a project; some can be standardised and made into templates for future use. An Epic is done when all the Items it contains are done.
## Story
### Planning a litigation project
Given their law firm has the ambition to win its clients’ lawsuits, defining the Goal initially felt like a small detour to the attorneys, but eventually they found that it helped the sharing of experience amongst themselves, and granted clarity on how to explain to their client what is achievable in the setting they have.
With that in mind, they now settle down to plan the project. Litigation often spans a longer period, which fits well with the highest actual work Elements, the Epics. The team reiterates that trials usually take more than a Sprint and they mull over how they could translate and break up their general experience into Elements that also serve as an explanation to their client. They want to have the client on board throughout the process, want him to understand both their approach and the litigation, but as litigation often comes with time pressure, being able to get started quickly is important. This is why Alice as the partner is hesitant to implement a new method of working and add more work for the team by defining parts of the process that they hadn’t done previously. Because she is committed to trying Agile methods and the timeline in this setting is only of medium urgency, she was ultimately comfortable with it.
Whilst their description of their work in Elements is first and foremost intended for themselves, they can show these to the client to explain the process. Now they break down the legal proceedings into Epics. They are fully aware that certain properties of the litigation may change, for example, in the case of promising settlement discussions; when needed they will adapt the Elements to reflect this.
## Example
In our story and the respective litigation case, the team’s initial epics look like this:
* Establish the facts of the case; gather evidence.
* Assess legal basis of the claim.
* Contact the opposing party claiming the amount.
Further Epics would be drafted depending on the evolution of the lawsuit, e.g.:
* Set up settlement meeting.
If the settlement fails:
* Draft statement of claim.
* Review the counterplea and decide on next steps.
## Template
### The Epics are: ...
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://www.lawfirm-operations.org/publications-and-articles/agile-law-firm-workbook/4.-elements/4.2.-epic.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
