Creating Tasks for Developers

Approval

Next, the Scrum team must approve the prioritized user stories and break them down into tasks. If the focus is on tasks, why mention user stories first? Because the process of breaking user stories down into definite tasks requires a lot of effort. Not only does it require effort, but these tasks may change over the course of the project. Breaking all user stories into tasks at the very beginning of the project wastes effort. If anything in development changes, these tasks may be rendered useless. Instead, the Scrum team waits until user stories for the immediate next sprint are selected.

Developers are beneficial to this step because they understand the logical divisions in a feature. What seems like a single piece of work to other roles, may have distinct parts to a developer. In addition to the tasks for other roles, developers can break a user story into tasks that allow multiple developers to work on a story at the same time. Once they have separated the tasks, these tasks are added to a task list for the individual user story.

Estimation

After user stories have been broken down, and the tasks have been approved, the Scrum team must estimate how long each task will take. While similar to the story points estimation of user stories, task estimations focus on hours and days of work. This gives the Scrum team a good idea of about how much time the tasks will require, and whether development is behind pace for a user story.

Developers are vital for the estimation stage since only a developer knows how long coding for a task might take. A seasoned developer has seen enough work to have a good idea of how long any piece of code will take. With a team of developers, these estimations can be averaged out. Bias from the area of expertise or seniority will generally cancel out and yield a close estimate.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: