Sprint Planning

Sprint 1 Planning

From this point forward, your Trello board should show regular ongoing planning activities in the form of team members making appropriate assignments to and from stories, and stories moving through lists in the planning board to the Sprint Done list.

Stories moving immediately to the Sprint Done list shortly before the sprint submission is NOT evidence of regular ongoing planning activities and will affect your team/individual grades.

Previously, you may have been required to add, as best you could user stories, to your backlog. This preliminary work where you identified user stories with the short card title, and the full user story text in the proper format should continue to be refined over time. You may have also been required to define acceptance criteria or solution tasks for these stories.

In this Elaboration phase, the project planning starter Trello board which provided you with initial Sprint Backlog needs to be improved upon by adding/expanding on the remaining user and spike stories that you identified for the rest of the project and any enhancements that your team is considering implementing. Although the enhancements are not to be your focus until further sprints. Seek clarification from your instructor as to when these are to be polished and delivered.

Again, you need to make sure to add any missing elements in the provided stories which were not fully defined and get your Trello board in the best shape possible. This includes acceptance criteria, acceptance tests, and solution tasks

As a team review the Sprint 1 Grading Rubric and deliverables.

Sprint 2 and 3 Planning

Sprints 2 and 3 are the Construction Phase of the project when the full functionality of the product is built out. Each of these sprints will be three calendar weeks long. At the start of each of these sprints, the team needs to decide which user stories it will commit to the Product Owner to complete. Only stories that have been estimated can move into the Sprint Backlog up to the limit of the team’s sprint capacity, i.e. velocity. To estimate a story, the Acceptance Criteria and Solution Tasks must be defined. Teams need to have a history to be able to reliably determine the team’s velocity.

For this project, the project teams will not be working together long enough to develop that history. Velocity is typically calculated as a running average of the number of story points completed in the last three sprints. You will make your best estimate of each story and how many story points you can commit to for Sprint 2. You will then use your team’s actual performance as a data point when creating your Sprint 3 backlog.

The last functional deliverable for your product is your Sprint 3 submission.

Sprint 4 Planning

Sprint 4 is the Transition Phase of the project. There is no further feature, i.e. user story, development. The activities in this sprint are related to closing up the project. These activities include:

• Creation of the final design documentation for the project. This design documentation will describe your final design, provide an analysis of the code metrics report, and discuss the quality of your design along with recommending future refactoring and other design improvements based on your metric analysis and review of the design against the object-oriented design principles covered in class and those your team selected to focus on from the beginning.
• Making a final project presentation

Your planning for Sprint 4 will involve creating Trello cards for tasks related to the activities above. You do not need to assign story points to these task. These tasks should be at a level that each activity has multiple tasks associated with it so that more than one team member can be assigned to work on the activity. For example, the documentation would have tasks for different sections that could be assigned to more than one team member.