Track Sprints

Daily standup occurs every day at a time that is convenient for all team members–usually in the morning–and often time-boxed at no more than 15 minutes. A burndown chart is used to view the team's overall status. The list of stories that are being worked on in the current sprint are viewed alongside a list of impediments (if there are any impediments). During standup, each team member addresses three key issues: what they have worked on since the previous daily standup, what they will work on today, and what impediments (if any) are present that could affect their current work item.

Because daily standup is a collaborative meeting, a given team may use multiple views to accomplish their daily standup goals. Many teams will choose to start by viewing their sprint burndown chart, from which the current health of a sprint can be viewed.

If your team has broken its stories down into tasks and is tracking task by hours, you may also want to review the sprint task burndown chart, which helps assess current progress by hours.

A storyboard can be used to view all of the stories in the sprint, often organized by work status and grouped into the following phases: Not Started, In Development, In Test, In Review, and Accepted. A storyboard cleanly shows the stories that are being worked on, by whom, and where that story is in the development cycle.

During standup, stories may be updated as information is shared among team members, stories may be transitioned from one phase to another, and so on.

A defect is a bug, an issue, or some problem with the a product. A defect can be identified by a customer, by a member of your sales or support organization, and (most often) by a member of your own team (a tester or an engineer, for example).

Serena Serena Agile Planner comes configured with a lightweight way to manage defects. Using this lightweight approach, any defect that is found during a sprint can be added as a defect, similar to how a task is added as a child to a story. If this approach is used, then that defect will need to be fixed before the parent story can be completed.

Another approach is to create defects independently. Using this approach, defects should be grouped under a generic story called Defects (or the name that is most meaningful to your team) that is used in the same manner for all products, releases, and sprints. All defects live under this story and can be moved among backlogs as long as they are being moved as part of the same parent container.

A release status meeting gives all team members (and other stakeholders) visibility into the current status of any given release. You can use a release burndown chart to help show the progress of the release, view the distribution of work item objectives as they relate to story points, and view a team's historical velocity. Release status is typically monitored by a product owner or by a group of stakeholders. In Scrum, a release burndown chart is used as the primary method of monitoring the release status.

A sprint review meeting (or retrospective) should occur at the end of every sprint (and often at the end of every release too). A sprint review gives team members (and other stakeholders) to give each other honest feedback about how well the sprint or review was (or was not) executed. The purpose of the review is to identify areas of improvement, identify successes and failures, and to learn and grow as a team so that it can improve its performance in future sprints.