anyong / jira-sample Goto Github PK

Task Breakdown

Many teams choose to break down user stories into a set of tasks needed to implement the story. They then update the status of these tasks during a sprint to track progress. The completion of the last task signals the end of the story.

You can add sub-tasks to a story on the sub-task tab (folder icon) above.

About the Product Backlog

The backlog is the source of truth for the order of work to be completed. It is expected that the Product Owner will work with the team to make sure that the backlog represents the current approach to delivering the product. JIRA Software makes it easy to prioritise (rank) Stories by dragging them up and down the backlog.

Creating Quick Filters

You can add your own Quick Filters in the board configuration (select Board > Configure)

When you click "+ Create Issue" you will be asked for the correct project (select "SAMPLE") and Issue Type (select "Story").

About User Stories

The Scrum methodology drops traditional software requirement statements in favour of real world problems expressed as User Stories. Stories describe the task a particular user is trying to achieve and its value. They are typically of the form "As a (role) I want (something) so that (benefit)". This approach focuses the team on the core user need rather than on implementation details.

Stories are "placeholders for a conversation" -- they do not need to be especially detailed since it is expected that the team will work together to resolve ambiguity as the story is developed.

Stories to be implemented in the future are stored in the Product Backlog. The backlog is ranked by the Product Owner so that the next items to be completed are at the top.

At 5

This story is estimated at 5 Story Points (as shown in the "Estimate" field at the top right of the Detail View).

Try updating the Story Point estimate to 4 by clicking on the "Estimate" then typing.

Estimating using Story Points

Because the traditional process of estimating tasks in weeks or days is often wildly inaccurate, many Scrum teams estimate in Story Points instead. Story Points exist merely as a way to estimate a task's difficulty compared to some other task (for example, a 10-point story would probably take double the effort of a 5-point story). As teams mature with Scrum they tend to achieve a consistent number of Story Points from Sprint to Sprint -- this is termed the team's velocity. This allows the Product Owner to use the velocity to predict how many Sprints it will take to deliver parts of the backlog.

Many teams use Planning Poker to achieve consensus on Story Point estimates.

Using Other Estimation Units

You can configure JIRA Software to use time-based estimates if you wish. In the configuration for the board, on the "Estimation" tab, select "Original Time Estimate" as your Estimation Statistic. If you also wish to track the time used during the Sprint, select "Remaining Estimate and Time Spent" to enable Time Tracking in JIRA Software.

Editing using the Detail View

Many of the fields in the detail view can be inline edited by simply clicking on them.

For other fields you can open Quick Edit, select "Edit" from the cog drop-down.

Starting a Sprint

During the Planning Meeting the team will examine the stories at the top of the backlog and determine which they can commit to completing during the coming sprint. Based on this information the Product Owner might break down stories into smaller stories, adjust story priorities or otherwise work with the team to define the ideal sprint outcome. When the sprint is started the stories are moved into the sprint backlog.

About Scrum

Scrum is an iterative approach to Agile software development. The methodology has been around since the 1980s but was popularised by Jeff Sutherland and Ken Schwaber.

Scrum breaks the development of a product down in to discrete iterations (termed Sprints) that each deliver functionality that could potentially be shipped to users.

The Scrum Alliance offers an excellent introduction to Scrum that provides an overview of key Scrum concepts, stakeholders, processes and artefacts.

Estimation of Bugs

Scrum teams do not normally apply story point estimates to bugs because bugs are considered to be part of the ongoing work that the team must deal with (i.e the overhead). If you view the story points completed in a sprint as a measure of progress, then bugs also have no value because they do not deliver anything additional to the customer.

However, you can apply estimates to bugs if you wish by configuring the "Story Points" field to apply to other Issue Types (by default it only applies to Stories and Epics). Some more information on this is in the documentation.