Sprint Planning

One of the requirements for your team to do well is for them to follow the defined software development lifecycle for the course. Work for the semester will be broken down into four "sprints", and at the end of each sprint, the team should have some complete artifact to demonstrate the progress in that sprint. Often this will be a demo of the code, but in the event that the project has atypical requirements, this may be a presentation of research results, or of components like 3d models or datasets. In all cases, they should be able to show how their artifact relates to the goals of the sprint and overall project, and talk about how it reflects the requirements and tasks created in the project scrum board.

Naturally, this means you will need to help them out by determining what the semester and sprint goals are, and helping align their work assignments to align with those goals.

Defining Goals and Deadlines

There are three "levels" of goals for the project - an overall goal or vision that you established during the Project Definition phase, a set of feature objectives for the current semester, and a set of feature objectives for the current sprint.

The goals for the overall project are unlikely to change much, but the specific goals for the semester and for each sprint may be more dynamic based on unexpected events, experience level of the team, etc. This leads to the classic "Cone of Uncertainty".

It's OK if the semester goals change based on coniditons on the ground, but sprint goals should be relatively firm. Ideally, they will all be related features, to help with the presentation they need to do at the end of each sprint.

High Level Sprint Goals

While each project may have minor variations depending on if this is a new or mature project, each semester is likely to have similar "groupings" of effort.

• Sprint 1 : Focus is on definition and design. What are the goals for the semester? What will the outcomes look like? How will we determine if they are achieved? Does the team understand the vision of the project?
• Sprint 2 and 3 : Focus is on development - executing tasks that build into features.
• Sprint 4 : Focus is on delivery, documentation, and planning for next semester. Is the team ready to present their work? Have they updated all system documentation? Do they have a list of lessons learned, next steps and recommendations? Have they created a plan for onboarding new members?

Planning for the Next Sprint

At the end of each sprint (or the start of the first), you should be looking through your user stories to determine what you want the team to work on for that sprint. Have the team move those stories into planned. This will set expectations for the current sprint, and provide a metric to see how close they came to the goal. If you find that there is only one (or a very small number) of stories planned for a sprint, you may want to consider breaking some down into smaller features, so that the team can demonstrate progress.

Dealing with Reality

Sometimes, things don't go according to plan. In the event that priorities change, work is more difficult than expected, or something turns out to be impossible, that's still OK. If you need to take more than one sprint for a story, it will just get tagged with the following sprint as well. If you need to abandon a story, you can move it back into the "backlog" as a historical footnote.

Preparing for Evaluation

It's a good idea to keep an eye on the calendar so you know when each sprint is ending. This should trigger a planning discussion in the weekly meeting before sprint end, when you will pick tasks to work on next sprint. It should also give you a spot to have the team tie things up so that they can demonstrate progress. The course coordinator will make every effort to help remind you, and if you have a student project manager they will as well, but it helps you help them to keep an eye on that cycle.

Winding Down

At the end of the semester (during sprint 4), it's a good idea to reserve some time for the team to work on any necessary transition documentation. If students are leaving the project (graduating, or otherwise moving on) having them make sure that they don't have unmerged code, that they've updated any relevant readme's or notes sections, and have walked their teammates through their work in progress goes a long way towards smooth transitions.