SE-2800 Software Engineering Process
Using Jira to create User Stories for the Product Backlog

Outcomes

• become familiar with using Jira to create a Product Backlog containing User Stories

Overview

Before a team can begin executing sprints (including designing, implementing, and testing code), the required features of the product/application must be gathered and learned to some extent, as well as which features have highest priorities.

Assignment

In this work session, you will be using Jira to create the (initial) Product Backlog by creating and entering User Stories that describe the features of the application you'll be developing.

The User Stories for the application can be found here, or on the SE2800 main web page.

Within your team, split up the User Stories below among team members, so that each member of the team enters at least two of User Stories into Jira.

As a team, review the entered User Stories and make sure that they have been entered and formatted correctly, and that each Story contains Acceptance Criteria (below) that make sense.

Instructions for entering User Stories

An example of entering a user story (from a previous SE2800 project) is shown below.

Enter each User Story into Jira via the Create Issue dialog, which you invoke by pressing the Create link on the Jira Screen when viewing your Agile Board.

1. Make sure the appropriate project is selected in the Project drop-down.
   
   
2. Make sure you select Story from the Issue Type drop-down.
   • In Scrum, Product Backlog Items (PBI's) are comprised of User Stories, Defects, Internal Improvements (i.e. improving old code), Ceremonies, and Knowledge Acquisition items (we'll discuss these later). For now, you'll just enter User Stories; later, you will add Defects, and you may also find that you need to add Internal Improvements or Knowledge Acquisition items; note, however, you will NOT be using Ceremonies.
     
     
3. Fill out only the Summary and Description fields. Other fields exist if you scroll the dialog, but you should not enter data in them at this point.
   • Recall that the User Story form is generally as follows: "As a <type of user>, we need <feature A> [so that <value proposition>]". A User Story also indicates Acceptance Criteria that, when met, mean that the feature satisfies requirements (but maybe not yet done!). As you complete sprints later, you'll again use these Acceptance Criteria/requirements to validate that the feature truly is functional and complete.
     Recall also that a basic tenet of Scrum is that these are unlikely to be known completely or with 100% certainty up-front, and that more knowledge will emerge with time, possibly resulting in changes to features and priorities - determined by the Product Owner (NOT the developers). The details of various features may be known to varying degrees (requiring a discussion between the developers and the Product Owner), and the need/priority for certain features may not become known until a later date.
     
     
• Each User Story description must include Acceptance Criteria which further clarify the requirements. You must add the names of the test files you will use to verify the Acceptance Criteria. The expected outcome(s) from loading the test files must be listed; this allows tests to be executed later by other persons who can compare the expected outcomes to the actual outcomes to ensure that the Acceptance Criteria are achieved. INITIALLY, leave placeholders for the expected outcomes - you will not know these now and will modify the User Stories later (during a sprint) as you work on testing and validation tasks.
  
  
• The Summary field should contain an abbreviated version of the User Story (for example, for User Story 1: "Import GPX Files"; for User Story 2: "Display Path Metrics")
  
  
• Note that requirements may not be stated in exhaustive detail - for instance, there may be no criteria that state exactly how the user interface should appear (although sometimes it is, and mockups or sketches may accompany the Acceptance Criteria). Generally, at the beginning of a project, you will be responsible for eliciting details with help from the Product Owner. SE students will learn more about this in SE3821, and practice it in depth in SDL (SE3010-3020-3030).
  
  
• Edit the styles in the Description text field by using the formatting functions so that each Acceptance Criterion is a separate bullet point.