Scrum process flow

Outlines the process flow for the SDLC Scrum Process application from plugin activation to the completion of a sprint.

This flow represents the common practice for creating and managing scrum records with the functionality provided in the base Scrum Process Pack and is not intended to represent the only possible process. Use the links provided to examine detailed instructions for each task. Each procedural page contains prerequisite information and instructions for accessing the next task in the sequence.

Create a product

In scrum, a product represents functionality that a product owner has identified as important to customers.

A product might contain the themes, epics, and stories that describe these enhancements from the user's perspective. Products can have a narrow focus with few user stories or a wider context with many user stories, each containing several tasks. You create products first and then add themes, epics, or stories to create the product backlog.

Create user stories

A user story is a brief statement of a product requirement or a customer business case created by a product owner.

Typically, stories are expressed in plain language to help the reader understand what the software should accomplish. Stories contain specific tasks for work that can be resolved in one sprint. Stories that take longer than a sprint to complete should be broken into one or more stories and grouped into an epic. Stories and epics can be associated with themes, which are the highest level goal or objective. The Scrum Process Pack enables administrators to add stories at different points throughout the scrum process as necessary to react to changes in feature scope or resource availability. You cannot create a story without associating it to a product. A story cannot be associated with more than one product, release, or sprint.

Well-written scrum stories

Within the Scrum process, the main purpose of a story is to provide a high-level definition of a requirement, capturing the who, what, and why in a simple, concise way.

Well-written stories are easy to understand by all developers and other team members, such as QA or documentation. They allow the Scrum team to accurately estimate the effort needed to implement the work according to the team’s definition of done (the exit criteria to determine whether a story is complete).

A Scrum story has the following basic conditions:
  • The story description relates to a user persona, such as administrator, and either describes a business value or addresses technical debt.
  • The story acceptance criteria are measurable and testable.

Story descriptions

A good user story description should identify:

  • The role of the user persona in the system.
  • The need expressed by the user persona.
  • The benefit to all stakeholders, such as developers, users, and others, of meeting the stated requirement.

Typically, this is expressed:

"As a <role>, I want <goal or need>, so that <benefit>."

Examples of Good Descriptions

  • Description: As a developer, I want to publish the current state of my application to an update set, so that I can deploy it to a production system.
  • Description: As a customer, I want to receive notifications when an incident is commented, so that I am updated on the status.
  • Description: As a change manager, I want to enable the assessment of risk for any given change by establishing a list of questions with multiple choice answers.

Example of Bad Description

  • Description: Notifications are sent when incidents are created.
This description is poor because:
  • The description does not state who or what is sending the notifications, not in what form the notification takes, such as email.
  • The description does not include any benefit information, so the business value is not clear.
It could be better written as:
  • Description: As an incident creator, I want email notifications to be sent to a predefined set of interested parties when I create an incident, so that they can be informed when an incident affecting them is created.

Story acceptance criteria

Acceptance criteria define the boundaries of a user story, and are used to confirm when the software is working as intended, which means the story is completed.

They are an essential part of the definition of done for that story.

Good acceptance criteria should include the following, where relevant:
  • Usability: Be sure to include measures of usability in the acceptance criteria. Indicate how to answer the question: Is it easy to use? The key is to identify the right measurements and make sure each is quantifiable.
  • Functionality: Identify specific user tasks, business processes, or functions that must be in place at the end of the project. A functional requirement might be: The user can choose from multiple sizes.
  • Error handling: Enumerate error cases and how each should be handled. For example, if a user performs the steps in the wrong order, how will the software handle it?
  • Performance: Test system performance from the perspective of an individual user. For example: Is the UI responsive?
  • Stress tests: Describe how the system responds when it is under stress because there are many users, transactions, or queries. Acceptance criteria should define acceptable thresholds for stress testing. For example: Does the system respond within a 250 millisecond threshold when 100 users submit queries simultaneously?

Example of Good Acceptance Criteria

Description: As a customer, I want to order and pay for the book via a secure web-based form, so that my credit card information is safe.

Acceptance Criteria:
  • All mandatory fields must be completed before a customer can submit a form.
  • Information from the form is stored in the customer orders database.
  • Payment can be made via Amex, Master Card, or Visa credit card.
  • The system shall accurately calculate and apply sales tax.
  • The system shall accurately calculate and apply shipping charges.
  • The customer shall be able to verify the accuracy of the order.
  • An acknowledgment email is sent to the customer submitting the form.
  • Protection against spam is working.

Example of Bad Acceptance Criteria

Description: As a customer, I want to receive notifications when an incident is commented, so that I am updated on the status.

Acceptance Criteria: The appropriate people are notified when incidents are commented.

The acceptance criteria are poor because they do not give enough detail to test; for example, it's not clear who the appropriate people are.

The acceptance criteria could be better written as:
  1. As an ESS user, create an incident.
  2. Select Notify interested parties.
  3. Save the incident.
  4. Log in as an interested party.
  5. Check that you have received an email for the logged incident.

Create a release

A release has a start and end date during which a number of development iterations are completed.

When a release record is created, at least one scrum team and its members should also be created. A release team can be reused for each sprint within the release. For each team member, a default number of story points can be defined and applied to the sprints. At the sprint level, the aggregate of the team members' story points determine the team’s capacity. Sprints inherit the default team and team members of the parent release. At the sprint level, the release planner can override the structure and number of points assigned to a team member if necessary to support the availability of the team members on a sprint-by-sprint basis. For instructions on creating a release backlog and development teams, see Releases in Scrum.

Create a sprint

A sprint is the basic unit of time in the development process.

A sprint can be of any length, but typically takes between one and four weeks to finish. The scrum master creates one or more sprints from within a release. All sprints within a release must fit within the release start and end dates. The scrum team is expected to complete all stories to which it is committed within a sprint and to meet the acceptance criteria as defined in the story records. The scrum master's expectation of the sprint content is that the stories are fully tested and potentially releasable. In most cases, the committed stories for a specific sprint should not change during the sprint. However, the Scrum Process Pack application makes this possible if necessary. Stories should be added or removed from a sprint only after a discussion with the team, scrum master, and product owner. For instructions, see Sprints in Scrum.

Plan the sprint

Before a sprint starts, the team and scrum master decide on what stories they can commit to completing within a sprint.

The scrum master must make sure that the effort (story points) required to complete the stories matches the capacity of the release team. If the effort exceeds the capacity, the scrum master can add team members, remove stories, or add sprints as needed. A velocity chart is available to help in the estimation process. The velocity chart shows a team’s historical record of the number of completed points, by sprint. This view gives the scrum master an idea of the general capacity of the team over time and produces more accurate sprint planning. Velocity charts are the most meaningful if sprint duration is constant and the team members' available points do not change between sprints. Use the velocity chart as guidance and not as a factual representation of what the team can produce in the next sprint. For details about sprint planning and using the planning board, see Sprint Planning.

Track sprint progress

The scrum master manages the sprint team's efforts, provides progress reports, and removes any impediments that the team encounters.

Team members update task and story records and conduct daily stand-up meetings (scrum meetings) to communicate their progress and concerns to the scrum master. The application provides powerful story and task boards to assist in the management and tracking of sprint progress.

Generate charts

In addition to the progress boards, the SDLC Scrum Process Pack provides a report called a burndown chart for tracking the progress of a sprint. This chart is one of the most important tools of a scrum team.

The burndown chart compares ideal progress in a sprint (based on the committed stories) against the actual progress, on a daily basis. This report enables the scrum master and team to track their progress and make necessary adjustments to complete the sprint on time.