Scrum process flow

Outlines the process flow for the Agile Development application from plugin activation to the completion of a sprint.

The flow described in this document represents the common practice for creating and managing scrum records with the functionality provided in the base Agile Development 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 perspective of a user. 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. Agile Development 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

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. Stories allow the Scrum team to accurately estimate the effort required to implement the work according to the definition of done (the exit criteria, agreed to by the team, that determines when 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 identifies, the role of the user persona in the system, the need expressed by the user persona, and the benefit to all stakeholders, such as developers, users, and others, of meeting the stated requirement.

Typically, a story description 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. Acceptance criteria are an essential part of the definition of done for a 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 several 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 sum of the team member 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 expects that the stories are fully tested and potentially releasable. Usually, the committed stories for a specific sprint should not change during the sprint. However, the Agile Development application makes changes 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 historical record for a team 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 when sprint duration is constant and the available points for team members 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 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 help with managing and tracking sprint progress.

Generate charts

In addition to the progress boards, Agile Development provides a report known as a burn down chart for tracking the progress of a sprint. This chart is one of the most important tools of a scrum team.

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

Parts of scrum

Scrum is an iterative and incremental framework for project management that is deployed in agile software development environments.

The scrum process has the following parts:

  • A scrum theme is the highest level of the story hierarchy and describes a view of a tangible product (such as a trading application) or an abstract goal (such as performance tuning). A product owner breaks down a theme into one or more epics.
  • An epic groups related user stories together or describes a block of requirements that have not yet been rationalized into stories.
  • A story is a brief statement of a product requirement or a business case. Typically, stories are expressed in plain language to help the reader understand what the software should accomplish. Product owners create stories. A scrum user then divides the stories into one or more scrum tasks.
  • Scrum tasks are the discrete pieces of work required to complete a story.
Note: Make sure to create a product before attempting to create themes, epics, or stories. You cannot submit these records without attaching them to a product.

See Scrum Products for information on creating products. For a complete list of the tasks required to use SDLC Scrum Process and links to the necessary procedures, see Scrum Process Flow.

After creating stories and scrum tasks for your products, create a release backlog containing the stories from one or more of these products.

Create a theme

A product owner breaks down a theme into one or more epics. Multiple themes can be associated with a product, but a theme cannot be associated with more than one product at a time.

About this task

Users with the scrum_product_owner and scrum_release_planner roles can create themes.

Procedure

  1. Navigate to SDLC (Scrum Process) > Planning > Themes.
  2. Click New.
  3. On the Theme form, enter a Name for the theme that states the high-level business case.
    Figure 1. Theme form
    Theme form
  4. Select the Product associated with the theme and complete the descriptions.
  5. Click Submit.
    The saved form displays the Epics and Stories related lists.

Epics

Epics organize the work needed to complete parts of a theme into smaller, more manageable pieces.

To organize epics, you can create a hierarchy of parent and child epics. You can associate an epic to a product, theme, or a configuration item (an item or service being affected). You can also define child epics. You can associate multiple epics with a single theme, but an epic can only be associated with one theme at a time.

Users with the scrum_master, scrum_product_owner, and scrum_story_creator roles can create epics.

Create an epic

You create an epic from the Theme form.

  1. Create an epic using one of these methods:
    OptionAction
    In a Theme record select the Epics related list and click New.
    Navigate to Agile Development > Planning > Open Epics and click New in the record list.
    Figure 2. Epic form
    Scrum new epic
  2. Fill in the fields, as appropriate.
    Table 1. Epic form fields
    Field Description
    Product [Required] Product to associate with this epic.
    Product owner Product owner associated with the product selected.
    Configuration item Item or service this epic affects.
    Theme Theme associated with this epic. This field becomes active when a product is selected. Themes are optional.
    Parent epic Parent epic, if this is a child epic.
    State Current state of the epic. The default is Draft.
    Assignment group Group working on the epic.
    Assigned to User interested in the progress of this epic.
  3. Click Submit.
    Related lists for child epics and stories appear.
  4. To create child epics or stories from these related lists, click New.

Stories

A story is a brief statement of a product requirement or a business case. A story should be small enough to be completed in one sprint.

The estimated effort required to complete a story is measured in story points, with more points being assigned to stories requiring more effort. Story points are arbitrary measurements of the effort (not necessarily the time) required to complete a story, based on the estimates of scrum team members. The work required for a story can be broken down into discreet scrum tasks.
Note: An epic can have one or more stories, but a story can belong to only one epic at a time.
Users with the following roles can create and edit stories:
  • scrum_master
  • scrum_product_owner
  • scrum_sprint_planner
  • scrum_story_creator

After creating stories and tasks, manage and track them to completion through the story and scrum task progress boards. Access the progress board from the Related Links section of the Story form as well as from other forms.For tips and best practices on writing effective stories, see Well-Written Scrum Stories.

Create a story

There are several ways to create a story.

  1. Create a new story in one of these ways:
    OptionAction
    Navigate to Agile Development > Stories > Create New
    In a product, release, or sprint form Select the Stories related list and click New.
    Display the product backlog in the planning board Click New.
    Figure 3. Story form
    Scrum new story
  2. Complete the Story form.
    Table 2. Story form fields
    Field Description
    Product The product with which this story is associated. This field is required if using the SDLC Scrum Process application (SDLC Scrum Process Pack plugin).
    Project The project with which this story is associated. This field is required if using the project-based Agile application
    Configuration item Select the configuration item or service this story affects, if applicable.
    Theme Select the theme for this story from a list of themes associated with the selected Product. A story can belong to only one theme at a time.
    Product owner [Read-only] Displays the product owner for the selected Product.
    Release Select a release for this story from the releases associated with the selected Product.
    Sprint Select a sprint for this story from the sprints associated with the selected Release.
    Epic Select an epic for this story from the epics associated with the selected Product.
    Priority Select the priority for this story. A product owner can use priorities to rank stories in the planning board.
    Opened Set the date and time for creating the story. The default is the current date and time.
    Opened by Select the user who created the story The default is the logged in user.
    Type Select the type of story:
    • Development
    • Documentation
    • Spike (research activity)
    State Select the story state. The default for a new story is Draft.
    Points Enter a number of points to indicate the estimated effort required to complete the story. A larger point value indicates that a greater amount of effort is required.
    Assigned to Select the user who will be working on the story. Users on this list have appropriate scrum roles.
    Blocked Select this check box to indicate that issues are preventing the story from making progress. Clear the check box if there are no blocking issues.
    Classification Select Defect or Feature to indicate the type of development the story involves. The default is Feature. This field has no connection to the Defect and Enhancement fields in the Related Records section.
    Acceptance criteria Describe the functional criteria or testing results required to move this story to a state of Complete.
    Work notes Enter any notes about the work being performed for this story.
    Related Records
    Defect This is a reference field from the Defect [rm_defect] table. Click the magnifier icon in this field to display defect reports created by users with the feature_user role. This is the only location in the Scrum Process application where records from this table appear. For details about reporting defects with this feature, see Defect Reports in Scrum.
    Enhancement This is a reference field from the Enhancement [rm_enhancement] table. Click the magnifier icon in this field to display enhancement requests created by users with the feature_user role. This is the only location in the Scrum Process application where records from this table appear. For details about enhancement requests, see Enhancement Requests in Scrum.
  3. Click Submit.
    Saving the form displays the Scrum Tasks, Prerequisite Stories and Dependent Stories related lists.
  4. Create the necessary scrum tasks for this story, or specify one or more stories where the current story is dependent from these related lists.

Create a story from an enhancement

The scrum product owner reviews enhancement requests and decides which ones require stories.

  1. Navigate to Agile Development > Stories > Create New.
  2. Complete the form using the procedure for creating stories in scrum.
  3. Select the Related Records tab.
  4. Click the magnifier icon in the Enhancement field and select the request for this story.
  5. Click Submit.

Assign a story to a project

You can assign a story to a project from the Stories list.

About this task

Use the examples in the following steps to add choice tables, notes, tables, figures, step results, and post-requisites to the task.

Procedure

  1. Navigate to Agile Development > Stories > Open Stories.
  2. Select the check box to the left of the desired story.
  3. Select Move to project from the Actions choice list.
  4. Select an active project in the Project field and click OK.
    The story is assigned to the selected project. When a story is assigned to a project, the settings in the following fields are cleared:
    • Release
    • Product
    • Sprint
    • Team
    • Epic
    • Theme
    If the project is assigned to a team and has a development phase, the following fields are auto-populated:
    • Team
    • Project phase

Scrum tasks

Tasks are the discreet pieces of work required to complete a story. A task might require between four and twelve hours to complete.

Team members volunteer for tasks based on their skills and track the hours remaining on a daily basis. The time remaining is reflected in the sprint burn down chart. If the planned hours for a task exceed an agreed upon period of time, such as eight hours, the task can be split into additional tasks. A story is not complete until all of its tasks are complete.

You add tasks to an existing story from the following locations on the Story form:
  • The Tasks related list
  • The Add Scrum Tasks related link in a Story form
Note: You also can add tasks from the planning board and the story progress board.

Create a scrum task from a planning board

You can add scrum tasks to an existing story from the planning board.

  1. On the planning board, right-click a story and select Add Scrum Task.
  2. Complete the form as described in the field description table.

Create a scrum task from a story progress board

You can add scrum tasks to an existing story from the story progress board.

  1. In the story progress board, click the green plus icon (+) in a story object to create a new scrum task
  2. Complete the form as described in the field description table.
    Figure 5. Story Progress board
    Create task progress board

Create a scrum task from the Tasks related list

You can add scrum tasks to an existing story from the Tasks related list.

  1. Navigate to Agile > Stories > Open Stories and open an existing story.
  2. In the Scrum Tasks related list, click New.
  3. Fill in the fields, as appropriate.
    Table 3. Scrum Task form fields
    Field Description
    Story [Read-only] Displays the story associated with the scrum task.
    Planned hours [Required] Enter the estimated number of hours to complete the task. A typical scrum task should take between four and twelve hours. If the task requires more than 12 hours, consider breaking it down into multiple tasks.
    Remaining hours Enter the estimated number of hours remaining to complete the scrum task. This value is updated by the assigned team member as work is being done on the task.
    Actual hours After the task is complete, enter the number of hours the task actually required.
    Type Select the type of work involved.
    State Select the scrum task's current state. The default is Draft.
    Assigned to Select the user who will be working on the scrum task. The default is the story owner.
    Blocked Select this check box if the scrum task is blocked for some reason. Clear the check box if there are no blocking issues.
    Short description Enter a brief description of this scrum task.
    Description Enter a detailed description of the scrum task.
    Work notes Enter notes to indicate progress on the scrum task or issues blocking it.

Manage a scrum task

You can manage scrum tasks on the task progress board.

About this task

You can also use the task progress board to track scrum tasks to completion.

Procedure

  1. Navigate to Agile > Open Sprints.
  2. Select a sprint.
  3. Click the Task Progress Board related link.
  4. View information about all stories and corresponding tasks.
  5. [Optional] To quickly assign a task to yourself, drag a task to the Work in progress column.
    Figure 6. Task Progress board

Add prerequisite and dependent stories

You can add the related stories to an existing story using the Prerequisite Stories and Dependent Stories related lists.

  1. Navigate to Agile Development > Stories > Open Stories and open an existing story.
  2. In the Prerequisite Stories related list, click Edit to specify a story which must be completed before the current story can be completed.
    The Edit Members form appears.
  3. Use the slushbucket on the form to add one or more stories, and click Save.
    The selected stories appear in the Prerequisite Stories related list.
  4. In the Dependent Stories related list, click Edit to specify a story which is dependent on the current story.
  5. Use the slushbucket to add one or more stories, and click Save.
    The selected stories appear in the Dependent Stories related list.

Products

A product is an arbitrary classification that represents an item under development.

A product organizes themes, epics, and stories of similar functionality into a single context. Stories represent the work required to build the product. The list of stories in a product is referred to as the product backlog. A product owner is responsible for keeping the product backlog organized and for selecting the stories for a particular release.

Create a product in Scrum

A scrum product is an arbitrary classification that represents an item under development. A product organizes themes, epics, and stories of similar functionality into a single context.

About this task

Stories represent the work required to build the product. The list of stories in a product is referred to as the product backlog. A product owner is responsible for keeping the product backlog organized and for selecting the stories for a particular release.

Only users with the scrum_product_owner role or the scrum_release_planner role can create products.

Procedure

  1. Navigate to Agile Development > Planning > Products.
  2. Click New.
    A blank Application Model form appears.
  3. Complete the form, using a unique and descriptive name.
    The Product owner field displays the logged in user's name. If necessary, select another product owner from the list.
  4. Click Submit.
    Related lists for releases, themes, epics, and stories appear.
  5. You can create records now by clicking New in a related list or continue to the next page in the flow.

    The stories you add create the product backlog. You cannot add a theme, epic, or story to more than one product or release at a time.

Result

After creating a product, create user stories to associate with the product.