Having set up our timeline for production, it probably makes sense to begin the development process. But not so fast! Depending on the type of system you are building, it might be necessary to look at the work you need to complete in finer detail.

Before we do this, let’s consider a requirement that many modern web and mobile applications would require; logging in with a username and password. This functionality might be described as a user story, a requirement, or a use case.

For now, let’s consider the 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.

Assuming that login credentials mean a username and password, and the report-generating system is defined accordingly in the system design documents, let’s break down what this requirement means in terms of work.

For this activity, assume that the user story is self-contained. That is, we only need to focus on the things that need to be implemented to achieve this user story. In this case, creating a system that securely stores the username and password wouldn’t need to be implemented, as this should have been developed as part of the user story: As a user, I want to create a user account so that I can log into the system.

With this in mind, consider the various things that this user story requires. What needs to be developed? Begin by thinking about what the user does, and how the system might respond to the user. What are the things that the system might do when the user initiates this user story?

For example, will the system need to check for the existence of the user name first? If it finds it, what will it do in response? What if it doesn’t find the user name? What if the user name exists, but the password is wrong?

Take a few moments to jot down the various things that the system might do in response to the user initiating this user story.

Tasks

When we break down a user story or a requirement into smaller pieces, we create tasks. In short:

Tasks could be specific to the back end of the system, the controller, or the user interface. They might also describe our system interacting with an external system. And they definitely should include testing at all levels!

To identify tasks, we really need to think about everything that our system might do in response to the initiation of a user story or to complete a requirement. Each of the things that the system will do is a specific piece of functionality that needs to be developed by someone. But how do we determine what the tasks are?

As with everything that we do, we will work as a team to develop a list of tasks for each requirement. We do this because our individual experiences will affect how we look at each requirement. Some of us might focus our task identification on the user interface, while others will think of the database and API. Whatever the case, it’s important to really think deeply about each requirement.

In your group, have one person read aloud the first requirement in your list of requirements. The group should then begin documenting as many tasks as necessary to complete the requirement. While you don’t have to order the tasks, you may want to ask about each task:

• What would the system do before and after this particular requirement?
• Does this requirement require me to access or modify the database (perhaps through an API)?
• Does this requirement require me to access information from another server or system?
• Does this requirement require me to collect information from the user?
• Does this requirement require me to provide feedback to the user?
• Does this requirement require me to validate information?
• Does this requirement consist of multiple functions?

These are not the only questions you might ask, but they can help facilitate discussion in the team so that you can identify all of the tasks necessary for a given requirement or user story. Of course, even the best team might miss something. That’s okay. That’s why we have the Parking Lot on The Big Board – which we’ll learn about in the next Chapter.

Time Estimates

Depending on the size and scope of the project, you may be required to develop time estimates for each task. The unit of time that is used will likely be more refined than that of the estimates used for each requirement (e.g. if the requirements are described in multiples of 0.5 days, the tasks might be described in multiples of 0.5 hours – just don’t make the time increments too small). We do this to ensure that our original estimate of the requirement is still valid.

That is, by focusing on each requirement and detailing the tasks associated with them, we might learn that we overestimated or underestimated the work that needed to be done. If we’ve estimated poorly, we might need to revisit our timeline. However, if you’ve estimated well, you’ll find that the overestimated and underestimated times will likely balance out.

A Few Things To Consider

When developing your list of tasks:

• Make sure they are meaningful and well described (for example, write “develop the login class” or “develop the encryption for user login”, instead of “coding” and “testing”). Short sentences are helpful. Include a title, a short description, and a time estimate.
• Make sure they are “right-sized”. Don’t create tasks that take 5 minutes or 10 minutes to complete; otherwise, you’ll be writing tasks more than you’ll actually be developing anything! Instead, write tasks such that each requires less than 8 hours to complete. Do not create tasks that span multiple days.
• Assign developers to the tasks based on the skills they have. Since these will be posted on The Big Board (discussed in the next chapter) with each of the requirements/user stories, you might colour code the tasks by user, or perhaps by the type of work that is required (e.g. front end, controller, API, database).
• Consider the Test Driven Development approach. That is, make unit testing a part of each implementation task, instead of its own separate task. This practice, of course, will depend on how your team or company works.

Review Questions