Skip to content
This repository has been archived by the owner on Feb 5, 2021. It is now read-only.

Flesh out Product Backlog and Doomline module documentation #47

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Flesh out Product Backlog and Doomline module documentation #47

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cc28501
Update contents.lr
Jan 13, 2021
003645e
Update contents.lr
Jan 13, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 15 additions & 8 deletions content/backlog/how-does-the-backlog-module-works/contents.lr
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,22 +1,29 @@
title: How does the backlog module works?
title: How does the Backlog module work?
---
body:

### Q. What is the backlog?
A. A backlog is a prioritized collection of user stories and tasks that the team needs to work upon in the future. A Product backlog is related to the tasks to be done for the overall product, including those that fit in the project scope and those that will not fit in the current project but could be done in the future.
### Q. What is the Product Backlog?

Typically, the backlog will be estimated and prioritized so the team can start working on the User Stories that sit on the top of the collection.
A. Product Backlog is an agile team's primary tool for scope management on a given project. The Product Backlog should give the team's Product Owner a real-time view into the current state of all known work. This includes work already done in the past, work currently in flight, as well as work planned for the future. A good Product Backlog allows an agile team to move swiftly with both speed and predictability.

In the following picture, User Stories that sit on the top of the pile should be ready to go into the next sprint and start being worked on.
A Product Backlog is a list of user stories, ranked in priority order of importance. Stories near the top of the backlog are considered the most important items for the team to work on next. Prioritization of stories is a collaborative activity performed by the Product Owner and Product Manager working in partnership. The Product Owner knows the business value of the work while the Product Manager understands relative size and complexity. The Product Manager knows the relative size and complexity of stories through continuous communication with the development team.

In the picture below, User Stories sitting at the top of the backlog are ready to be added into the next sprint. Once the User Stories are added to the sprint, the development team can begin picking up the work.

![Backlog](backlog.jpg "Backlog")

### Q. What is a sprint?
A. Sprint is the scrum term for an iteration. An iteration is a period when the team works to produce the next increment of the finished product.
A. Sprint is the scrum term for an iteration. An iteration is a fixed period of time in which the team works together to produce the next increment of the product.

Once a sprint is started, scope is traditionally considered fixed. This means that new stories may not be added to the current sprint unless a story of equal weight (in points) is removed to compensate. This is how the team can ensure that there is no "scope creep" - attempting to pack in more work after the sprint commitments have been made.

Once all of the User Stories in a sprint are done, there are multiple options for how to proceed. If the sprint is not yet finished in terms of calendar time, additional User Stories may be added so that the team may continue executing until the end of the sprint. Figuring out which stories to add should be a collaborative activity for the entire team. It is also acceptable to simply close the sprint and plan a new one.

If the sprint ends and all work is not yet completed, the Product Owner and Product Manager may decide whether to "roll over" unfinished stories into the next Sprint. The Product Owner and Product Manager may also decide to deprioritize the unfinished stories for a later sprint.

In order to work on a focused subset of User Stories that will not change while the team is working on them, we create a separate area, named Sprint. The team is committed to produce and deliver this subset on a specific period. When all User Stories of a Sprint are done, that Sprint will be closed and a new iteration could start.
Additionally, the team should attempt to learn why they were not able to complete all the work for the sprint during a retrospective session.

A common workflow would be to create a new sprint and drag the top User Stories from the backlog into the new sprint to ensure that the team, with its fullest dedication, can afford to deliver into an specific date. When there is consensus on what the team will be focused on during the sprint, the sprint starts.
A common workflow is to create a new Sprint and drag the User Stories at the top of the backlog into the new sprint to ensure that the team, with its fullest dedication, are able to deliver all the work by a mutually agreed-upon date. When there is consensus on what the team will be focused on during the sprint, the sprint starts.

![Sprint](sprint.jpg "Sprint")

Expand Down
9 changes: 5 additions & 4 deletions content/backlog/what-is-the-doomline/contents.lr
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,16 +3,17 @@ title: What is the doomline?
body:

### Q. What is the Doomline?
A. The Doomline (AKA Project Scope) is the estimated set of User Story points that will be delivered at the end of the project.
A. The Doomline (AKA Project Scope) is the estimated set of User Story points that will be delivered at the end of the project. The Doomline is a powerful way to visualize what work is at risk for a given deadline and what work will likely make it in.

Typically, when the User Stories of the backlog are estimated, the Doomline will show all the User Stories that, according to our current estimation, backlog prioritization and project scope configuration, will become the expected product.
Typically, all User Stories are estimated with points. Points indicate the relative time/weight/complexity/effort that the team believes is necessary to expend to complete a particular User Story. When the team is estimating consistently, the Doomline module uses the team's historical velocity to compute predicted completion date for a given amount of scope. When used properly, the Doomline enables ruthless scope management against an aggressive deadline.

The Doomline is visible in our interface in the backlog module, if we configured it in the admin area, as a red bar amongst our User Stories. That is your project scope.

The Doomline is visible in the Taiga interface in the backlog module. (The Doomline may be configured in the project admin area). When looking at the Product Backlog, the Doomline is displayed as a red bar in the middle of our User Stories. This is the project scope.

![Doomline](doomline.jpg "Doomline")

### Q. How do I configure my project Doomline?
A. To configure your doomline, you should have admin privileges of your project. In the admin area, under the ``Modules`` section, find your backlog settings. If you change your 'Expected total of story points' in the admin area, the Doomline will automatically move to fit in the new project scope.
A. To configure your doomline, you should have admin privileges on your project. In the admin area, under the ``Modules`` section, find your backlog settings. If you change your 'Expected total of story points' in the admin area, the Doomline will automatically move to fit in the new project scope.

---
order: 100
Expand Down