# Scoping & Breakdowns

## Why Are We Doing This?

* Breaking down complex topics into epics and user stories helps us tackle work in the proper order and avoid losing an overview or goal. Additionally, breaking down bigger tasks early on makes writing and reviewing code more manageable.
* Ensuring transparency by enabling all team members to see what everyone is working on, which issues are blocking/blocked, and how much workload we currently have.
* Creating user stories helps us build features from the user's perspective and ensures that we tailor the experience toward them. It's an easy way to cover all bases and think about edge cases before starting the implementation.

## Getting Started

Before working on a task, we first need to document it in GitHub. This also means breaking down complex topics into smaller subtasks with dependencies between each other.

As a rule of thumb, if you need more than one day to work on an issue or cover many different aspects (e.g., creating a design, writing front-end code, and updating the SDK), it should be broken up into smaller tasks.

The main advantage here is smaller PRs, making for easier code reviews. Nobody wants to review 5,000 line changes in a single PR, as this can become cumbersome quickly and lead to overseen bugs eventually landing in production.

So before you start writing code, think about the task as a whole and how you could potentially break it up into smaller subtasks. Then, please create a new issue in the appropriate repository for each task and link them to make dependencies clear. If a task is small enough or it doesn't make sense to break it up, then create just one issue.

The next section will cover best practices for creating new issues and epics.


---

# Agent Instructions: 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:

```
GET https://docs.elasticswap.org/developer-collaboration/scoping-breakdowns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.