What is Scrum?

Scrum is an implementation of a development process based upon the concepts in the Agile manifesto and the Agile principles. Scrum’s purpose is to provide a framework within which it is possible to plan, design, build and deploy complex working software that is fit for purpose, in priority order first.

The Scrum Alliance supplements the core Agile principles with the Code of Ethics. This can be found on the scrum alliance website.

Scrum is the most popular Agile implementation of a full development process. It supplies the types of roles that are in the team, the artefacts the team will need and the process by which they produce working software.

This page will give you a good overview of Scrum. Understanding how Scrum works is very important and you will almost certainly be asked about it in your telephone calls with recruitment agents and in your interview.

Certification

Once you have read this page and the materials listed in the further reading section, I recommend that you attend and complete a Scrum Master training course with Adventures with Agile. The cost of the course should easily be recovered with the additional amount you will be able to earn once you have the certificate. We also offer a self funding option. The course will also give you a very solid grounding in Scrum.

An introduction to Scrum

Roles

Scrum defines three roles, they are:

- Product Owner

The product owner is responsible for the delivery of the project. It is their responsibility to make sure the right thing is built and that it is built in priority order. They manage the most important artefact in Scrum: the product backlog.

- The Team

The team is made up of all the people responsible for building the solution. They will code, test, design and implement the deliverables for the project.

- Scrum Master

The Scrum Master’s role is to ensure that the Scrum process is followed and that everyone has what they need to do their job. They also can help protect the team from outside pressures and ensure the team gets the space they need to deliver the project.

For more details about these roles, please see the individual role pages on this site.

Artefacts

Artefacts are items that help in the delivery, design or management of a project. The artefacts used in Scrum are simple and vital to the success of the project. These are:

The project vision
Although not detailed in the above diagram, the project should have a shared vision. This is usually a brief description of what the project is about and what value it will deliver. The vision is what gives meaning and understanding at a high level to the individual stories in the backlog.
A story
Although not a recognised artefact in its own right, I think it is worth putting in here, as stories are fundamental to the Scrum process. A story is simply a sentence that represents some sort of requirement or value (feature) that the product owner would like to be developed. It is actually just a placeholder to have a conversation about the feature. Very large stories are actually the same amount of text as a small story. The size represents the likely number of features or effort to implement the story. Large stories are called Epics.When stories start their lives, they may represent a huge piece of work, such as ‘implement an ecommerce system’. These stories will later be broken out into more stories, each with a finer grained level of detail. This will only happen at the last responsible moment and usually just before developers are going to work on it.
The project backlog
The backlog is a managed list of stories ordered by the product manager in the order that the developers will work on them. This is usually contained in some sort of management application such as Jira, Microsoft TFS, Target Process or one of many others. The backlog contains all stories describing the project.
The sprint backlog
The sprint backlog is a subset of the project backlog and contains only what the development team are implementing at the current time.
Potentially shippable product
The shippable product is not always considered an artefact in its own right, however, I think it is useful to have here as it should always be delivered as part of an iteration. The shippable product emphasises that the work done in the sprint is completely finished.

The process

The process for Scrum is iterative. This means that the process is repeated over and over again until the product reaches the end of its life. Typically an iteration ranges from between 1 and 4 weeks. An iteration is called a sprint.

The process is described here and you can follow this on the above diagram.

The product owner works with the stakeholders to create a product backlog which contains all of the features that the stakeholders require. At least enough stories must be created for the team to complete a single sprint before a sprint planning meeting can occur.
The team will draw upon their experience, elements from Extreme Programming and Industry best practices to define when a story is complete. When a story is complete, it is commonly called Done. Or in some cases Done Done, meaning that not only have developers coded it (done) but all the pre-defined criteria for a story being complete have been met (done done).
The team get together for a sprint planning meeting. The sprint planning meeting is split into 2 parts.
Sprint Planning part one.
The first part is to define the sprint goal, discuss, understand and estimate the stories, and decide what stories the team will commit to for delivery in the sprint.
Sprint Planning part two.
The second part is to work out how the team will deliver the output from the stories. The sprint planning meeting is time boxed (limited in duration) to 2 hours per 1 week of a sprint. (for a 4 week sprint the meeting would be 8 hours).
The delivery from the two sprint planning meetings is the sprint backlog. Each story in the sprint will have been broken down into tasks and each task estimated by the developers.
The team then work on delivering the items in the sprint backlog. Each day, the team meet and give a very brief update in the Daily Scrum. The daily scrum or stand up meeting, is time boxed to 15 minutes and each member reports what they did the day before, what they intend to do today and if they have an impediments.
At the end of the development cycle, the team should have a potentially shippable product. This means that if the product owner wants to, the product, including all work completed in the sprint could be shipped to customers.
The team then have a sprint review meeting which allows the team to show the stakeholders and other interested parties the work they completed in the sprint. This is the chance for feedback to guide future sprints, build trust in the work the team have done and be transparent to the rest of the organisation.
The team also perform a retrospective. The team discusses the good and bad things that have happened over the duration of the sprint and typically look at how they can improve their working in the next sprint. This meeting is an informal way for the team to inspect their process and ways of working and to adapt to become better.
The process then continues, with the product owner reviewing and updating the product backlog and the whole team starting the process again. The iterations continue until there are no more stories in the product backlog or the product is shelved.

Self-organising teams

One of the huge benefits that come out of an Agile process and especially SCRUM is the concept of self-organising teams. If you look at the roles, you will not see a manager. The team is responsible for getting the work done and a natural process tends to evolve with the most appropriate person for the task doing the task. This happens when the team is motivated to succeed and then the person with the most experience in a particular area naturally volunteers for the task.

Planning, Estimating and Monitoring Progress

Being an iterative process of development, with scope changing depending upon feedback from customers, problems encountered in development and changing business needs, it might seem it is very difficult to plan a project in Agile.

Agile and particularly Scrum follows a ‘plan always’ approach, where the plan is being updated frequently. This is achieved in the following way.

The road map

At the beginning of the project, all the stories in the backlog are probably high level epics. It is possible to assign relative sizes to the stories in order to estimate possible effort. Start with the smallest and give that a 2. Then estimate each story to see how large it is in proportion to the smallest story. Add up all of the estimates and you will have a number of points for the entire backlog.

At the beginning it may be difficult to know how many points the team will get through in every sprint, but we take an estimate and divide the project up into sprints, putting the highest priority epics in the first sprints.

This gives us a rough road map as to how long and when the software will be delivered.

It is important to remember that we may not (and probably won’t) deliver the software in anything like the plan we have just described. However, before development this is a good first guess at how things might go.

The first sprint

After the first sprint, we will know how fast the team have delivered the story points and have a slightly better idea at whether our estimates are close. We can reflect the increase in our knowledge by moving the plan.

Continuous planning

As sprints are completed, we can measure the average number of story points the team are delivering. We can refine our estimates of the remaining stories based on improving our estimating, better understanding of the product and technical challenges in delivering it.

The more sprints that go by, the better average we will get and more refined the estimation process becomes.

Less Risk

This approach brings much less risk to the planning process, as feedback happens on a period equal to the sprint length. We can determine early on in the project if we are likely to meet the minimum set of functionality in time to make the project worthwhile doing. By getting earlier feedback, we can provide expectations and better planning and reduce risk early.

Scrum – An overview