Planning happens at the beginning of every Sprint. Stories are placed into the backlog and prioritized by the Product Owner. The team estimates complexity points for each story, and also makes a best guess at the velocity from either a known value, or from estimating how many of the stories can be completed during a Sprint. The team makes a commitment to do their best to complete all of the work included in the Sprint.

The Sprint begins by working from the top of the backlog and progressing down. Developers should always choose a story from the top and not in the middle or at the bottom of our backlog, as the stories are prioritized for a reason (business value). Since no one person on the Scrum team has an assigned role, everyone is responsible for getting the work done.

Every day we have a meeting before we begin work, to answer the following questions:

1. What did I do since the last meeting?
2. What will I commit to working on next?
3. Am I having any blockers or problems?

It is crucial that each team member makes a public commitment to getting something done, so that the entire team is taking responsibility for the Sprint.

The features are demo'ed for the Product Owner, who then either accepts or rejects the stories. It's best to have the Product Owner(s) review the features as soon as they are deployed to the server. This ensures that stories will be accepted by the end of the Sprint, and won't bleed over into the next one.

After every Sprint, the Team Members and Scrum Master have a meeting, to answer the following questions:

1. What went well?
2. What could be improved?
3. What actions can we take in the future to maintain high quality work?

We like to make a big poster on the wall to remind ourselves what actions we've collectively decided taking forward into the next Sprint (cf. Kaizen). We also periodically have our Scrum Master retrospect with the Product Owner, to see how our working relationship can be improved.

• Shepherds the team into self-organization.
• Makes sure the team is running smoothly and on track for the Sprint, by tracking and removing impediments.
• Communicates progress with the Product Owner.
• If something will take longer than expected, meets with Product Owner to determine what can be done to complete the sprint e.g. simplify or remove features.

• Adds new features to the backlog.
• Keeps backlog up-to-date and prioritized.
• Gives feedback to the team: accepts or rejects stories after they are completed and demonstrated.

• Developer, designer, QA tester, etc.
• Assign story complexity points.
• Commit to and complete tasks.
• Keep the time remaining up-to-date on their tasks, so the burndown chart will be accurate.

The period of time necessary to deliver a committed amount of functionality; typically 1 week, 2 weeks or a month.

A high-level feature description; often expressed in the following syntax:

As a [role], I want [feature], so that [value].

Dan North wrote a fabulous article about User Stories and Scenarios.

During a consensus voting process (cf. planning poker), Stories are assigned complexity points relative to each other. This is most easily done by singling out the easiest and most complex stories to establish a range. We prefer to use a nonlinear (quasi-Fibonacci) scale.

The number of Story Points your team can deliver in an Sprint. You must guess this number initially when there is no historical data for your team. After several sprints, you will know your true average velocity and be able to project milestones with confidence.
N.B.: This number will change if Team Members are added/removed from the team.

A list of Stories, prioritized by the Product Owner in order of business value.

A chart that plots how the team is tracking to the Sprint goals. A daily snapshot of the number of hours remaining for each task. In order for this to be accurate, Team Members must keep the estimates (shown in red on the task card when they are due) up-to-date on a daily basis. More info here