All Posts Tagged Tag: ‘artifact’

Scrum Artifact: Burn Down Chart 7

The Burn Down Chart

Definition

A burn-down chart is a graphical representation that shows the progress made during the development cycle.

The Burn Down Chart can be used to show outstanding work for a release or for a sprint and in both cases, the chart represents the amount of work remaining for the completion of the release or sprint versus time.

How the Burn Down Chart works?

The vertical axis (Y-axis) of the chart presents the work remaining to complete the release or sprint while the horizontal axis (X-axis) represents the time.

Scrum Burn Down Chart

Scrum Burn Down Chart

The chart typically presents 2 lines going from the top left section of the chart towards the bottom right.  While the first line presents an estimate of work delivered over time, the second line shows the actual values. As such, the Burn Down Chart is useful for predicting when the work scheduled for the current release or sprint will be completed.

Posted on: 07-1-2009
Posted in: Scrum

Scrum Artifact: Sprint Backlog 0

The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the team’s perception of the time it will take to complete the various features.
It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.
The sprint backlog is very commonly maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.
 During the Sprint the ScrumMaster maintains the sprint backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done.
The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.
The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
The sprint backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of that sprint. Sprint backlog creation happens in the second part of the sprint planning meeting with the participation of every team member. Giving some real attention to this process is fundamental to a better understanding by the team about what should be done and to better planning during the sprint. Despite this, many teams still struggle with this activity. I hope these tips will help.

 

The Sprint Backlog

Definition

Similar to the Product Backlog, the Sprint Backlog is a list of tasks that the Scrum team is committing to deliver within the current Sprint. The Sprint Backlog is a simple list of the tasks that must executed by the team in order to deliver an increment of functional software at the end of the Sprint.

How the Sprint Backlog works

Based on the priorities set by the Product Owner, the Scrum team selects as many items from the Product Backlog as they believe they can complete within the current Sprint.

Sprint Backlog creation happens in the second part of the Sprint Planning meeting with the participation of every team member.  It is critical that the team selects the items and size of the Sprint Backlog since they will be the ones committing to completing the tasks.

During the Sprint the Scrum Master maintains the Sprint Backlog by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done.

 

References:

Posted on: 05-18-2009
Posted in: Scrum

Scrum Artifact: Product Backlog 5

As I’m gathering information and slowly writing the content of my book, there is some information I need to refer to in the book but I don’t want to include as it distracts the reader. As such, I decided to start keeping that information and post it on this blog. It will be easy to know when a blog post is done in the context of the book as it will be tagged “the agile bi book“. Today’s post relates to the Product Backlog.

The Product Backlog

Definition

The Product Backlog is simply a list of customer requirements needed to complete the project and sorted by business value. It is initially prepared at the beginning of a project by the Product Owner and remains active throughout the duration of the project as completed items get removed while new items are added.

How the Product Backlog works

As time goes by, the highest priority items in the Product Backlog get broken down into smaller chunks as they become part of the Sprint Backlog.

The Product Backlog is property of the Product Owner while the business value is set by the Product Owner, the development effort is set by the team. 

Benefits of using a Product Backlog

1) It’s a simple list, discussed face-to-face
2) It provides the customer with control
3) The product backlog is allowed to change.
4) Inspection and adaptation
5) It resolves dependencies timely, and without fancy pansy dependency graphs.
6) It allows for some longer term planning
  • It’s a simple list, discussed face-to-face;
  • It provides the customer with control;
  • The product backlog is allowed to change;
  • Inspection and adaptation;
  • It resolves dependencies timely;
  • It allows for some longer term planning.

In Summary

The Product Backlog:

  • is simply a list of things needed to be done in the context of the project;
  • always lists items that add value for the customer;
  • may include functional requirements and non-functional requirements;
  • can also include items required by the team, but only the ones that will eventually bring value to the customer;
  • cannot include low level tasks. 

References:

Posted on: 05-13-2009
Posted in: Scrum