Creating Tasks and User Stories is a critical element in the extraction of User Requirements in any Scrum Project. User Stories define a specific component that is needed as part of the whole Product Deliverable. It is described in language that is clear to the Business User. The technical specifications that underlie this small User statement are not described. They need to be Documented as briefly and concisely as possible. This is achieved by breaking down each User Story into a set of Tasks. The Tasks are then the building blocks of the Sprint.

Team members complete User Stories by taking one or more Tasks, developing the functionality and demonstrating it during a Sprint Review meeting at the end of the iteration. The Daily Stand-Up Meeting is utilized to report on the Tasks completed the previous day and the Tasks to be Done today. Tasks can have interdependencies, which gives a pattern to how they are constructed. They are not taken on arbitrarily, but constantly viewed as part of the whole.

Creating Tasks: Getting to Task Discovery

When all of the User Stories have been created, they are added into the Product Backlog in priority order. The Stories with the highest priority are put forward for inclusion in the next Sprint. Throughout the Sprint Planning Meeting, the Scrum Team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) discuss the number of Stories they can commit to completing in the next Sprint. An agreement is reached and a set of User Stories are moved into the Sprint Backlog for execution. These Stories can now be divided into Tasks during the Sprint Planning Meeting.

The Scrum Development Team examines each User Story. They determine the set of Tasks that are required to get the Story to “Done”. Each Task has an Estimate of Effort attached to it. This task estimate is typically given in time, measured in hours. The User Stories are estimated in points.

It is recommended that no Task is longer than one Sprint day. That is unless it is a Task for a paired Team. In which case the estimate may be greater than one day but should be able to be completed within a day by multiple team members.

Creating Tasks: Identifying Dependencies

Dependencies can occur at all levels of Product Requirements. When they are defined at Task level it is simple to understand any delays within the Sprint. This is particularly true when dependencies are external and outside the control of the Sprint. There are many ways of categorizing dependencies. Scrum utilizes four classifications:-.

• External.
• Internal.
• Mandatory.
• Discretionary.

These are not exclusive, one can have a Mandatory External dependency for example. One can also have a dependency that is external, where one Scrum Team depends on another internal Project.

External Dependencies

‘External Dependencies’ present the most significant difficulty. This is due to the fact that they are outside the Scope and control of the Team. They might be inter-dependencies between this Team and another Scrum Team in a multi-Scrum Project. They may be a dependency on someone or something outside the Project. For example, this could be a supplier delivering hardware or a new database.

Internal Dependencies

‘Internal Dependencies’ are dependencies within the Sprint. For instance, a Task that needs the database to be refreshed by another Team member. This could be required before a Test-Driven Development pair can develop a test frame and begin generating the Code.

Mandatory Dependencies

‘Mandatory Dependencies’ are non-negotiable and can represent Risk to the Project. Mandatory dependencies are often the reason that the Project was released in the first place. For example, a Change to tax legislation.

Discretionary Dependencies

‘Discretionary Dependencies’ are dependencies that the Team have identified will be best for the Project. This could be based on previous experience or Lessons Learnt in a Retrospective. In test-driven Development, the Testing logic is developed before the Code that is to be tested against it. This is the reverse of a Traditional Development project.

Handling the Task dependencies well is the key to Project success. There should never ever be a scenario where one member of the Team can not proceed due to a reliance on another Task.

We found these books great for finding out more information on Agile Scrum:

Creating Tasks: Developing the Task List.

As each User Story is broken down into its constituent Tasks, it can be added to the Task List. There is no prescribed format for a Task list, however it must contain:-.

• User Story details with which the Task is associated.
• A “Handle” for the Task, e.g. a Task No.
• A Task description.
• The Estimated Effort given in hours.
• Actual Effort in the same metrics.
• Status of the Task.
• Dependency information on other Tasks.
• Tasks dependent on this one.
• Person who has actually assumed the Task.

The Task list needs to include all the Tasks to be finished during the Sprint. When it comes to the Sprint Retrospective, the Estimated vs actual Effort is crucial. This enables Lessons Learnt about Estimation to be taken into the next Sprint.

Proactive Risk Management

It is recommended to carry out some proactive Risk Management when it comes to dependencies. In a Scrum dependency action Plan, it is recommended that you have a dependency Risk Meeting. During this meeting Traditional Risk analysis can be utilised to Identify and categorise Risks (i.e. Probability * Impact) and provide Mitigations in case of the dependency producing a bottleneck. Forewarned is forearmed and the Scrum Product Owner or Scrum Master can use any Mitigation to external and/or mandatory Risks, while discretionary and internal Risks need to be Mitigated by the Team.