# 9 Monitoring the product backlog entries Vs User stories

Before any feature is taken up for production, the user story (stories - one feature can have multiple user stories)  should be ready along with the acceptance tests. It is the responsibility of the product owner to ensure this. Elaboration of the product backlog entries into user stories is a continuous process throughout the project (the product backlog is allowed to grow), and it is important to track this. CollabTeam provides this chart to track the total number of features Vs user stories against them. 

The second bar in red colour, indicates the total number of  bugs handled through the product backlog. 

# 8 Program management using CollabTeam

A program is a collection of inter related projects, when done together gives the stakeholders some added advantages, than doing them one after the other (thanks to PMBOK). Consider a situation, where multiple project teams operating from different geographies contributing to a program (or position yourself as a super product owner, who has multiple project teams contributing tp your program). CollabTeam provides you with the following features to cater to this situation in a seamless fashion.

• A program comprising of multiple milestones (road map) can be defined using the program option under the administrator module (log in as administrator).


• Sprints under the projects within the company can be linked to the milestones

This feature helps to integrate the outputs of multiple sprints across projects to a milestone at the program level.

# 7 Handling of defects by collabteam

In collabteam, defects are handled through the product backlog. Defects are booked under the product backlog under the category "defects", to be considered during the next sprint.

# 6 Sprint Velocity

Sprint velocity calculations help the team to learn and continuously improve.

Sprint velocity = (work units completed / work units committed) during the sprint * 100

During the initial sprints, it is quite likely that teams can fail becuase they either over committed work or under committed. In the former case, at the end of the sprint, the team might not have completed the work committed at the start of the sprint. In the latter case, the sprint will get over before the sprint end date. After some learning through a couple of sprints, the team will learn to complete what they committed within the stipulated time frame. At that time, the sprint velocity calculation will show 100%.

# 5 Sprint Burn down chart

A sprint burn down chart helps to track the progress of work, and to make appropriate dec

isions as the sprint progresses. The 'Y' axis shows the 'effort' required to complete the balance work in tyhe sprint and the 'x' axis, the number of days of the sprint. The objective is to make the effort required to complete the sprint zero on or before the sprint end date.

In the conventional project management, we use the earned value management. The earned value chart focuses on the work completed so far. In the case of a burn down chart, the focus is on balance effort required to complete the pending activities.

Collabteam feature

Collabteam has the sprint burn down feature. The burn down is derived from the 'balance effort' against the tasks, which the team members updates regularly.

# 4 Sprint Board

At the end of the sprint planning meeting, a sprint board is created. A sprint board is classified into three columns - work to be done, being done and done. At the beginning of the sprint the features to be developed and the associate tasks will be umder 'to be done'. The team members

are requested to volunteer the work. Once the work gets volunteered it moves on to the 'being done' column and finally when it gets done, it moves to the 'done' column. Work volunteering is an integral part of scrum. Work volunteering brings in more ownership and pride in work.

When the tasks are progressing, the team members can update the effort required to complete the remaining part of the work on a daily basis. This helps to forecast the total effort required to complete the balance activities in the sprint

# 3 Sprint backlog

Sprints are ideally 30 day cycles, where the team works on a subset of the features from the product backlog, which is agreed upon by the team, the scrum master and the product owner during the sprint planning meeting ( 1 day meeting for 30 day sprints). This subset of the features, which are taken up for production during the sprint is known as the sprint backlog.

Sprints should be ideally of same duration. This is becuase, over a period of time the team will learn to accurately estimate what they can achieve during a specific time frame. Once the sprint durations fluctuate, the team will never learn to estimate the work. It is not necessary that sprints should be 30 day cycles. For our projects, we are doing 6 day sprints, where at the every week, a new set of features are released.

Sprint backlog feature in CollabTeam

The above screenshot is the collabteam screen for creating sprints. The entries on the left are the product backlog. Against the entries in the product backlog (not yet developed), check boxes are provided to choose the features for the sprint under consideration. The selected features from the product backlog are transferred to the sprint backlog.