Best practices for creating a single Azure DevOps (TFS) -based project template

In one of the previous articles, we wrote about how the whole company switched to a single tracker based on Azure DevOps (TFS). This allowed us to create a unified set of rules for project management. We will tell you how our project office developed the logic according to which all our teams are working now.





A single tracker alone does not guarantee that all teams will have workflows in the same way. For this to happen, the company must have a unified view of project management - both at the upper level, where managers plan product development, and at the lower level, where developers complete tasks and deliver releases to the customer.





Such a unified view gives the continuity of experience. All projects are similar to one another, all teams use the same approach and speak the same language. To this end, our project office last year set about creating a single template that combined our common terms, processes and default project settings.





The goal was to make it so that in the end each project could be β€œread” in the tracker and clearly understand its state. Moreover, this can be done both by a person (adjust end-to-end metrics for all projects, understand where everything is good and where everything is worse), or a machine (the Release Notes formation service β€œunderstands” which tasks with which statuses and tags to include in the mailing list). And of course, all newly launched projects must be created at once in the same rules.





We have now achieved this goal. When a manager sends a request to administrators to start a new project, he does not need to explain what should be there: what settings and types of tasks, to which systems to connect. Everything you need is in the project from the very beginning, you can immediately start sprints, fill out tasks, prepare a development plan.





, . - , (, ..). , , .





, .





True Engineering

1.  . , – .





- Epic. -, . , .





, . β€” Β« Β».





– Feature, 1-3 ). Feature – -. , .





– PBI (Product Backlog Item, ), . , , – PBI. Task-, , 8 .





, , - – .





2.  . PM – , , , , .





- , . , , .





, . , - .





, .





3.  . :

















, : , , , . .





Azure DevOps

. TFS. , , , , .





TFS Aggregator. Task- PBI. , .. Release Notes, , Release Notes.





OLAP-. , , Time-to-Market, . . , – , .





. , , .





. , , .





– -. , , TFS.





. , . , .





Another challenge is organizing a sprint retrospective. According to our idea, the system should be able to interpret and interpret the results of the sprint: what was planned at the beginning of the sprint, what was received at the end, how the work went in the process and if there were difficulties, then where. Then, in retrospect, the team will not be engaged in a subjective analysis of their results, but will evaluate them according to objective data.








All Articles