SE-2800 Software Engineering Process
Sprint 2 Planning and Execution

Outcomes

Assignment

In this assignment, you will plan a sprint whose goal is a fully tested and deployable version of the GPS Analyzer application containing the additional functionality specified by user stories indicated by your instructor for your specific team, as well as corrections to all defects remaining in user stories done in SE2030, and possibly other items (Internal Improvement and Knowledge Acquisitions).

Sprint Planning consists of determining the subtasks needed to complete each PBI (whether that item is a User Story, Defect, etc) that will be completed in the upcoming sprint, along with an hour-estimate for the time needed for each subtask. Subtasks consist of both development and non-development activities (more information below).

Activity

First, make sure that the simulated sprint 1 has been closed. Next, create sprint 2 and move your assigned PBIs into it (your instructor may have already done this as Product Owner). Enter subtasks into Jira for these PBIs, describing all activities that will be needed to design, implement, and test them.

When planning these activities, do your best to estimate the time required for each activity, but do not worry about getting these times too precise. You are not graded on estimation accuracy or precision!

You may need separate subtasks (remember, each subtask is generally done by 1 person) that cover:

  - Rewriting the use cases (perhaps 1 subtask for the normal flow, and 1 subtask for each alternate flow).

  - updating the high-level sequence diagrams (again, 1 subtask for the normal flow, 1 subtask for each alternate flow, 1 subtask for each UI mockup)

  - updating the low-level class and sequence diagrams

  - figuring out what approach/algorithms to use to compute metrics (e.g. distance) or how to graph the path

  - implementing the additional functionality in the various classes (1 subtask per class)

  - writing unit tests/creating test files

  - running unit tests

  - testing the UI (e.g. making sure that only valid entries are accepted - something that unit tests can't easily do). You can break this down into multiple test tasks that can then be distributed among team members

  - testing the entire system as built (e.g. making sure that the entire application works as it should; you can also break this down into multiple test tasks to distribute among the team)

Starting the Sprint

**After** you have entered the subtasks, start the sprint, specifying an end date corresponding to 8am on the first day of class (Tuesday) during week 7.

Note: If you start the sprint before the subtasks hours are estimated, the total estimated hours in the sprint will be incorrect.

Discuss and assign all subtasks to various members of the team. Assignments can change later, but you should initially have some idea of who will do what.

Once you start the sprint, all PBIs and their subtasks will be in the "Ready" state. Decide which PBIs you will attack first.

Discuss and decide what subtasks will be worked on first. In Jira, using the Agile Board, move those subtasks from the "Ready" column to the "In Progress" column.

You may want to begin by working on the "Design" and "Test" subtasks (assuming you have one): reviewing the use cases, UI mockups, and UML diagrams you created in SE2030.

Sprint Plan Grading

See the page Sprint Rules and Grading for how the entire sprint (not including planning) will be graded

Your grade for your sprint plan will be based on the following:

  1. Plan entries must be correct: for example, every PBI must have child tasks that fully detail what activities must be done in order the fully implement and validate the functionality described by the PBI (review the above guidelines).
  2. Every task must include a reasonable amount of detail in its description so that it is clear what it is for.
  3. The entire sprint plan must be in place by the end of lab.