Scrum is an Agile project management framework used for product development, especially software development which encourages all members of a team to get involved. It can be applied to any project with complex requirements and allows large tasks to get done by breaking them up into smaller parts known as sprints. Scrum also allows product owners and managers to monitor progress by the use of a simple Kanban board and burndown chart (more on these later).
By David Groves
So how does it compare with the ‘traditional’ method?
Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like:
- Gather and document requirements
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
In a Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. There is also typically a stage gate between each; for example, requirements must be reviewed and approved by the customer before design can begin.
Of course, one obvious problem with this is … what do your developers do when the project is outside of the ‘code and unit test’ phase?
Scrum on the other hand is an iterative, team-based approach to development. This approach emphasises the rapid delivery of an application in separate complete functional components. All time is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, agreed at the start of the sprint.
Deliverables are prioritised by business value as determined by the customer. If all planned work for the sprint cannot be completed, work is reprioritised and lower priority items are put back in the product backlog for a future sprint.
As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project, but especially during these reviews.
What are the advantages to an ‘Agile’ approach like ‘Scrum’
- Transparency – Stakeholders and management can be much more involved throughout the project from prioritising features, iteration planning, trying nightly builds and following progress on burndown charts and Kanban boards.
- Predictable Delivery – Because Agile provides a timeboxed fixed sprint, features agreed up front are delivered frequently and at an agreed time.
- Predictable Costs – Sprints are fixed duration and can provide a fixed costs framework for new feature requests.
- Early delivery – Clients may declare that software can be delivered for use at the end of any sprint if required, although with a reduced feature set.
- Flexibility of changes – Clients can add any number of new features into a backlog to be included in the next sprint. These do not need to be agreed up-front as in a more traditional software development framework.
- Focus on Users – Agile commonly uses user stories to define product features. By focusing features on the needs of real users, each feature incrementally delivers business value.
- Quality – By breaking down the project into manageable units, the project team can focus on high-quality development, testing, and collaboration. Frequent builds, testing and reviews during each iteration improve quality and identify defects early.
An introduction to Scrum would not be complete without knowing the Scrum terms mentioned in this blog:
Scrum team: A typical scrum team has between five and nine people, but Scrum projects can easily scale into the hundreds. Additionally, Scrum can easily be used by one-person teams and often is. This team does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”
Product owner: The product owner is the project’s key stakeholder and can be someone from product management or marketing, or maybe a key user.
Scrum Master: The Scrum Master is responsible for making sure the team is as productive as possible. The Scrum Master does this by helping the team use the Scrum process, by removing impediments to progress, by protecting the team from outside, and so on.
Product backlog: The product backlog is a prioritized features list containing every desired feature or change to the product. To clarify, the product backlog is a list of desired features for the product. The sprint backlog is a list of tasks to be completed in a sprint.
Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held, during which the product owner presents the top items on the product backlog to the team. The Scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to a sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.
Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.
Sprint review meeting: At the end of each sprint, the team demonstrates the completed functionality. Typically, this takes the form of a demonstration of the new features, but in an informal way. PowerPoint slides are not allowed!
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint retrospective, which is a meeting during which the team (including its ScrumMaster and product owner) reflect on how well Scrum is working for them and what changes they may wish to make for it to work even better.
Kanban: A simple task board (electronic, paper or whiteboard) which clearly shows the items in the sprint backlog, an estimation as to how long to complete and their current status (not started, in progress or complete for example)
User Stories: A means to explain a new feature set in a human readable form using a ‘As a <role> I want <feature> so that <benefit>’ template. For example ‘As a user with a reservation, I want to cancel my reservation so that I get a refund’
Burndown Chart: A graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed.
The Scrum Framework as a picture
As part of your Sprint Planning Meeting, you will need to estimate the work for the sprint. Remember, the work in the sprint backlog has been guaranteed for delivery! If you don’t know how long it is going to take, you cannot tell if you have enough man-hours to complete, and therefore if you can guarantee to complete it!
In its simplest form, this will be a case of taking an item from the sprint backlog, splitting it into a number of tasks, and collectively estimating each task.
If the sum of the task estimates is greater than the amount of man-hours available for the sprint, then something has to go back to the product backlog. This is a job for the Product Owner.