Sprint week


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.

Advance planning

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.

Day 1: Sprint meeting

All 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:

  1. 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).
  2. Decide on the set of stories that could be tackled within this week (that means, could be completed, including demoing/testing, by Friday).
  3. Discuss the testing implications: what are the criteria for completing the story and how (and who?) will verify it?
  4. Discuss any dependencies between tasks - will this cause problems? How will required communication be ensured?
  5. Discuss whether any specialist skills are needed, and who has them? How can you optimise the use of specific people's time?
  6. 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").
  7. 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.

Home : Teaching : Courses : Sdp 

Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh