Sheila's Blog

In Scrum, a project is developed in a number of time-boxed iterations.  Each of these iterations is known as a Sprint.  A Sprint is usually 1-4 weeks long.  The team develops a number of requirements during the sprint, and at the end of each sprint the team is expected to deliver and demonstrate working software that is potentially shippable.  Any requirement that is not fully completed is not counted.  This makes it very clear when targets aren’t being achieved.

Sprint Length:
At the start of the Sprint, the team takes a set of requirements from the top of a prioritised list of requirements called the Product Backlog that’s maintained by the Product Owner.  In the Sprint Planning Meeting they decide how many of these requirements can be accomplished during the Sprint.  The length of a Sprint is determined by how confident a team is and how much uncertainty, newness or risk is involved.  If any of these are high, the sprints should be shorter.  However the length of sprints shouldn’t change too often to allow the team to improve estimates, so choose carefully.

Changing Scope:
In a Sprint, scope is the only thing that can be compromised.  Quality can’t be skimped on.  This is very important to avoid building software that is difficult and time-consuming to maintain.   If the team has over-committed they can consult the Product Owner and drop some lower priority items in order to fully complete the top priority tasks.  Likewise, if the team has under-committed, they can select more items from the backlog in consultation with the Product Owner.

Abnormal Termination:
This doesn’t happen often, but a Sprint can be abnormally terminated if the team feels they can’t meet the Sprint goals or the Product Owner finds external circumstances that cancel out the Sprint goals.  When this occurs a Sprint Review should immediately be held to review the reasons for terminating the Sprint.  Then the team should continue on to a new Sprint Planning Meeting.

Sprint Artifacts:
There are a number of artifacts that should be generated by the end of a Sprint.  They can be used to help improve estimates for future Sprints.

Sprint Burndown Chart – this is updated daily and shows the velocity for the Sprint.

List of impediments encountered – this is kept by the Scrum Master, logging impediments encountered and the steps taken to resolve them.

Relevant quality metrics – this includes things like unit test and code coverage reports.

Sprint Report:
It states the start/end date of the sprint, the team members available for the sprint, the number of working days planned for, versus the ones actually worked (noting sick days etc) and the story points planned versus the ones earned.  Each backlog item that was in the sprint is listed, and an outcome of complete or incomplete.  Finally, it logs the review action items for that sprint.

These artifacts – especially the Sprint Burndown Chart should be highly visible to the whole team.  A scrum team meets daily and at the end of that meeting the burndown chart should be updated so that everyone is  clear about how much progress has been made, and more importantly – what’s still left to do.  This allows the team to judge whether they can meet their committments for the Sprint and raise any issues that may prevent them from doing so.  The artifacts should show estimates improving and a sustainable velocity reached as a scrum team evolves.

Tags:   scrumNo Comments