Visual Studio ALM Rangers Transparency – Clarifying the processes: Guidance (Part 2)

  • Article

We continue from Visual Studio ALM Rangers Transparency – Clarifying the processes: Projects (Part 1), which covered the high level project view. In this post we will have a closer look at the new experimental guidance checklist for GUIDANCE-type projects.

Remember that the objective is to create a consolidated and easy to follow map of common ALM Ranger tasks as part of projects, in this case a Guidance project.

Selecting the GUIDANCE project quick reference

Option 1 – Click on the GUIDANCE tile ion the ALM Rangers Dashboard
imageBUTTON

Option 2 – Click on the Guidance Project – Process & Checklists URL on the PROJECTS project quick reference
image PPP_PRD_132_3D_people-Puzzle

Stepping through the GUIDANCE sheet

image

  1. Each guidance project is based on one or more Epics (killer features), which are owned by the Product Owner and driven by the Project Lead.
  2. The team starts by revising the backlog, creating product backlog items (PBIs) and tasks needed to implement each Epic. In addition the team defines the sprints/iterations and the team member capacity. It is important to define pessimistic capacity estimates due to limited a part-time bandwidth!
  3. Once the backlog is defined, the team iterates through the sprints/iterations using the process template and methodology of their choice at a team level, but using Ruck as a bare minimum. Content is developed using the ALM Ranger templates for consistency and based on the User Education (UE) Review Guidelines defined by Patricia Wagner.
    Common Questions:
    1: Who creates the sprint backlog? The team, with optional guidance from the product owner.
    2: Who prioritizes the sprint backlog? The team, with optional guidance from the product owner.
    3: Who assigns or grabs tasks? The team members typically grab tasks. Alternatively the project lead could assign tasks to team members to minimise impact on team members and ask the team to verify.
  4. Once content reaches a near feature-complete and quality level, the team reviews the deliverables and releases ALPHA release for all ALM Rangers to review.
  5. A UE Technical Review is performed on the content. The team iterates through revisions until the guidance reaches a BETA quality.
  6. The Product Owner reviews and approves the BETA release, which is typically released on Codeplex.

     
  7. Once the guidance is feature complete and has passed all the relevant reviews and assessments, the Release Candidate is optionally released, followed by the Release To Market (RTM).
  8. Part of the RC and RTM releases are HOL Packages which allow users and the VM Factory to setup the HOL environment in an automated manner.
  9. If a follow-up release is voted for and approved as mentioned in Visual Studio ALM Rangers Transparency – Clarifying the processes: Projects (Part 1), the next set of Epics are tackled, restarting from step 1.
  10. The sheet also summarises the core responsibilities of the Ranger, the Project Lead and the Project Owner.

What do you think"? Add your thoughts as comments or email me direct.