At the start of each development iteration, your team must create task plans for each team member to complete during iteration.
The task plans must be entered into the mX-task-plans document (where X is the number of the milestone the plans are for).
Each team member must add task plans to the document such that:
At Least 10 Hours of Work per Team Member per Iteration: Each team member should plan tasks that total at least 10 hours of work for each iteration.
At Least 2 Tasks per Team Member per Iteration: Each team member should have at least two tasks assigned to them. Having more than two tasks is perfectly fine.
Cohesive Tasks: Each task should be cohesive in that it is nicely focused on a particular functionality or closely related set of functionality. A task should not include unrelated things. Tasks that lack cohesion can be broken up into separate, more cohesive tasks. Smallish tasks are OK in such cases.
For each task plan in the document, the following fields must be filled:
Task Title: A short title that concisely captures the work to be performed in the task. Task titles must be unique.
kabob-case. It is recommended that it be prefixed with the name of the team member performing the task (e.g., alice-blah-blah).Here are some additional criteria for the task plans:
Everybody Codes: For each development iteration, each and every team member must take on substantial coding tasks (although it’s possible to have some tasks that don’t involve coding).
Everybody Must Do Work on the Model: For each development iteration, each and every team member must do some substantial work on the model (e.g., creating new model classes and creating new model class associations).
No Shared Task Assignments: Do not assign a task to more than one team member. Although team members are encouraged to collaborate, the responsibility for completing a particular task must lie with one and only one team member. Teammates who assist on a task can be credited in the task reflection.
Tasks Must Yield Project Artifacts: Generally, you should specify only tasks and subtasks that yield project artifacts. For example, you should not have tasks/subtask that involve only learning about something, and
No Learning-Only Tasks: It is assumed that team members will need to put effort into learning new technologies during the project. However, such effort should not be specified as a task. Generally, only specify tasks that yield project artifacts.
No Communication Tasks: It is assumed that team members will put effort into team communication and coordination each iteration. These types of effort should not be counted as tasks. Generally, only specify tasks that yield project artifacts.
Once you have successfully merged a pull request that completes a task, you must report the outcome of the task.
The task outcomes must be reported in the mX-task-outcomes document (where X is the number of the milestone the tasks were completed for).
For each task outcome in the document, the following fields must be filled:
Task Title: This should generally match the title given in the task plan. For tasks that pop up unexpectedly after the task planning was completed (such as debugging tasks), the title need not appear in the task plan. For such unexpected tasks, add “(unexpected task)” to the title.
Task Outcome: The best characterization of the task outcome must be selected (Completed, Partially Completed, or Not Started). Additionally, some clarifying text should be added to explain the outcome selected.
Time Spent on Task: Give a best estimate of how long you spent actively working on the task. Round to the nearest half hour.
Pull Request(s): List the URLs for the pull requests that correspond to the completed task work.
User Stories Supported: List the user story IDs and titles of the stories that correspond to the features completed in the task.
Note that if you did not complete a planned task, the task should still be mentioned in the outcomes document (with a Task Outcome of Not Started).
Scored out of 20 possible points.
Half of the points (up to 10) will be for the task plans.
Missing Plans: A deduction will also be taken if task plans are missing for a team member. If there are N team members, then 1/N of the 10 points will be deducted for each team member with no task plans. For a team member with only 1 task plan, half of the deduction will applied (since a minimum of 2 plans are expected).
Defective Plans: After the above missing-plans deduction is applied, the remaining score will be calculated as the percentage of task plans that are free of blank or incorrectly filled out fields.
Late Plans: Because creating task plans at the beginning of an iteration is an important part of the iterative development process, a deduction will be assessed for late plan submissions. For every 24 hours past the due date, a 1-point deduction will be assessed.
The other half of points (up to 10) will be for the task outcomes.
Missing Outcomes: A deduction will also be taken if task outcomes are missing for a team member. If there are N team members, then 1/N of the 10 points will be deducted for each team member with no task outcomes. For a team member with only 1 task outcomes, half of the deduction will applied (since a minimum of 2 outcomes are expected).
Defective Outcomes: After the above missing-outcomes deduction is applied, the remaining score will be calculated as the percentage of task outcomes that are free of blank or incorrectly filled out fields.