The aim of this week is to plan and experience a sprint as practiced in Agile programming.
Note that the work you put in this week is not meant to be in addition to the total hours for SDP expected through the semester. Rather, it is a chance to put in concentrated work now, without the usual distractions of other courses, so that the work remaining for SDP for the rest of the semester should be manageable, relative to the time needed for your other courses.
In industry, a sprint should deliver a potentially shippable product increment, i.e. a coded, tested and usable advance of the system. Keep this in mind for your planning - you need to be realistic about the advance possible within one week of work. A simpler task that is fully finished will be more satisfying than a more complex task that is only half-complete.
If at all possible, before the meeting on Monday, there should be a pre-meeting to generate a set of stories (see below); estimate the workload for each (see below); if necessary, subdivide stories so each is a manageable load; and put these in priority order.
This meeting could be held virtually, e.g., via Slack. It should at minimum involve the managers of the two groups who are going to form a team, but can be open to anyone who wants to participate. The groups should also share their Process Reports with each other as a useful starting point to generate some stories.
Related to a 'use case', an agile user story describes some feature of the desired system from the point of view of the user, in a simple and concise form such as "As robot handler, I want to be able to stop and start the robot easily, so that I can follow referee instructions", or "As the robot, I want to make a predictive update of the position of other robots on the field, so that I can deal with noise in the visual tracking". (Note the general pattern - who is the user, what do they want, and what purpose would that serve?)
If a story is too large, it is an epic, and needs to be broken into smaller stories: a useful story should be clear, feasible to implement, and testable.
- Workload estimation:
A popular approach in Agile is to use the 'planning poker' method; for each story, all meeting participants make an independent estimate of the amount of work involved, using an exponential scale: 1, 2, 4, 8 etc. Note that the scale is relative, it is not meant to map onto hours of work or the like, but rather to allow identification of stories that are too large (and should be broken down) or to determine what looks reasonable to expect people to complete. After the independent scoring you can discuss and come to a consensus on the appropriate workload for each story.
Day 1: Sprint meeting
students should attend this event, on Monday 20th February, from 9:30 to 12:00, in LT1 Appleton Tower.
The session will start with an overview from the course organisers of what you are expected to accomplish in your sprint meeting, and during the week. Here are the slides.
You will then meet in your teams (=2 groups). We will suggest a few short activities you might use to get to know each other a little better.
A sprint meeting should be an in-person meeting with the entire team present, as it is important for you all to take ownership of the decisions on which tasks to pursue, and who should pursue them. You need to do the following:
- Start by jointly viewing the list of stories - probably easiest to do if you write each one on a card and lay them out so everyone can see. There should be some flexibility to add to the story list, to revise workload estimates or to rearrange priorities, but try to limit the time spent on this (this should have mostly been decided in the pre-meeting).
- Decide on the set of stories that could be tackled within this week (that means, could be completed, including demoing/testing, by Friday).
- Discuss the testing implications: what are the criteria for completing the story and how (and who?) will verify it?
- Discuss any dependencies between tasks - will this cause problems? How will required communication be ensured?
- Discuss whether any specialist skills are needed, and who has them? How can you optimise the use of specific people's time?
- Revise the story list given the above considerations, then allow team members to select tasks. They might usefully choose to do something together (e.g. someone might say, "I can do this, but would need someone who can help me with that aspect of it").
- If there is a task that seems necessary, but no-one wants to do it, dig deeper to find out if it must be done, or if there may be an alternative way to approach it to make it more interesting, or an incentive that can be offered to whoever volunteers.
Typically this meeting can take up to two hours. You might want to take a break in the middle (e.g. try another team-building exercise).
At 11:30 we will all gather again as one class to discuss any questions arising, and in general get feedback on the course progress so far.
Days 2-5: Daily scrum
You should arrange for the rest of the week to meet daily as a team, preferably near the start of each day, for no more than 10-15 minutes, standing up, to discuss progress. Each person should briefly state what progress they have made since the day before, what they hope to get done before the next day, and raise any issues that are preventing them from completing their story. Don't get into lengthy discussion of how to solve a problem, but rather arrange a follow-up discussion for those concerned to try to sort out the problem, rather than extend the scrum duration for everyone.
Day 5: Sprint review & retrospective
As the sprint should have produced a coded, testable and usable advance, this should be a group meeting at which you demo to each other the new features that the team has accomplished. You may also want to hold a 'retrospective', to reflect on how well the sprint has worked, and what you need to do next. Your mentor will ask you about the outcome at the next meeting.
Return to the course webpage.