The Sprint (Part 1/2) – Introduction and Rules

We’ve arrived at the part of Scrum where real work gets done. The Sprint! The Sprint is where people get down to business and apply their funky stuff. They architect the software, code it, design it, test it. Repeat that. They wave their arms in joy and frustration. They turn requirements into working software.

At the start of our Scrum series, I stated that Scrum is a lightweight and simple process framework with minimal load and overhead. While this statement still holds up, it is also true that rationale behind every Scrum mechanism is a bottomless well. You can get started with Scrum, reaping many of its benefits quickly. Anyone can grasp the mechanisms with a minimal of introductory coursing needed. On the other hand, you can spend months or even years to really understand their consequences and power. We for our part are not through analyzing Scrum for rationale and benefits. We’ll keep on doing that until we’re Scrum ninjas. And I mean ninjas with a capital N. Ninjas. Now you see us, now you don’t.

A quick recap of events. (What have we done before starting The Sprint?)

We’ve spent time with the customer constructing the Product Backlog. This establishes an understanding of what to create. We’ve gathered The Team and stakeholders to pick an amount of items from the Product Backlog to commit to for the sprint. We spent 4 hours doing this. Then, the team has broken down the items into tasks and created a Sprint Backlog (another 4 hours). Now, The Sprint has started.

So that’s all there was to it. The team has done 8 hours of work to prepare for The Sprint itself. What has not been planned or resolved during these 8 hours, The Team is responsible elaborating during The Sprint.

There are two main topics about The Sprint

There are two main topics to discuss regarding The Sprint. I’ll address rules in the remainder of this post, and proceed to talk about the Daily Scrum in a post that will follow the day after this one airs.

Sprint Rules

The Sprint is time-boxed to one month. This is the minimal amount of time needed to create a significant increment of potentially shippable software. Also, it is the maximum time that can be allocated without The Team doing so much work that we loose overview and have to start making documentation and artifacts to support the process. We want to avoid that, as only it adds to the load, so we’ll stick with the one-month iterations.

No one can interfere with The Team during the sprint. It is utterly self managing. The Team can seek advice and help as they want, however. The only way to interfere The Sprint is to terminate it. Stop it dead in its tracks. Then we’ll start over with a new round of Sprint Planning. This rule really makes anyone wanting to disturb the flow of the team, think twice about demanding them to change their plans, as its implications are made very obvious and dramatic. This is necessary.

The sprint can be terminated if The Sprint has become non-viable, or of little of no value due to changing requirements.

If The Team feels they have too much, or too little, to do during The Sprint, they will consult with the Product Owner on which items to remove from, or add to, the Sprint.

The Team is responsible to keep the Sprint Backlog up to date. (At Aptoma, we have developed web-based in-house software to support this (and every other) activity in Scrum. Our software increases visibility and simplifies day to day registering and planning. We call it AptoPappa, as it is so kind as to look after us and our Scrum activities. We might just show it to you one of these days.)

These are almost all, and certainly the most important rules of The Sprint in Scrum. Stay tuned for more on the Daily Scrum, an imperative activity in The Sprint, and in Scrum as a whole.

PS! One of these days I’ll do a post with no links to our RSS-feed, but it will be only one post, and it will be years into the future.