Scrum is one of several agile project management methodologies, which is named after the practice in rugby, where a team huddle together in order to beat an opposing team. One of the central ideas of scrum is that a team has to work hard and pull together in the same direction.
Scrum is a set of interrelated practices and rules that optimise development environments, reduces organisational overhead, and closely synchronise market requirements with iterative prototyes. Based in modern process control theory, Scrum - when it works well - causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every x days (often 30 or 14) as requirements, architecture, and design emerge, even when using unstable technologies.
Whereas Scrum deals primarily with process and project management, it is often efficiently combined with other practices, especially test-driven development and extreme programming.
This article aims to explain some of the main terms in broad terms, and will be followed with further exploration into each of these terms as time permits.
User Stories
All technical functional requirements of a piece of software are captured as user stories, which serves as a request and outline of a piece of functionality.
User stories are formulated as a mini-story which represents a need or requirement from a user (“As an administrator, I want to be able to disable content flagged as offensive by site users, because this is a legal requirement, and because having a ‘clean’ site improves the user experience”). Good user stories are independent of others, negotiable, valuable to the business, small enough to estimate properly, and it has to have success criteria built in.
Product Backlog
The product backlog can be seen as the wishlist for the current project, and consists of all the user stories that are currently being considered for implementation.
The backlog is ordered by priority, and when planning a new sprint, the theory is that the Product Owner would pick user stories from the top of the stack, which means that the most important work is always completed first.
The Product Owner is responsible for taking the requirements and ideas from the project stakeholders, and keeping the product backlog in order of priority.
Sprint Planning
A sprint is a single x-day cycle of development of the project, and the idea is that we end up with a new increment of the website at the end of a sprint. A sprint might contain work which improves current functionality, new functionality, and bug fixes on old functionality.
Before the sprint planning meeting, the team figure out what their velocity – or the number of story points the team can do per sprint.
In the Sprint Planning, the development team work with the Product Owner to estimate and plan the upcoming sprint. This is done by taking stories off the top of the product back-log, and re-estimating the number of story points each story takes, based on the work it would take to complete the stories.
The team considers the complexity of the site as it stands, the complexity of the development and design which is required, and will come up with an estimate for how much time a particular story will take.
Sprint
When the whole sprint has been planned full of stories that need to be worked on, the team commits to the sprint, and go off to spend the next 2 weeks delivering the work they have committed to.
Once the sprint has started, its scope is fixed, and can no longer be changed. This means that other work that comes up while the iteration is in progress, needs to be scheduled into the next iteration.
Sprint review meeting / Iteration demo
In a sprint review meeting, we show off the functionality that has been completed over the past sprint to key stakeholders, and will give enough time for people to ask questions, offer comments, and get to grips with the release better.
After the sprint review meeting, the development team does a retrospective to find out what went particularly well (or badly) during the past sprint, and then they launch into a sprint planning meeting again.
Scrum team
The make-up of a scrum-team is complicated enough to warrant a series of separate articles, but in very short, it consists of a Scrum Master, who is responsible for ensuring that Scrum's principles are followed properly, and to remove any impediments that are in the way of the team.
The scrum team are the people who are actually working on the product on a daily basis; the engineers who are getting the work done.
The final role in Scrum is the Product Owner - this is a complicated role, as s/he is the person who decides what the team is working on next by keeping the product backlog prioritised.