Scrum Managment in VSO Part II – Implementation

Hello Friend,

Welcome back to Scrum Management Series !

AS we have  understood the scrum methodology described in part 1 , Next I am going to explain the i am explain the details about implementing the development project via scrum methodology in Visual Studio Online.

We know that there are limitation with Visual Studio Online as you see in this article. Still its quite quick and easy to manage the project in VSO and get very basic and important reports as per the need to visualize the development team progress.Lets start !

Work Items Hierarchy in SCRUM

This section is mainly concentrated with process to follow in VSO/TFS while working with Application. We are using Scrum process template to plan the projects, then track, view, and report their progress. Teams plan their project by capturing features and requirements as product backlog items (PBIs). They track bugs, work, and blocking issues using the bug, task, and impediment WITs. Features support a first level of portfolio management to view a rollup of PBIs across teams.

Below diagram shows the different work item types used by scrum template:

This process template tracks Bugs at the same level as Product Backlog items and tracks estimates using an Effort field. The system automatically zeroes out the Remaining Work field when the task State is set to done. A work item is a TFS database record that contains the definition, assignment, priority, and state of work. Work item types define the template of fields, workflow, and form for each type. Work items can be linked to each other to support tracking dependencies, roll up of work, and reports.

Defining Features

Features represent work that cannot be completed within one sprint and instead will run over a longer period of time before it is complete. They are broken down into Product Backlog Items that we hope will fit into a single sprint. Features are not estimated as they are by definition large and unwieldy, instead they have a target date to help prioritise and plan releases over time. Features are not used in sprint planning as they are too big – only the Features children in the form of Product Backlog Items are used for sprint planning and forecasting.

In short, Features are composed of Product Backlog Items and have target dates.We can view hierarchical portfolio of backlog items by creating features and then creating links between those features and the backlog items that support them. You can then view overall progress for features as well as for the backlog items that support them.

To create features, please have look in following link:

https://msdn.microsoft.com/en-us/library/dn237341.aspx

Defining Backlog Items

A product backlog is a prioritized list of all the functionality needed to complete during an iteration.Whenever there is new requirement, which will be distributed as set of backlog items owned by Product Owner. These backlog items are either in form of PBIs or Bugs which can be added by anyone which will be groomed by entire team during the iterations.

You can create the PBI or Bugs from Product Backlog page.  You can open each PBI or bug to provide more details and estimate the effort. Also, by prioritizing the PBIs and bugs on the backlog page product owners can indicate which items should be given higher priority.

By defining the Effort for PBIs or bugs, teams can use the forecast feature and velocity charts to estimate future sprints or work efforts. By defining the Business Value, product owners can specify priorities separate from the changeable backlog stack ranking.

To create backlog items, please follow the steps described in following link:

https://msdn.microsoft.com/en-us/library/ee518933.aspx

Monitoring Backlog Items

Teams can use the Kanban board to track progress of PBIs and bugs, and the sprint task board to track progress of tasks. Dragging items to a new state column updates the Workflow State and Reason fields.

A typical workflow progression for PBIs and bugs follows:

• The product owner creates a PBI or a tester creates a bug in theNew state with the default reason, New backlog item.
• The product owner moves the item toApproved after it is sufficiently described and ready for the team to estimate the level of effort. Most of the time, items near the top of the Product Backlog are in the Approved state, while items toward the middle and bottom are in a new state.
• The team updates the status toCommitted when they decide to complete the work during the sprint.
• The item is moved to theDone state when the team has completed all its associated tasks and the product owner agrees that it has been implemented according to the Acceptance Criteria.

By updating the workflow status, teams know which items are new, in progress, or completed. Most WITs support transition both forward and backward from each workflow state.

To work with Kanban board, please have look on following link:

https://msdn.microsoft.com/en-us/library/jj838789.aspx

Structuring Sprints

As described in earlier section in Scrum Events, Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. And hence, Sprint is a heart of Scrum.

In order to define team with the sprint, please have look in following link:

https://msdn.microsoft.com/en-us/library/hh500414.aspx

After defining the team and sprint, it’s necessary to schedule the sprint as explained in following link:

https://msdn.microsoft.com/en-us/library/hh500418.aspx

Once you schedule the sprint, Define the team capacity that will help to make sure you’re taking on the right amount of work in the sprint. As you work day-to-day, you’ll be able to see if your team is on track.

To define the capacity of team update them in capacity tab of the sprint as indicated in following screen:

 

 

 

 

 

 

 

 

 

Above represents the individual’s capacity per day. It’s also facilitate to configure off days of individual team member or entire team as well as activities of individual during the sprint.

After structuring the sprint, its turn to assign the backlog items in sprint. From the backlog items page, move planned backlog items in to sprint as indicated in following screen:

Creating Tasks

Once sprint with backlog items is ready, team will distribute the backlog items and break down them into tasks by clicking on plus sign of product backlog item. Team member can also create subtask by clicking on links tab in task page.When team member estimate work using hours or days, they define tasks and the Remaining Work and Activity (optional) fields.

Understanding Common Work Item Fields

The following fields and tabs appear in most work item forms. Each tab is used to track specific information, such as History, Links, or Attachments. These three tabs provide a history of changes, view of linked work items, and ability to view and attach files, respectively. The only required field is Title. When the work item is saved, the system assigns it a unique ID.

Filed/Tab	Usage
Title(Required)	Enter a description of 255 characters or less. You can always modify the title later.
Assigned To	Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu will list only team members or contributors to the team project.
Remaining Work (Recommended)	Indicate number of hours of work remained to complete a task. If you divide a task into subtasks, specify Remaining Work for the subtasks only. You can specify work in any unit of measurement your team chooses.
Activity	Represents the type of activity which is assigned during team capacity planning.
State(Recommended)

Use the default value first. As work progresses, update it to reflect current state.Reason Use the default first. Update it when you change state. Each State is associated with a default reason.Area(Recommended)

Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting.Iteration(Recommended)

Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later, during a planning meeting.Backlog Priority(Recommended)

Used to track the relative ranking of PBIs and bugs. The sequence of items on the product backlog page is determined according to where you have added the items or moved the items on the page. As you drag items, a background process updates this field, which is assigned to type=”Order” in the Process Configuration file.All Links Add all types of links, such as hyperlinks, change sets, source files, and so on. This tab also lists all links defined for the work item, even those defined in other links control tabs.Attachments Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types.History Review the audit trail that the system captures and capture additional information.Every time that the work item is updated, information is appended to the history. History includes the date of the change, who made the change, and which fields were changed. You can also add formatted text to the history field.

To know more information about other fields, please have look on following link:

https://msdn.microsoft.com/en-us/library/ms194971.aspx

Basic Check in Policies

A check-in policy is a rule that must be executed by each team member before every check-in to ensure that the selected change set is OK to commit. Please follow below policies before every check into TFS:

• Verify that there is no warning or build error message.
• Verify that the last build was successful.
• Verify that code review has been done.
• Verify that certain tests are completed.
• Verify the check in comments has been added.
• Verify that one or more work items has been associated.

In this section we have learned to implement the Scrum Methodology in Visual Studio Online and next we will look for reporting of the work items which is available here !

Happy Scrumming ! 🙂