> 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.9.-bringing-it-together.md). # 4.9. Bringing it together So how does all this fit together? First things first. To ensure good alignment of all the Elements, it is vital to know what you are aiming at (Goal). From there the question is “what has to happen, so that we can achieve this?”. The Idea is to identify the big things that need to happen (Epics). Those don’t need to be super detailed yet. To get started, it is enough to have a rough idea of the main topics. The User Story method can be helpful here, as it forces one to think about an Epic starting from the desired outcome and then goes backwards. Once you have some Epics defined it’s time to split them into Items that can be done within one Sprint. Here you can use the User Story method once again. Starting with the User Story provides a great baseline from which you can then add more and more details to your Item/Epic until it is clear what it contains. To make sure we cover everything needed for the team to start working when defining Items, it can be useful to define when an Element is sufficiently described and therefore ready to be worked on—the Definition of Ready. From here the only question that remains is: “when are we done?”. This is where the Definition of Done comes in. A collection of overarching quality criteria that define when an Element is considered to be done. This reflects the standards of the team. ## Story ### Having things ready Our two senior members of the team, Alice and Fiona, think that it might be interesting to have a quick chat with the team. They come to see Gabriel, who is happy for the distraction. Based on what he read about Agile teams in the morning on the way to the office, he suggests moving the discussion into the secretarial office and include their secretary Oliver, who has not been involved in their discussions about new processes yet. When introducing the topic to him, they quickly find that they’ll need to visualise all work Elements, so they decide to put them on Post it notes on the whiteboard and group them as well as possible. For the moment they pin them to the board in Oliver’s office, as that’s the place they all visit often. But they feel uncomfortable with the sheer volume of Elements, especially about how to bring User Stories, the Definition of Ready, Definition of Done and Acceptance Criteria together—which goes with which? Help comes from outside this time, as Sara confi rms a lunch appointment for next day. While this will be without Alice for the moment, Fiona and Gabriel will share their findings with her in the afternoon. Sara turns out to be very pragmatic regarding their points: she suggests starting with Items having a User Story, depending on what can be described easily, and that each Item should relate to a Definition of Ready and a Definition of Done and feature clearly spelled out Acceptance Criteria. Like this, the team is always ready to work and the person working on an Item would always be able to tell whether it’s finished or not. Just before they part ways, Gabriel remembers that he wanted to ask Sara about teams that only spend a part of their time in an Agile team. Her answer to the question was somewhat disillusioning. One would preferably have their team members work Agile full-time but she acknowledged that this might not be feasible. It is still possible, just a little more difficult to start working in an Agile manner if you also have to work non-Agile at the same time. This can still work, if there is a core team that has most of its time dedicated to it. ## Example ### Item 5: Set up a table to align the arguments before court with the submission/argument, relevant proof, the legal basis, and potential applications to the court. **User Story:** As an attorney, I want to have all arguments and relevant details easy at hand, so that when I go to court and discuss a particular argument, I don’t have to look for the most important information. **Tasks:** * [ ] Create the table. * [ ] Fill out the table. * [ ] Link the fields to the relevant files in the system, where appropriate. * [ ] Format the table based on firm standards. **Acceptance Criteria:** * [ ] The table consists of the following columns: argument/submission, proof, legal basis, application, other info. * [ ] A list of all arguments/submissions to the court is written in the first column. * [ ] All columns apart from “application” and “other info” are filled out. * [ ] All proof is linked to the relevant fi le in the file system. * [ ] The table is easily readable when in court. **Definition of Ready:** * [ ] Acceptance criteria are defined. * [ ] Item has been explained to the team. * [ ] Dependencies are clear. * [ ] This Item can be executed in one Sprint. **Definition of Done:** * [ ] Acceptance Criteria for the Item are met. * [ ] Legal assessment has been executed. * [ ] Formatting has been applied. * [ ] File names have been issued appropriately and it has been saved in the correct place. * [ ] All links to documents in the file system are working and updated. * [ ] Correct party/parties have been added. * [ ] Attorney has reviewed and approved. --- # 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.9.-bringing-it-together.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.