11 CREATE AND ESTIMATE TASKS
The Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or Customer representatives attend the Sprint Planning Meeting.
During the Sprint Planning Meeting the Product Owner describes the highest priority features to the Team. The Team asks enough questions during this meeting so that they can go off after the meeting and determine which Tasks they will move from the Product Backlog to the Sprint Backlog.
Collectively, the Scrum Team and the Product Owner define a Sprint goal, which is a short description of what the Sprint will attempt to achieve. The success of the Sprint will later be assessed during the Sprint Review Meeting against the Sprint goal, rather than against each specific item selected from the Product Backlog.
After the Sprint Planning Meeting, the Scrum Team meets separately to discuss what they heard and decide how much they can commit to during the upcoming Sprint. In some cases, there will be negotiation with the Product Owner, but it will always be up to the Team to determine how much they can commit to completing.
The Task Planning Meeting is normally divided into two sections, with a designated purpose and broad agenda for each.
TPM First Part |
|
|
|
|
|
TPM Second Part |
|
|
|
Figure: Task Planning Meeting, Broad Agenda |
|
In Scrum, User Stories are written on small Index Cards. Only essential details are documented on the cards, which can be used by the Scrum Team to collaborate and discuss. These Index Cards, often described as Story Cards, increase visibility and transparency, and facilitate early discovery of any problems that may arise.
Decomposition is a tool whereby high-level Tasks are broken down into more detailed, low-level Tasks. Members of the Scrum Team decompose the User Stories into Tasks. Prioritized Product Backlog User Stories should be sufficiently decomposed so that the Scrum Team has adequate information to create Deliverables from the Tasks itemized in the Task List.
Once the Scrum Team has selected User Stories for a given Sprint, they should then consider any dependencies, including those related to the availability of personnel as well as any technical dependencies. Properly documenting dependencies helps the Scrum Teams to determine the relative order in which Tasks should be executed to create the Sprint Deliverables. Dependencies also highlight the relationship and interaction between Tasks, both within the Scrum Team working on a given Sprint, and within other Scrum Teams in the project.
There are numerous types of dependencies: mandatory and discretionary, internal and external, or some combination thereof. For example, a dependency may be both mandatory and external.
- Mandatory dependencies: Dependencies that are either inherent in the nature of the work, as a physical limitation, or that may be due to contractual obligations or legal requirements. For example, work on the first floor cannot begin until the foundation of the building is complete. Mandatory dependencies are also commonly described as hard logic.
- Discretionary dependencies: Dependencies that are placed into the workflow by choice. Typically, the Scrum Team determines discretionary dependencies based on experience or best practices in a particular field or domain. The Team may decide to complete one Task before working on another because it is the best practice, although not a requirement. For instance the Team may choose to build the door and window frames before the full structure of the wall is in place.
- External dependencies: External dependencies are those related to Tasks, activities, or products that are outside the scope of the work to be executed by the Scrum Team, but are needed to complete a Project Task or create a Project Deliverable. External dependencies are usually outside the Scrum Team’s control. For example, if the Scrum Team is not responsible for procuring the materials required for building the walls, then those materials and Tasks related to their procurement are considered external dependencies.
- Internal dependencies: Internal dependencies are those dependencies between Tasks, products, or activities that are under the control of the Scrum Team. For example, installing dry-wall must be completed before painting the wall can begin. This is an example of an internal dependency because both Tasks are part of the project. In this case, it is also mandatory because it is based on a physical limitation. It is not possible to paint the wall before it is dry-walled.
11.5 Output from the Sprint Planning Meeting
- Task List: This comprehensive list contains all the Tasks to which the Scrum Team has committed for the current Sprint. It contains descriptions of each Task along with estimates derived during the Create Tasks process. The Task List must include any testing and integration efforts so that the Product Increment from the Sprint can be successfully integrated into the Deliverables from previous Sprints.
Even though Tasks are often activity-based, the Scrum Team decides the level of granularity to which the Tasks are decomposed.
- Updated Approved, Estimated, and Committed User Stories: The User Stories are updated during this process. Updates can include revisions to the original User Story estimates based on Tasks creation and complexity factors discussed during the Sprint Planning Meeting
- Dependencies: Dependencies describe the relationship and interaction between different Tasks in a project. They can be classified as mandatory or discretionary; or internal or external.
There are numerous ways to identify, define, and present the Tasks and their dependencies. Two common methods involve the use of Product Flow Diagrams and Gantt Charts.
11.6 Task Estimation in the Sprint Planning Meeting
Task Estimation enables the Scrum Team to estimate the effort required to complete a Task or set of Tasks and to estimate the human and other resources required to carry out the Tasks within a given Sprint. In the Task Estimation Workshop, the Scrum Team members use the Task List to estimate the duration and effort for the User Stories to be completed in the Sprint.
One of the key benefits of this technique is that it enables the Team to have a shared perspective of the User Stories and requirements, so that they can reliably estimate the effort required. The information developed in the Task Estimation is included in the Estimated Task Effort List and it is used to determine the velocity for the Sprint.
In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. All the techniques in Chapter 10 can be used in this Workshop.
The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being Story Points and Ideal Time. For example, an Ideal Time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s Deliverables, without including any time spent on other activities or work that is outside the project. Estimation Criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.
