Agile Software Development, Scrum part 3

Today we’ll look closer at the Scrum process items. Each of this item works in it is own/unusual and specific way, helping Scrum practices come into life. Let’s start from the product backlog which is an alive Artifact of this project framework.

Product Backlog

Product Backlog – it is an ordered list of everything that could be necessary in the product, it is the only source of requirements for any changes that may be required to make to the product.

Responsibility for Product Backlog is carried by the Product Owner, including its content, availability and tasks ordering.

Product Backlog is never a completed thing. The initial version of this document contains only the initially known and most understandable requirements.

Product Backlog is constantly updated when product and its development environment around it updates. Product Backlog is dynamic, constantly changing to meet the requirements of the product, its suitability and competitiveness.

Product Backlog contains all the features, functions, requirements, enhancements, and information about the correction of defects, i.e., the data that determine the changes needed in future releases of the product.

Each element of Product Backlog has description, serial number, estimate the amount of work and value.

Over time, the product is used and gains value, and the market gives the feedback for it, so Product Backlog becomes more voluminous and exhaustive. Requirements never stop changing, Product Backlog is an alive artifact.

Changes in business requirements, market conditions, or technology may lead to change Product Backlog.

Sprint

The heart of Scrum is a Sprint with duration of one month or less (in Nokia it is about 6 weeks), during this period potentially ready for the release and use product (working version) is created.

Every Sprint may be considered as a project lasting no more than one month.

Next Sprint starts immediately after the previous one.

Sprints consist of:

Sprint Planning;
DailyScrum;
Development;
Sprint Review;
Sprint Retrospective.

During the Sprint:

Any changes are not permitted to make, which could jeopardize the purpose of the Sprint.
Goals about product quality remain unchanged.
The scope of work can be refined and re-verbalized between the Product Owner and Product Development Team as the accumulation of knowledge.

Sprint can be canceled before it is completed. Only the Product Owner has the right to cancel the Sprint.

Sprint is canceled if its purpose ceases to be relevant.

This can occur due the changes in the direction of the company, changes in market conditions or technology.

Sprint Planning

Actions plan is created in cooperation of the whole Scrum Team. For Sprint with month-long, meeting duration is limited to eight hours. For shorter sprint planning is usually allocated even less time.

Sprint planning answers the following questions:

What can be done in increment of the product in next Sprint?
How will execute the work required to create the Product Increment?

The purpose of the Sprint

The purpose of the Sprint gives the development team some flexibility with respect to functionality developed in the Sprint. Selected items of the Product Backlog bear one common purpose, which may be the target of the Sprint.

Daily Scrum – a 15-minute activity for development team to synchronize activities and create a work plan for the next 24 hours.

This is doing to verify the work that have been done since the last Scrum and forecasting of what can be done to the next. These meetings are held in the same place and in the same time. During the meeting, each member of the development team explains colleagues the following:

What have I done since the last meeting in order to help the development team to achieve objectives of Sprint?
What will I do today to help the development team to achieve objectives of Sprint?
Does I see some obstacles for me or a development team that could hinder the achievement of objectives of Sprint?

Each day the development teams must understand how it achieves the goal till the end of the Sprint.

Sprint Review

Meeting for the Sprint Review is held at the end of the Sprint to check the Increment.

During the Sprint Review Scrum Team and stakeholders are discussing the executed work that have been done during the Sprint.

This is not an official meeting, but rather a presentation of the Increment, designed for obtaining feedback and evolving cooperation. For Sprint month-long the Sprint review is a four-hour event.

The Sprint Review includes:

Participants, including Scrum Team and key stakeholder persons invited by the owner of the Product;
Product Owner explains what is “ready”, and what is not;
Development Team discusses what went smoothly and what difficulties had appeared during this Sprint and how they coped with them;
Development Team make a demonstration of what has been done and answers questions about current increment;
Product Owner discusses the state of the Product Backlog.He makes assumptions about a possible completion date, taking into account the speed of advance to the date;
Overview of the possible changes in the market, potential product applications, and the most valuable tasks;
Review of the terms, budget, the potential opportunities and the state of the market to the moment when the product will be released.

Revised Product Backlog is the result of a Sprint Review

Sprint Retrospective

Sprint Retrospective provides Scrum team the opportunity to inspect itself and create a plan for improvements for the next Sprint. Sprint Retrospective occurs after the Sprint Review, before the next sprint planning.

It is limited to three hours meeting for one-month Sprint.

Team members are telling their opinions about the last sprint.

Answers two basic questions:

What has been done well in the last Sprint?
What should be improved in the next Sprint?
Perform an Improvement of Software Development Process (solve problems and fix successful solutions).

Sprint Backlog

Sprint Backlog is a collection of items from Product Backlog selected for implementation in the current Sprint, as well as a plan of the product Increment development. Product Backlog is some kind of a forecast from Development team that describes functionality that will be part of the next Increment. Sprint Backlog determines the amount of work that Development team must perform to turn Product Backlog in “Ready” Increment.

Transparency of Artefacts

The sense of this methodology is transparency. Solutions for optimizing the value and risk control are taken on the basis of understanding the state of the artifacts.

As long as full transparency exists, these decisions have a sound basis. When transparency is incomplete, these decisions may have errors, the value decreases and risks grow.

Determine the readiness

When an item from Product Backlog or Increment is called “Ready”, everyone must understand what that means.

Although this definition are interpreted in different ways by different Scrum Teams, in order to guarantee the transparency the Team members must have a common understanding of what it means – to complete the work.

Only one definition of “readiness” is used by Scrum Team to assess the completion of work on the increment of the Product.

Having a common understanding about the product readiness, you could announce its completion and then put a product on the market. You should not have any contradictions within the Scrum team. The owner will be pleased with the results, and the team is satisfied with the development.

As we had seen in this three-part article, Scrum represents some new and productive way of the software development. It based on some old and good-working principles such as command structures, discipline, rationality, one-source management e.t.c. The client oriented design and short time delivery of a new product versions make this framework very attractive for IT business nowadays, because it gives many competitive advantages in today’s hostile environment. In our team we use Scrum practices with some modifying for our needs and find it useful. Also most of our experienced clients prefer to use it to. Through the years this approach finds more and more followers, so if you do not use Scrum today, now you know why you should.