Project management header
products page

Project management systems – SCRUM – part 2

SCRUM – part 2

The Product Owner

The Product Owner (could be a key user) prioritises the Product Backlog.
A single person must have the final authority when representing the customer's interest in Product Backlog prioritisation and requirements questions.

The Scrum Team examines the list of priorities in the Product Backlog and decides on the top priority tasks that will be completed during a sprint.
These items become the Sprint Backlog.

Hence, these tasks will be the most important to the Product Owner.
The Product Owner does not add any tasks to the sprint.
This supports the commitment of the team to complete the high priority tasks.

Any change that occurs will be outside of the sprint.
Once a team begins the sprint it should be completely focused on its completion.

The Product Owner should be available to the team at any time, especially during the Sprint Planning Meeting and the Sprint Review Meeting.

Challenges will include:

  • He or she must resist the managing the team. The team should sort out issues for itself
  • The Product Owner does not add any tasks to the sprint
  • He or she must be able make hard choices, as necessary, during the sprint planning meeting
  • Balancing the interests of competing stakeholders

Sprint

This is a short burst of work lasting approximately 30 days.
During this period an executable and other deliverables are built by an engineering team, as indicated by the assigned Product Backlog.

A sprint lasts no more than 30 days.
A sprint is undertaken by a cross functional team consisting of no more than 9 members.
Every sprint has a specific goal.
An executable demonstrating the goal will be completed by the team during the sprint.

The sprint team has the final say in estimating and determining what they can accomplish during the sprint.

Once the sprint is underway, a new Product Backlog cannot normally be added to the sprint.
This can only happen if:

The Scrum Master determines that a new Product Backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the Product Backlog item can be added.

If it is realised that the sprint is working on the wrong thing, a sprint can be halted and restarted with new Product Backlog and purpose.

At the end of each sprint the team demonstrates the completed functionality at a Sprint Review Meeting.

Sprint Planning Meeting

The meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives.

The product owner describes the highest priority items to the team.
He may not have the time to describe them all and may focus on the high priority items.
Others can be left for another meeting.

The team listen and ask questions.
They are then able to go off and determine which tasks they will move from the Product Backlog to the Sprint Backlog.

A sprint goal is agreed describing what should be achieved at the end of the sprint.
Success will be measured against this goal at the Sprint Review Meeting.

After the sprint planning meeting, the Scrum team meets separately.
They will discuss the described items and will agree on the task load for the coming sprint.
There may be some negotiation with the product owner.

Sprint Backlog

At the start of each sprint a Sprint Planning Meeting is held during which the Product Owner prioritises the Product Backlog.
The Scrum Team then selects the tasks they can complete during the coming Sprint.
These tasks are then moved from the Product Backlog to the Sprint Backlog.

The sprint backlog can be maintained as an Excel spreadsheet.
Software is very useful for sorting large lists against pre-defined fields.

Whilst the sprint is underway the Scrum Master updates the sprint backlog by recording completed tasks.
He or she should also identify actions for those tasks not yet finished.
The estimate of work remaining is calculated and recorded graphically.
This will lead to a burn down chart.

The aim of the team is to try its best to agree to the right amount of work for the sprint.
However, during the Sprint planning meeting the team may get too much or too little.
Tasks may need to be added or removed.

Scrum Master

The Scrum Master upholds the values and the practices of Scrum within the team.

He or she manages the team commitment and makes sure that the work taken on is realistically achievable during the sprint.

The Scrum Master facilitates the daily scrum.
He or she is responsible for removing any obstacles raised during a Scrum team meeting.
Whilst the role could be filled by anyone it is usually a project manager or a technical team leader.

The Scrum team

They are not usually comprised of traditional roles such as programmers or testers.

The team forms a closely bonded unit that is committed to completing the tasks agreed in the sprint.

Whilst the team size is normally 6 to 12 persons there are reports of successful teams consisting of many hundreds.

When larger teams are used they can be arranged into a team hierarchy.
When larger numbers of people are involved the number of levels may increase.
Here the smaller teams choose a representative to attend a ‘higher’ ‘Scrum of scrums’ team meeting to review progress.
These may not be run daily but every 2 or 3 days or whatever time frame is deemed suitable.

More information can be found in the online encyclopaedia Wikipedia.

Under PRINCE2® 2009 [see ‘The Complete Project Management plus PRINCE2’] planning is covered by the Plans theme.
The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering the products (the where and how, by whom, and estimating the when and how much).
[see Plans - Purpose]

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.