Scrum project management

Scrum is an agile process that focuses on delivering the highest business value in the shortest amount of time. It allows for the rapid and repeated inspection of actual working software every two weeks to a month. The business sets the priorities and teams self-organise to determine the best way to deliver the highest priority features. Every two weeks to a month, anyone can see real working software and decide to release it as is, or continue to enhance it for another sprint.


Scrum projects make progress in a series of iterations called sprints. The typical duration of a sprint is two to four weeks, or a calendar month at most. A constant duration leads to a better rhythm. The project is designed, coded and tested during the sprint.

No changes are allowed during a sprint. The sprint duration should be planned around how long change can be kept out.

Scrum framework

A scrum team is made up of a number of roles who take part in a number of ceremonies using a number of artifacts.


Product owner

The product owner defines the features of the product. They decide the release date and the content released on that date. They are responsible for the profitability of the product by determining the potential return on investment (ROI) for each user story.

They prioritise features according to market value at the time, and adjust these features and their priorities every sprint as needed. They accept or reject work results, and ultimately decide if the iteration made during a sprint will be released or not.

The scrum master

The scrum master has authority over the entire process. They are responsible for enacting scrum values and practices. They remove hindrances.

They also ensure that the team is fully functional and productive. They enable close cooperation across all roles and functions within the team. They also shield the team from external interference when need be.

The scrum team

A team is made up of three to nine people. This does not include the product owner or the scrum master unless they are actively developing. Teams are cross functional. They include:

  • Programmers
  • Testers
  • UI designers
  • etc.

All skills are used in some form in the duration of a sprint. Members of the team should be working full time and working together all of the time. Exceptions can be made to this rule where specific skills are in short supply; in which case, they may be shared across a number of teams. (for example, a DB administrator).

Membership should change only between sprints according to the next sprint goal. This usually will have a slight impact on productivity as members get used to their new teams.


Ceremonies include the daily scrum, sprint planning meeting, sprint review, sprint retrospective, and others.

The daily scrum

A stand up meeting that happens daily at a set time, and for a set duration. These meetings are not for problem solving. Everyone is invited to a daily scrum, but only the scrum team must attend. Only the scrum team, scrum master and product owner can talk at the meetings.

Everyone answers three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Is there anything in your way?

As well as informing the scrum master of your status, these are also commitments made in front of your peers in person. Social commitment is a very strong work motivation.


Product backlog and user stories

Backlog item naming convention
As a <actor> I can <action> so that <goal>.
As a <role> I can <feature> so that <reason>.
eg. As a guest I can make a reservation so that I stay at a hotel.
As a registered user I can log in so that I can see my profile page.

Product backlogs are given an estimate, which is usually given in story points.

A user story is a form of agile requirements specification.

A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.

They define what will be built in the project, and are formulated in one or two sentences in everyday language. The language used should be understood by both developers and customers/product owners. They are typically written by the customers. The work required to implement the stories is estimated by the developers, and then priorities by the customer/product owners after the estimation is carried out.

Benefits of user stories include:

  • They are quick to write compared to formalised requirements specifications.
  • They are easier to modify and maintain when requirements change than more formal requirements specifications.
  • They enable a quick response to changing requirements (between sprints)
  • They encourage face to face communication.
  • Minimal investment of time needed until really necessary.
  • Allows projects to be broken up into sprintable chunks.
  • They give a unit of work that developers can estimate.