How we unified a project template for our teams

If you didn’t read the beginning of this story, we described migrating to Azure DevOps in one of our previous articles. A uniform tracker doesn't guarantee workflows will run the same way in all teams per se. For this to happen, the company must first share a common understanding of project management both at the top level, where the managers plan product development, and at the lower level, where the developers complete tasks and deliver releases to the client.

Such a singular view creates a consistency of experience. Projects remain similar and recognisable among one another, all teams utilize the same approaches and speak the same language. Last year our project office embarked on creating a uniform template that could combine our common terms, processes, and default project settings.

The goal was to make it so that each project could be “read” in the tracker and its state understood clearly. Moreover, this was to be done both by a human (adjusting end-to-end metrics across all projects, understanding where things go better or worse) or by a machine (the Release Notes drawing service “understandings” to which tasks assigned which statuses and tags were to be included in the mailout). Of course, all newly launched projects had to be created according to the same initial rules.

We've now reached this target. When a manager sends a request to the admins, starting a new project, they don't need to explain what's to be there: what settings and task types orwhich systems are to be connected. All the necessary elements are included in the project from the very beginning; one can run sprints, fill out tasks, prepare a development plan right away.

At the company-scale, the number of standardized projects is growing; the old ones are being migrated stagewise. Those already moved can be used as a basis for cross-project processes; successful task and team management practices are distributed between projects (dashboards, metrics, etc.). And the project office can be sure that, within all the teams, development follows the same pipeline and all teams' developers and managers intend the same meaning on the same terms.

Now we’ll describe the logic behind the template, as well as which settings are enabled there by default.

True Engineering project template elements

1. Task types and hierarchy. The first thing our teams agreed on is a uniform concept of product decomposition.

Epic is the pyramid’s apex. It’s a business value that the product function must embody. From the development standpoint, it’s a vital part of the function set that can be deployed within several iterations.

An important criterion here is epic's finiteness in time, i.e. the attainability of a specific goal. A good example of an epic is 'Test Automation in a Project'.

Below is the 'Feature;’ these elements take 1-3 sprints for development. One Feature is one business scenario. E.g. Business trip processing.

One level below is PBI (Product Backlog Item, a delivery unit); it represents a separate case within the scenario. Preparing a business trip application, incoming appeal approval, uploading receipts for an advance report, these all fall within PBI. They are divided into Tasks, atomic units of work that are assigned to the performer, and do not require more than 8 hours.

As a result, the teams attain a uniform vision of how to split the project in order to deliver the business result effectively, which is our main goal.

Image

2. Development pipeline mechanics. A huge part of any PM's work — they control the state of each feature in development; monitor that the team could send the code for testing at the right time, and so on.

In the past, each team and each manager had their own approaches which had evolved over the years. Of course, in general, everyone has the same understanding of ​​the development process, but we needed to standardize it and to extend this standard to all.

The project office studied our teams' practices and formed a single set of statuses for the release process. The diagram was made as detailed as possible so that no team had to add any steps of their own.

As a result we got a single pipeline which consists of clear and convenient steps.

Image

3. Resource and time planning support. In all the teams we introduced three sets of metrics for labor cost management:

• Initial development time assessment
• Real reported time
• Time leftovers

Having appointed this calculation system in all projects, we gained the possibility of utilizing end-to-end analytics: for instance, we can upload all the time planned, compare with the time actually spent, and see where deviations occur. The template also sets the duration of one iteration per two-week sprint.

Template’s technical capabilities

Uniform metrics set. We described our project analytics thoroughly in the TFS dashboard article. Our template contains everything a manager requires to assess the project’s state, including the cases when the manager joins the team midway.

TFS Aggregator plugin.This tool is attached to the project and enables automatic control of the task status movement and, using this data, tracking the state of their parent PBIs. As a result, we can set uniform rules for the client's tracker and send them notifications about the release status, task comments, etc. This function is used to collect Release Notes automatically, and to notify clients about feature deliveries, as we described in the Release Notes article.

OLAP cube integration. This function provides analysis of labor costs, task statuses,  and monitors Time-to-Market and other project indicators. In the past we used the cube to monitor metrics within projects. Once we got a uniform coordinate system, it became possible to create end-to-end analytics for all teams at once, and we know that the same measurements are used in all projects with the same ideas.

Client tracker integration. We are synchronizing the data so all the accounting systems will display the task statuses and time tracking automatically, simultaneously, and correctly.

Calendar. This module helps track who’s going on a vacation, who’s being engaged in another team, etc.

Further destinations

Our primary target is integration with the feature flag portal. More and more teams are adopting this tool, and we want the features' states to be displayed in TFS.

In parallel, we are considering expanding the list of metrics over the templates. We want to create end-to-end metrics to shift the analytics outside each individual project. Then we can distinguish the strengths of different teams and identify bottlenecks, improve experience sharing and accelerate the intelligence accumulation.

Another challenge is organizing a sprint retrospective. We want the system to interpret sprint results: what was planned at the beginning of the sprint, what we got in the end, how the work went in the process, what difficulties were present and where. Then in the retrospect the team will not analyze their results subjectively, but will assess them using objective data.