At this point, you’ve created a logically consistent set of requirements and organized them into a production timeline. It might seem like you’re finally ready to start developing the software.

Not quite.

Before implementation begins, most software teams perform one more important planning activity: breaking each requirement into smaller pieces of work that developers will actually complete.

A requirement tells us what needs to be built.

Tasks describe how that work will be completed.

The more complex the project, the more important this step becomes.

Thinking Beyond the Requirement

Consider the following user story:

As a user, I want to securely log into the system using my login credentials so I can access the report-generating system.

At first glance, this appears to be a single piece of work. In reality, it represents many smaller development activities.

For this example, we’ll assume that creating user accounts has already been implemented through a separate user story or requirement. Our focus is only on what must happen when an existing user attempts to log in.

Think about everything that needs to happen after the user presses the Log In button.

For example:

• Does the system verify that the username exists?
• What happens if the username cannot be found?
• How is the password validated?
• What happens if the password is incorrect?
• Does the system establish a secure session after a successful login?
• Does the interface display helpful feedback if an error occurs?
• Are unsuccessful login attempts recorded for security purposes?

Although the user only experiences a single action – logging in – the software performs many individual operations behind the scenes.

Each of these operations represents work that someone on the development team must complete.

Take a few moments to think about this user story and write down all of the individual pieces of work that would be required to implement it.

What Is a Task?

When we break a requirement (or user story) into smaller pieces of development work, we create tasks.

A task is one piece of development work that can be completed by a single developer as part of implementing a requirement or user story.

Tasks may involve:

• developing user interface components,
• implementing business logic,
• creating or modifying database structures,
• building APIs,
• integrating external services,
• validating user input,
• handling errors, or
• writing automated tests.

Collectively, these tasks transform a requirement from an idea into working software.

Identifying Tasks

Identifying tasks is rarely something that should be done by one person.

Different team members naturally think about different parts of the system. One developer might immediately focus on the interface, while another thinks about the database or security concerns. Bringing these different perspectives together almost always results in a more complete task list.

For each requirement, have one team member read it aloud while the group discusses everything the system must do.

Questions like the following often help guide the discussion:

• What happens immediately before this functionality begins?
• What happens after it completes?
• Does this requirement interact with a database or API?
• Does it communicate with another system?
• Does it require input from the user?
• Does it provide information or feedback to the user?
• Does it need to validate data?
• Does it contain multiple logical steps that should be implemented separately?

These questions are only a starting point. As your experience grows, you’ll naturally begin asking additional questions that help uncover missing work.

Even experienced teams occasionally overlook tasks during planning. That’s perfectly normal. As development progresses, new work often emerges. Rather than interrupting the team’s current focus, these newly discovered tasks can be added to the Parking Lot on The Big Board, which we’ll introduce in the next chapter.

Estimating Tasks

Once the tasks have been identified, each task should receive its own time estimate.

Because tasks represent much smaller pieces of work than requirements, they are usually estimated using finer units of time.

For example:

• Requirements might be estimated in half-day increments.
• Tasks might be estimated in half-hour increments.

Breaking a requirement into tasks provides an opportunity to validate your original estimates.

Sometimes you’ll discover that a requirement was much larger than expected. Other times, you’ll realize it was actually simpler than you originally believed.

When this happens, it may be necessary to revisit your production timeline and adjust it accordingly.

Fortunately, if your estimating process is reasonably accurate, overestimates and underestimates tend to balance each other across an entire project.

Writing Good Tasks

A good task should clearly communicate the work that needs to be completed.

When creating tasks:

• Write meaningful, descriptive titles. For example, use Implement password encryption or Validate login credentials instead of vague descriptions such as Coding or Testing.
• Include a brief description and a time estimate for each task.
• Keep tasks appropriately sized. A task should usually require less than one working day to complete. Extremely small tasks create unnecessary overhead, while very large tasks become difficult to estimate and track.
• Assign tasks to developers whose skills best match the work. Teams often colour-code tasks by developer or by work type (for example, front end, back end, database, or testing).
• Whenever possible, incorporate testing into the implementation task itself rather than treating testing as a completely separate activity. This aligns well with practices such as Test-Driven Development (TDD) and encourages developers to think about software quality throughout implementation rather than after the code has been written.

Looking Ahead

By the end of this process, each requirement should have a well-defined collection of tasks that describe the work required to implement it.

The team now knows what needs to be built, how it will be built, and who will likely complete each piece of work.

The next challenge is organizing and tracking all of these tasks as development begins.

In the next chapter, we’ll introduce The Big Board, a visual project management tool that helps teams coordinate work, monitor progress, and respond to unexpected changes throughout the project.