Sign upLogin

GSA/christopher

View on GitHub
Star
_guides/conducting_sprint_review.md

Summary

Maintainability
Test Coverage

Line length
Open

A **Sprint Review (Demo)** provides the platform for the Scrum Team to showcase what they accomplished during the sprint while creating the opportunity for key stakeholders to [inspect the increment and adapt the Product Backlog](https://www.scrum.org/resources/what-is-a-sprint-review), if necessary.
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

Line length
Open

The Sprint Review (Demo) is **not** a status meeting - it is an opportunity to elicit feedback and foster [collaboration](https://www.scrum.org/resources/what-is-a-sprint-review) between the Product Owner, Scrum Team, and stakeholders and identify the next incremental effort that can be done to optimize business value. It is recommended the meeting be timeboxed to **_one hour per week of Sprint length_** (i.e. two week sprint is a maximum 2-hour Sprint Review) and to focus on acceptance criteria that meets the team’s [Definition of Done (DoD)]({{ site.baseurl }}/guides/glossary/#definition-of-done). If a demonstration of functionality is required, it should center around a realistic user experience that displays the product / prototype and how the user will interact with its features, not the system source code or logic.
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

Line length
Open

The best way for the Product Owner to summarize which items are accepted and considered "done," demonstrate features completed, and review the team’s commitments, is to use a presentation-style format. Sprint Review presentations can be stored in an accessible team folder and provide a convenient, informative summation for stakeholders who are unable to attend the review. The Product Owner, or team member presenting, should always prepare and practice before the meeting. While the Scrum Master should ensure the reviews for the upcoming few sprints are scheduled ahead of time to enable stakeholders to plan their attendance.
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

First header should be a top level header
Open

### Preparing a Sprint Review (Demo) Presentation
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD002 - First header should be a top level header

Tags: headers

Aliases: first-header-h1

Parameters: level (number; default 1)

This rule is triggered when the first header in the document isn't a h1 header:

## This isn't a H1 header

### Another header

The first header in the document should be a h1 header:

# Start with a H1 header

## Then use a H2 for subsections

Headers should be surrounded by blank lines
Open

### Good Reads
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Headers should be surrounded by blank lines
Open

### Preparing a Sprint Review (Demo) Presentation
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD022 - Headers should be surrounded by blank lines

Tags: headers, blank_lines

Aliases: blanks-around-headers

This rule is triggered when headers (any style) are either not preceded or not followed by a blank line:

# Header 1
Some text

Some more text
## Header 2

To fix this, ensure that all headers have a blank line both before and after (except where the header is at the beginning or end of the document):

# Header 1

Some text

Some more text

## Header 2

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse headers that don't have a blank line before, and will parse them as regular text.

Lists should be surrounded by blank lines
Open

  - Project Managers
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD032 - Lists should be surrounded by blank lines

Tags: bullet, ul, ol, blank_lines

Aliases: blanks-around-lists

This rule is triggered when lists (of any kind) are either not preceded or not followed by a blank line:

Some text
* Some
* List

1. Some
2. List
Some text

To fix this, ensure that all lists have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

* Some
* List

1. Some
2. List

Some text

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse lists that don't have blank lines before and after them.

Note: List items without hanging indents are a violation of this rule; list items with hanging indents are okay:

* This is
not okay

* This is
  okay

Lists should be surrounded by blank lines
Open

  - Developers
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD032 - Lists should be surrounded by blank lines

Tags: bullet, ul, ol, blank_lines

Aliases: blanks-around-lists

This rule is triggered when lists (of any kind) are either not preceded or not followed by a blank line:

Some text
* Some
* List

1. Some
2. List
Some text

To fix this, ensure that all lists have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

* Some
* List

1. Some
2. List

Some text

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse lists that don't have blank lines before and after them.

Note: List items without hanging indents are a violation of this rule; list items with hanging indents are okay:

* This is
not okay

* This is
  okay

Lists should be surrounded by blank lines
Open

* [6 Common Misconceptions and Anti-Patterns of the Sprint Review Meeting](https://www.solutionsiq.com/learning/blog-post/6-common-misconceptions-and-anti-patterns-of-the-sprint-review-meeting/)
Severity: Info
Found in _guides/conducting_sprint_review.md by markdownlint

MD032 - Lists should be surrounded by blank lines

Tags: bullet, ul, ol, blank_lines

Aliases: blanks-around-lists

This rule is triggered when lists (of any kind) are either not preceded or not followed by a blank line:

Some text
* Some
* List

1. Some
2. List
Some text

To fix this, ensure that all lists have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

* Some
* List

1. Some
2. List

Some text

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse lists that don't have blank lines before and after them.

Note: List items without hanging indents are a violation of this rule; list items with hanging indents are okay:

* This is
not okay

* This is
  okay

There are no issues that match your filters.

Category
Status