Completing Requirements Milestone

Learn More About the Requirements Milestone

Before you proceed with this page, learn about the agile project lifecycle and the requirements milestone:

Creating Epics, Features, and Tasks

Epics

From company to company, the term "epic" may be used differently. This course will describe epics as it is traditionally coached in Agile. Epics are large! How epics form are completely up to the backlog owner (the product owner duty). They decide how to form epics and how to categorize things in epics. Sometimes epics are created and are used as "buckets" of organization.

There are two general types of epics:

1. Fixed-scope Epic: These epics constitute a specific set of work items that will eventually be delivered; at this point, the epic is "done" and no longer used in the backlog. The benefits of this are for clarity on progress and reporting. Some tools provide capabilities to measure how long an epic took to close, or the status of work within the epics themselves. This allows teams to check how far they have to go until they meet the "definition of done" for the release.

2. Never-ending Epic: These epics are never "closed", work keeps getting added to them. This can be useful if there is a type of work that will never end and is not part of fixed-scope work.

Features

There are many features within epics, and many user stories within features.

Tasks

Tasks are independent pieces of work that finish quickly.

Use the Product and Service Vision and Scope Template to define the epics, features, and tasks: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Creating the Release Roadmap

Once you have epics and features you can map them on a timeline. However, this timeline is not a "one and done" deliverable. As your assumptions change, your vision and scope change. As your vision and scope change, your roadmap needs to change with it. Teams should build maintenance into their roadmaps such that they can keep them accurate on a continuous basis.

Use the Product and Service Vision and Scope Template to define the roadmap from the epics and features: https://www.figma.com/community/file/1494349319575390329/product-release-vision-scope-and-roadmap-workshop-template

Creating Task-Level Requirements for Research, Design, Product, and Development Work

User Stories

Tasks should start with user story statements. This helps teams who are reading and reviewing requirements quickly review the "who", "what", and "why" before proceeding with the details. See the previous lesson on crafting user stories.

The user story is at the heart of all requirements work. It summarizes who the work is for, the goals they have, and why the work is worth doing. Beyond this, the other details within epics, features, and tasks expand on the user story. Without the user story, teams would have a hard time communicating the "why"; they may not solve the right problem or solve the problem correctly.

The user story statement can be one of the hardest pieces of requirements to craft well. It takes a lot of knowledge, awareness, and empathy towards the audiences you're talking about in the user story. It takes a lot of language and writing skills too. Without these, it can be hard to describe the person's goals and why it's worth building.

A good user story:

1. Is one sentence;

2. Clearly justifies why it's worth building;

3. Tells a story out of empathy;

4. Describes the user goal, NOT the solution;

5. Always has a "so that" part;

6. Explains things in plain terms anyone can understand;

7. Avoids jargon;

8. Is concise;

9. Speaks from the perspective of the audience;

10. Uses the language and tone that the persona would use;

Acceptance Criteria

Acceptance criteria are the "instructions" for completion. They do not, however, dictate solutions. They must dictate the user need, the business need, and the technical need in their details. This helps the person delivering the work successfully deliver what's needed.

Acceptance criteria determine whether the problem is being solved and whether the problem's being solved correctly! Everything so far leads to this. This is it. Get ready to learn about the anatomy of acceptance criteria.

Acceptance criteria has several parts:

1. User story statements

2. Background

3. Problem statement

4. Goals of the task

5. Expected deliverables of the task

6. Scope / "definition of done" of the task

7. Listed items of acceptance

Task Flows

Task flows describe the sequence, logic, and expected outcomes of use cases. To describe the sequence of events in a use case, requirements writers can visualize it all with a task flow. Task flows show each step, the decisions that users or the system must make, and the paths that result in decisions being made.

Use Case Scenarios

Basics of Use Cases

Use case scenarios describe scenarios of business logic that users go through to carry out tasks. They can be useful when documenting requirements to ensure that teams focus on building the right solutions. Use cases are based on persona so they change per audience. Use cases help requirements owners generate buy-in from stakeholders about the features being built. They can talk about work based on situation to support in the product or service.

Describing the "Happy Path" and "Non-Happy Path"

"Happy Path" is a term often used in requirements and use case writing that describes the most common scenario. Happy Path scenarios are straightforward and simple results are expected. Non-Happy Path scenarios are for other scenarios where someone needs to describe if another circumstance happens. For instance, an error case is a non-happy path because it's not a normal scenario that all users face; only some users face it. It's very important when writing use case scenarios to write both Happy Path and Non-Happy Path scenarios for the sake of understanding everything that needs to be built or tested.

How to Properly Scope Tasks to Ensure They Get Finished in One Short Iteration

Tasks must be completed quickly in order to deliver them and get feedback quickly. Teams shouldn't put too many pieces of work in a single task. This can be challenging for people managing requirements. Teams can use the I.N.V.E.S.T. acronym to ensure that task-level work can be completed quickly (one or two weeks).

1. Independent - A task should be able to completed on its own without dependencies

2. Negotiable - A task should be able to pivot and adjust based on team or client needs

3. Valuable - A task should provide provable value to humans who use a product or service

4. Estimable - A task should be able to be easily estimated in terms of level of effort

5. Small - A task should be able to be completed in one iteration

6. Testable - A task should be able to be put into the hands of users and tested

Refining Requirements with Teammates

Teams should review and refine requirements after they are written. This should be built into their work process together.

Estimating Level of Effort for Tasks

Level of effort should be measured for all kinds of work: research, design, and development alike. Teams should gauge level of effort for their work so that they have an idea of what's too much work for a given iteration, and can track the changes over time.

Measuring level of effort changes team-to-team. The overarching goal of an Agile team each iteration is to finish what they commit to. IF they have committed to too much work and can't finish, they should reduce the scope of the iteration's work itself; this is important to continually progress in delivery of the work and avoid work that is in progress for too long without delivering.

In order to do this successfully, teams must measure the effort levels of tasks in their backlog. This helps to holistically understand how much work is "too much" for the team in one iteration. Depending on the Agile method, teams may plan entire iterations (like Scrum method) or pick up one-off tasks as they are ready for the work (like Kanban method). All methods of Agile require teams to measure their effort; this may lead to breaking down tasks or splitting them out into separate tickets, and will save teams from unfinished work at the end of iterations.

Each team is highly unique in the case of how much work they can get done in one iteration. It depends on their skills, their availability, and a lot of other things. The methods of measuring level of effort remain the same, but the number of stories each team can get done in one iteration is highly variable and changes team to team. Learn how to measure level of effort in the next lesson.

Planning Requirements for Upcoming Work

Once the requirements are refined with the team, teams can forecast when they would complete the work using the project plans and sprint goals (started in Intake milestone).

Head to the Next Lesson