Let’s follow with our SCRUM series… dealing with sprints.

We can say SCRUM’s sprints are something similar to XP’s iterations, although with several differences.

We could define a sprint as the total amount of time that development team has in order to implement, document and test a set of new functionality (this set is called “increment”). At the end of the sprint, we should have a ready-to-use, shrinkwrapped version ready to be delivered to any customer.

Typically, one sprint is split in three phases:

1.- Planning: a meeting with product owner together with development team with next goals:

• Set sprint’s duration: it shouldn’t last more than 30 days in order to don’t delay that stuff never should be delayed: the periodical deliveries. We usually work with 1-2 weeks sprints, but cheating, because we aren’t released “ready-to-use” versions, but internal versions (with lack of documentation, more exhaustive tests, etc.). Our failed subject is to achieve 3-4 weeks sprints (perhaps with one middle checkpoint) to get one ready to deliver version. Don’t worry Juan, we’re working on (:

• Choose a set of features to be implemented, in other words: the increment. The product owner will be choosing different user histories from product backlog and suggesting them to development team. At that time, development team should identify and estimate all concrete tasks necessary to implement chosen feature. Moreover, dev team should identify possible dependencies between features and warn to product owner. Let’s see it:
  
  - Product Owner (PO): well, I think we should implement the level editor’s undo/redo feature.
  - Development Team (DT): let’s see… this feature isn’t hard; we can use a mix of Command and Memento design patterns. It could be split in next tasks: a) create Command classes for different level editor’s actions. B) Create Memento class for level and c) give user interface to handle this. We can estimate them with 8, 5 and 6 hour respectively.
  - PO: OK, so we have assigned 19 hours of sprint. In the other hand, I’d like to use hardware acceleration for our levels renderers… We’ve realized it’s quite slow when we have a lot of objects.
  - DT: Wait a minute… that has been tried to do for isommetric renderers and we realized we should decouple the code before it. If you don’t do it, the change is to heavy and complex.
  - PO: OK, I had no idea about that. So… we have to refactor the code before implement hardware acceleration, right?
  - DT: Yes, we have to create new classes and test whole engines.
  - PO: All right. How many hours it will take?
  - DT: In one hand we have to refactor 3 or 4 classes and write unit tests, so let’s say two days. In the other hand we should research about VolatileImage class and apply that to all renderers classes, so 2 days more.
  - PO: OK, then we have 32 hours more which means we have assigned 52 hours.
  - DT: Something more?
  - PO: I’m, afraid rendering changes will take a lot of time to be tested for all handsets, so let’s reserve 2 days for testing and one more for update whole user documentation.

All these tasks will be noted down in one new spreadsheet called “sprint backlog”. We don’t note new features (user histories), but it turn into concrete tasks (refactor X, research Y and so on).
In sprint backlog we’re going to write the amount of hours remaining until each tasks was done.

2.- Implementation: once we’ve get our sprint backlog, we can start the development. Both parties (product owner and dev team) should agree they can’t add new tasks until sprint ends. If one new feature comes up, it will be added to product backlog and it will be taken into account for next sprint.
Everyday during sprint development, whole dev team will meet to review the progress and up to date the sprint backlog. This is the “daily meeting” and we’ll tackle it next day.

3.- Review: once the sprint has been completed, product owner and team will meet every other interested part (marketing people, customers, etc) and an informal demo will be done to show new functionality (called “increment”). During this meeting could arise one or more new features and them will be noted down at product backlog.

In the other side, dev team will meet themselves and will think about:

• What things went right and should be keeping up?

• What things went bad and could be improved?

For instance:
- Tony: we’ve failed with new renderers test.
- Johnny: yes, it was a sheer hell
- Tony: As soon as we have some free time, we should research how we can automate it.
- Johnny: yes, I note it down to add it at next sprint.
- Tony: By the way, undo/redo prototype feature went really good.
- Johnny: it’s true. It was a good thing that we spend a couple of hours writing a small prototype in order to prove whether Command and Memento design pattern works as expected.
- Tony: OK, next chances we can use prototypes too.

Next day we'll talk about daily work of one sprint and the daily meeting.