Plan a Sprint#

It’s always tempting to rush into coding, but you should always have a planning meeting at the start of a sprint to make collective decisions on what needs to be done.

You have specific things that you should do in preparation for the next sprint. These should be done in a single meeting, as soon as you can after the demo is complete.

A great idea is to run your planning meeting within a day of your demo. Discussing it early will keep your momentum going.

Make sure to record meeting minutes and store them in your project! You will make important decisions in these meetings, and the minutes will help you remember details.

Retrospective#

If it’s your first planning meeting, this section won’t apply. However, if you have just completed a sprint, you should be in this position:

• You have just completed a software release, with documentation.
• You have shown it to a user (TA, instructor), and received feedback.

Take the time to discuss feedback and use it as input into the next sprint.

Things to consider.

• Did anything go wrong in the demo that you need to address? e.g., it crashed?
  • Take the time to log a new task to capture what you need to do to address it.
  • Discuss the priority and when you think you should address it.
• Did your user make any suggestions on changes they think are important?
  • Again, log a task in GitLab to capture the feedback.
• Is there anything that you think you should do differetly as a team?
  • Look for areas where you can improve and work together more effectively.
  • e.g., “it would have helped me if I’d known that Jared was working on X; maybe we should talk about how to coordinate work better”.

Planning#

The second part of the meeting should be a planning exercise, to determine what you will work on in the upcoming sprint.

By the end of the meeting:

• Your team should agree on what is being done during the sprint.
• Tasks should be updated to reflect what you’ve agreed upon.
  • Work items are assigned to the milestone. Other items are unassigned or tentatively assigned to a later milestone.
• Items are assigned to team members. The ONLY items assigned to you are the ones that the team agreed to work on.

Things to consider when assigning work.

• Is there something that is very risky?
  • Investigate it early in the project to minimize a risk e.g., you want bluetooth support and you don’t know if it will work.
• What are the highest priority items? Do these first.
  • These are often either foundational (e.g., connecting to the database) or will take a long time to implement (e.g., building your first GUI).
• Consider feature dependencies. Some features are important because they enable other later features.
  • e.g., pulling in data from a web service might be high priority if that data is used by 2-3 other features.

One challenge in this course is that something that is easy for one team may be difficult for another team, based on the team’s experience, or the peculiarities of your project.

If you have identified something as urgent, you can “skip ahead” in the lectures, or ask for help! Don’t wait until week 10 to add database support if you need it in week 4 to make progress on other features.